[OT] Obj-C shortcomings (Was: Re: Subclass)
[OT] Obj-C shortcomings (Was: Re: Subclass)
- Subject: [OT] Obj-C shortcomings (Was: Re: Subclass)
- From: Sailor Quasar <email@hidden>
- Date: Sat, 14 Jun 2003 06:22:41 -0400
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
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.