Re: Cocoa et al as HCI usability problem
Re: Cocoa et al as HCI usability problem
- Subject: Re: Cocoa et al as HCI usability problem
- From: "Michael Ash" <email@hidden>
- Date: Wed, 21 May 2008 16:16:37 +0800
On Wed, May 21, 2008 at 12:52 PM, Peter Duniho <email@hidden> wrote:
>> 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.
This doesn't mean that they don't have this hazard, it just means that
the creator of a class is able to mitigate it.
That said, I have a difficult time emphasizing with this antagonistic
point of view that users of these languages tend to have. It's as
though the API writer is a sysadmin, and the API users are system
users, and the users must be prevented from doing anything to
adversely affect the system. I've found a cooperative approach to make
a lot more sense. The reason you avoid accessing other objects'
private instance variables isn't because you can't (you can do it in
any C-based language, of course, regardless of the access controls you
set), but because it's a bad idea and makes your code more brittle. So
it's tough to see how it makes a language better because it enforces
this kind of thing, when you can get essentially the same effect by
simply adding a comment that says "// do not override this method".
> 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.
Objective-C, not Cocoa, of course. Although Cocoa's designed is
inextricably based on the features and capabilities of Objective-C.
If the above languages are the only other OO languages you know, then
the fact that you think that these features are inconsequential and
pointless, when we think they're essential and useful, is
unsurprising. It's normal to think that the features in a language you
know well are all essential, and that the features in a language you
don't know well are all fluff. I'm sure I do it with other languages.
If I may, I'd suggest checking out at least a couple of languages that
come closer to the sort of dynamism that ObjC gives you, such as
Python, Smalltalk, Ruby, Common Lisp's CLOS, and others. It may give
you a better appreciation both for Objective-C and for how Cocoa is
put together. Or it may just convince you that we're all crazy, it's
hard to say.
Mike
_______________________________________________
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