• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Cocoa et al as HCI usability problem
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cocoa et al as HCI usability problem


  • Subject: Re: Cocoa et al as HCI usability problem
  • From: Peter Duniho <email@hidden>
  • Date: Tue, 20 May 2008 21:52:46 -0700

Date: Wed, 21 May 2008 08:33:40 +0800
From: "Michael Ash" <email@hidden>

On Tue, May 20, 2008 at 4:07 PM, Peter Duniho <email@hidden> wrote:
But personally, it makes me nervous to have a language that allows the
implementation of a class to change according to other code not related to
the class. It's one thing if you're just adding a method that you want to
use somewhere else. But in Objective-C you can also add a method that
overrides a base class method, or would not normally exist in the class but
which has meaning to some other code that might check for it.

I'd just like to point out that the above applies to any OO language which supports both subclassing and dynamic dispatch, which is to say approximately all of them. Categories are certainly differently powerful in this regard, and as such will get you into trouble in ways that subclassing cannot, but subclassing already has this powerful and dangerous semantic that you're worried about.

No, it doesn't.

Each language varies a bit, of course. But in the other popular languages that I know reasonably well -- C++, C#, Java -- a subclass does not have the ability to touch any part of the base implementation that is not specifically exposed by that implementation. Private members are invisible, and other members are only overridable when the base class allows it by making them virtual.

There is, of course, hazard any time the base implementation makes this allowance. But those choices can be made on a member-by-member basis, and reliable decisions and assumptions can be made regarding the relative dependability of the base class on the basis of what that base class exposes to sub-classes. Many classes have _no_ overridable members and no "protected" members, and thus completely encapsulate their implementations. This is, in fact, the norm for these other languages.

Cocoa restrains class extension _much_ less than any of these other languages, and in turn has a _much_ higher degree of hazard.

It's certainly a continuum. I agree we're not talking either/or, black/white, etc. here. Other languages aren't without their danger zones either. It just seems to me that Cocoa goes overboard, for relatively little payoff.

YMMV.

Pete
_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Cocoa et al as HCI usability problem
      • From: Jonathan Hendry <email@hidden>
    • Re: Cocoa et al as HCI usability problem
      • From: "Michael Ash" <email@hidden>
    • Re: Cocoa et al as HCI usability problem
      • From: j o a r <email@hidden>
  • Prev by Date: Re: Cocoa et al as HCI usability problem
  • Next by Date: Re: Attempting to create NSTableView with Single Header
  • Previous by thread: Cocoa et al as HCI usability problem
  • Next by thread: Re: Cocoa et al as HCI usability problem
  • Index(es):
    • Date
    • Thread