Re: Refactoring tools available for Cocoa / ObjC?
Re: Refactoring tools available for Cocoa / ObjC?
- Subject: Re: Refactoring tools available for Cocoa / ObjC?
- From: glenn andreas <email@hidden>
- Date: Wed, 3 May 2006 13:24:14 -0500
On May 3, 2006, at 12:18 PM, Greg Titus wrote:
On May 3, 2006, at 9:30 AM, glenn andreas wrote:
On May 3, 2006, at 11:22 AM, Greg Titus wrote:
The reason is that, just again, whilst in Smalltalk there can be
some (whatever sweet way unknown to me they are achieved and
detected), in ObjC *there are no abstract classes*. Period. You
encounter NSObject instances pretty often, a few times I've even
instantiated NSArrays. I haven't ever instantiate an NSString,
but I bet some other one did :) And so forth.
NSObject and NSArray are not abstract. NSString, on the other
hand, is. If you don't see the distinction, then no wonder you
aren't thinking about this very well.
How do figure that "NSString" is abstract but "NSArray" isn't? As
far as I'm concerned, none are abstract, since, other than the
fact that there is no "abstract class" in Objective-C, with all of
them you can instantiate them, send them messages, etc...:
Turns out both NSArray and NSString are abstract classes, I was
mistaken. Forgive me - in earlier releases NSArray was concrete. It
is now abstract. Try actually logging [[x class] description] in
each case, and you will find that you have actually instantiated
NSObject, NSCFString, and NSCFArray. If you looked at the _actual_
NSArray class, you would find declarations of -objectAtIndex: and -
length which raise exceptions. These are the abstract methods which
must be implemented by subclasses.
You guys are both getting confused by Java/C++ making 'abstract'
into a language keyword. When we are talking about refactoring
tools we are talking about class patterns. Abstract Superclass is a
pattern, not necessarily a language feature. It is _not_ a language
feature in either Smalltalk or in Objective-C. That does _not_ mean
that you can't detect the _pattern_.
So if you want to define an "abstract class" in Obj-C as a class
which has at least one method which must be implemented in a subclass
(and raises an exception if you try to call that method on an
instance of that class or subclass without having overridden said
method), then yes, by that definition, NSArray and NSString are
abstract classes. They are also class-clusters, which is another
thing (and is part of an implementation detail - view it more as an
"optimization pattern" rather than a "design pattern").
Though by that definition, NSObject is also an abstract class,
because -copy will raise an exception (since it calls copyWithZone:
which must be implemented in the subclass), as will -mutableCopy and
(indirectly) -forwardInvocation.
So if you want instead to define an abstract class as the above
refined to only include methods that provide "primitive
functionality" (i.e., the actually get/set an item in an array), then
you've got something that has to be based on the programmer's
intention to determine if it is abstract or not (would "copy" of
NSObject be something that provides primitive functionality or not?)
So what, then, is the definition of an "abstract class" in Objective-
C (since half the people say "no, you can't detect one" and the other
have say "yes, you can" but neither are talking about the same
critter...)
Glenn Andreas email@hidden
<http://www.gandreas.com/> wicked fun!
quadrium | build, mutate, evolve | images, textures, backgrounds, art
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden