Re: [OT] Obj-C shortcomings (Was: Re: Subclass)
Re: [OT] Obj-C shortcomings (Was: Re: Subclass)
- Subject: Re: [OT] Obj-C shortcomings (Was: Re: Subclass)
- From: Sailor Quasar <email@hidden>
- Date: Sat, 14 Jun 2003 07:03:00 -0400
On Saturday, June 14, 2003, at 06:47 AM, Wade Tregaskis wrote:
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.
Fair enough. Although I must say your path towards optimized ObjC is
a well travelled road, without a happy ending.. :/
That path ends pretty much at pure C, I'd say.
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.
Fair enough, I suppose. But, where do you draw the line.. :)
At forcing the compiler to tell me when I called the wrong selector
because of a typo that is still a valid method *grin*.
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 :).
Would it be possible, as a workaround, for you to maintain a pointer
in each instance which refers to the global variable? At least then
you'd only have to do the two message calls when you initialize each
instance. If your variable will be a pointer of some kind anyway,
there shouldn't be any overhead with dereferencing and what have you.
Yes, that's a good solution too.
2) promote thread-unsafe coding (globals require locks to be
thread-safe unless they are guaranteed to be accessed from only a
single thread)
You'd have to lock the shared variable somewhere, anyway, whether it
be in your setter function or wherever else.
True but at least using a shared variable accessed through messages
centralizes access to that var.
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)
My memory's a bit faded on this... could you elaborate a bit, if it's
still on topic? While style is a subjective thing, crashes and data
corruption is something I'd like to know about. :)
Reentrancy refers to the calling of a method from one thread while that
same method is already executing in another thread. If that method
writes to static or global data, that data can be in an inconsistent
state when the method is reentered, causing very odd and
difficult-to-track problems.
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).
It may only be me, but I find when writing in C++ I have to violate a
lot of OO principles, simply because the language makes it too
difficult to do some things - particularly the sort of dynamism I'm
used to in ObjC. Sure, there's RTTI and virtuals and so forth, but
it's never quite enough, it seems..
Yes, in C++ that's often true, and I've never liked C++'s RTTI at all.
But just because ObjC is better doesn't mean we should relax on the
things it Doesn't make easier :).
Perhaps we're doomed always to have imperfect OO languages, because
sooner or later practicality - whether ease of coding, performance, or
otherwise - steps in. I guess it's a matter of picking which
imperfections you prefer. :)
Don't get me wrong; given the choice I will always pick Obj-C over C++
in terms of OO coding. IMHO, C++ is a nasty mess, and I'm glad to have
ObjC around, for all the relative slowness of messaging dispatches. The
trick to writing good C++ is to write C instead; the trick to writing
Obj-C is to minimize unnecessary messaging while still taking full
advantage of the language :).
-- Sed quis custodiet ipsos custodes?
My Latin is too rusty to translate this. What does it say? =)
-- Sailor Quasar, High Codemaster of the Web, scourge of systems
cvs server: Updating Quasar/brain/caffiene
A pepsi
R coke
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.