Re: Objective-C Question
Re: Objective-C Question
- Subject: Re: Objective-C Question
- From: Marcel Weiher <email@hidden>
- Date: Mon, 22 Sep 2003 11:09:11 +0100
On Sep 22, 2003, at 10:56 AM, Steve Ehrenfried wrote:
--- Marcel Weiher <email@hidden> wrote:
You can't write a Category that deals with more
than one class, even,
or with anything but *one* *class*.
Sure you can.
Please explain.
Easy: think superclasses. Objective-C is (for most practical
purposes) single-rooted.
Perhaps you are thinking of protocols, which are
analogous to interfaces in Java. Multiple classes can
implement a specific protocol; thus a protocol can
span multiple classes.
No, I am not thinking protocols. Of course, it is actually possible to
attach categories to multiple individual classes using runtime
manipulation, but that is hardly ever necessary.
From what I can tell categories are mostly a hack for
adding methods to classes that were developed by
someone else. Good OOP should focus on classes and
protocols, IMHO. Still this is a cool feature that can
be a Godsend when needed.
Well, if that is your attitude towards the use of categories, then
you're probably going to miss the more AOP-like capabilities. "If you
don't like this sort of thing, then you'll find that this is the sort
of thing you don't like" ;-)
From what I can tell Obj C is missing several things
which a good OOP language like Java has:
1) Being a able to make a method and/or class "final",
i.e. it can't be overridden or subclassed.
That is not in any way a "good" feature. In fact, it is downright
awful.
2) Being to able to have a partial implementation of a
class, i.e. an "abstract class". (Perhaps Obj C
supports this but I just don't know about it. If there
is, how do you specify that instances of a specific
class can't be instantiated?)
Objective-C "supports" this in as easy a fashion as you could want:
just implement the parts that you find necessary.
3) Built in support for exceptions, though this is
more of a convenience than part of the object model.
Precisely. Anyway, gcc 3.3 now has exceptions "built-in", apparently
to appease those who think that this "must" be a language feature.
Functionally, I have a hard time detecting any difference. Maybe if I
squint right...
Great implementation in Java, horrendous
implementation in C++ (the function signature doesn't
specify what exceptions are thrown, so how do you know
[unless it's documented, which it probably isn't] what
you need to catch or re-throw? It's real easy for an
uncaught exception to percolate up the stack).
Declaration and enforced catching of Java exception is yet another
horrible mis-feature of that language.
4) Being able to specify the access control of members
(public, protected, private). Isn't everything public
in Obj C? Sorry, I'm a newbie here, but isn't data
encapsulation part of the object model?
Language-enforced levels of access control are yet another quite
unnecessary "feature" that just complicate the language without
actually adding tangible benefits.
5) No namespaces (C++) or packages (Java). Again, Java
has a much cleaner implementation and is better
thought through, IMHO. Anything like this in Obj C?
Although I can understand the theoretical attraction of a namespace
facility, I must say that I find a prefix (which is functionally
identical) to be practically sufficient. No need to add yet another
feature.
Marcel
--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.
1d480c25f397c4786386135f8e8938e4
_______________________________________________
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.