Re: Objective-C Question
Re: Objective-C Question
- Subject: Re: Objective-C Question
- From: Dietmar Planitzer <email@hidden>
- Date: Mon, 22 Sep 2003 22:51:35 +0200
On Monday, September 22, 2003, at 11:56 AM, Steve Ehrenfried wrote:
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.
Yep, not supported in ObjC.
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?)
There is no support in the language for marking a whole class or
individual methods as abstract. The way that abstract classes are
generically implemented in ObjC is, that the abstract class implements
all abstract methods so that they throw an exception.
Naturally, the compiler will not be able to tell you if your code tries
to instanciate an abstract class and whether your abstract class'
subclasses implement all required methods. While the former hardly ever
happens in real life, the latter can happen quite easily in more
complex projects. I think that adding an abstract keyword to ObjC
wouldn't hurd.
3) Built in support for exceptions, though this is
more of a convenience than part of the object model.
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).
ObjC currently offers only a macro based exception implementation.
Actually, its the Cocoa framework which does this because the language
itself has no support for exceptions whatsoever.
A negative side-effect of the macro implementation is that it adds a
measureable performance overhead to your code, even if it never throws
or catches an exception. The simple reason for this is that the
NS_DURING macro calls the setjmp functions which, besides calling into
the Kernel, dumps the whole CPU user state into a memory buffer. The
user state on a PPC G4, however, consists of 32 32bit integer, 32 64bit
float and 32 128bit vector registers. Saving all this information costs
time. The situation gets worse on the G5 with its 64bit integer
registers.
Exceptions could be handled far more efficiently and in a safer way if
they would be part of the language, so that the compiler could just
save the information really needed by the catch block.
However, things do get better in this regard. Its already public
knowledge that Apple has added "real" exceptions (a-la Java with
finally block) to ObjC in a newer compiler version.
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?
All instance variables of a class are by default protected. All methods
are public. Further, while there is a way to control the access mode of
instance variables, there is no way to control access to instance or
class methods.
I would very much welcome the addition of method access control.
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?
ObjC has no support for name spaces. De facto everyone prefixes his
exported classes and functions with some sort of namespace qualifier.
This works as long as you do not have to incorporate code from third
parties where two of them chose the same prefix...
Again, adding name spaces wouldn't hurd.
Regards,
Dietmar Planitzer
_______________________________________________
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.