Re: Objective-C Question
Re: Objective-C Question
- Subject: Re: Objective-C Question
- From: Marcel Weiher <email@hidden>
- Date: Mon, 22 Sep 2003 17:57:21 +0100
On 22 Sep 2003, at 12:38, Steve Ehrenfried wrote:
--- Marcel Weiher <email@hidden> wrote:
Easy: think superclasses. Objective-C is (for most
practical
purposes) single-rooted.
Do you mean you can subclass a category, or do you
mean that the methods in the category get inherited by
all subclasses of the class that a category was added
to?
The latter.
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" ;-)
I'm not familiar with AOP, so I won't debate it, but I
was merely pointing out what a Cocoa author had
written about it. He cited that there are several
"large teams" that frown on over use of categories.
I'm sure they have their reasons based on experience.
It made sense to me. The author didn't say that
categories should never be used or that they shouldn't
be "liked". He simply cautioned against their
over-use.
Powerful features are generally dangerous when overused, as "over-"use
also usually implies mis-use.
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.
I have to strongly disagree here. There are several
valid uses of it.
Name one.
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.
OK, I'll be more specific in my question. In languages
like Java or C++ you can implement whatever methods
you like, but if a class doesn't have implementations
for all the methods defined in it and its
superclasses, you can't instantiate it.
And this is helpful exactly how? I can't recall a single instance
(sic) of ever having an abstract superclass instantiated accidentally.
Furthermore, if it ever *did* happen, such a case would fail your unit
tests instantly.
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.
You don't have to catch every exception in Java; it
can be passed on.
Passing the burden, in a burdensome fashion.
You don't say why you think it is a
"horrible mis-feature".
Because it clutters your program with useless declarations and/or code,
distracting from the essential.
It's a great feature if used
right; not every function has to throw something. I
like it because it simplifies error handling, and the
exceptions a method can throw are self-documented. I
take it you just don't like Java and therefore
anything that is Java-only is therefore bad.
Not at all, it is the other way around: they just managed to pile on
mis-feature on mis-feature, with complete and utter inconsistency.
Language-enforced levels of access control are yet
another quite
unnecessary "feature" that just complicate the
language without
actually adding tangible benefits.
In that case Objective C sucks too.
I totally agree with you that varying protection levels of instance
variables are one feature of Objective-C that is rather useless (it was
added later, too).
I subsequently
found out that Obj C supports access control for
instance variables, just like C++ and Java. Perhaps
not a lot of people use it.
I think you might be right, though I haven't taken a poll. I actually
have used it once in MPWFoundation, to make a single instance variable
of a single class public, but I could have used the @defs() construct
just as well, which was always part of the language.
Marcel
_______________________________________________
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.