Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[OT] Obj-C shortcomings (Was: Re: Subclass)

On Saturday, June 14, 2003, at 05:06 AM, Wade Tregaskis wrote:
1. As noted, enforcement of pure virtual base classes.
I still don't see why a protocol doesn't fill this requirement. Just because the compiler doesn't barf, curse and delete your source when you don't implement them properly... Ultimately you can never know for sure whether a class implements the protocol at compile time, because - for example - a subclass might implement methods dynamically at runtime. It's behaviour in not meeting a protocol may be valid in it's particular case. The whole "you must implement this or else" methodology just doesn't fit the ObjC mould.

I concede this point :).

2. The ability to declare methods protected or private I'm aware it's quite possible to declare private methods as a category within the class' source file so that the selectors are not published to client code. For private methods this is fine since it prevents unwanted code from easily using them, but for protected methods it's a nusiance at best and not doable at worst.
I believe there's an implicit var (like 'self') which refers to the calling object... perhaps you could make sure the calling object isKindOfClass or isMemberOfClass, protected and private respectively.

There is no such var of which I am aware. Too bad, too, it'd be a neat feature. Irregardless, I wouldn't want to use it in this manner; the overhead of sending the isKind/MemberOfClass messages would negate the use.

I think you can use private and protected keywards in ObjC++, from what I've seen. In fact, I think I've even seen the keywords in ObjC files. They must
do something, presumably, otherwise those files wouldn't have compiled..

They work for instance variables in ObjC class, not methods, afaik.

But ultimately, it seems to boil down to: what sort of project are you working on where you don't trust the people around you? If you don't declare the methods in the header, they won't use them, right?

I'm in fact the only coder for the project I have in mind, but I prefer that the compiler enforce some things, because as a human I'm as prone to mistakes as all the rest.

3. The ability to declare static instance vars (instance vars that are part of the class object rather than of any instance of that class). If I've missed this functionality somewhere, please tell me where it is. I generally use globals to emulate it, which I personally feel is bad style.
You can declare them as static within the class method they're used. Often you'll have the scenario that you want to establish a single default instance, so you would have a class method to retrieve it, which initializes and returns it's static variable as required. That's just one of many examples.

That also is a perfectly reasonable method for getting around the missing functionality. But from an instance method, this:

someSharedVarRef = [[self class] sharedVar];

equates to:

someSharedVarRef = objc_msgSend(objc_msgSend(self, @selector(class:)), @selector(sharedVar:)); // the first parameter Could be optimized by the compiler as self->isa, but since it's a message sent to NSObject it probably won't.

That's two messages just to retrieve a variable reference that would require two pointer deferences given compiler support (i.e. ((TheClass *)self->isa)->sharedVar). You tell me which is faster :).

I don't think globals are as bad in ObjC, as compared to C++, in terms of popular opinion. Indeed, why they are so hated in C++ needs a bit of explaining - what's the difference between a global var and a getter function which returns it's own static var?

Globals are frowned upon because they:
1) promote lazy coding (i.e. the use of a global to store a value that would be better passed as a parameter)
2) promote thread-unsafe coding (globals require locks to be thread-safe unless they are guaranteed to be accessed from only a single thread)
3) promote non-reentrant coding (a global can be read fine from a reentrant method, but if that method writes to the global, you're in trouble)
4) violate OO principles, specifically enscapulation (globals can not belong to any unit of code smaller than a single object file (compiled source code file), while member variables belong only to their owning class).

-- Sailor Quasar, just another player in The World
"Come with me in the twilight of the summer night for awhile"
Email: email@hidden
_______________________________________________
darwin-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-development
Do not post admin requests to the list. They will be ignored.


Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.