Re: Refactoring tools available for Cocoa / ObjC?
Re: Refactoring tools available for Cocoa / ObjC?
- Subject: Re: Refactoring tools available for Cocoa / ObjC?
- From: Greg Titus <email@hidden>
- Date: Wed, 3 May 2006 09:22:20 -0700
On May 3, 2006, at 8:53 AM, Ondra Cada wrote:
Greg,
On May 3, 2006, at 5:22 PM, Greg Titus wrote:
Try actually reading about the Smalltalk refactoring browser and
Smalltalk in general. There is no 'abstract' keyword or equivalent
in Smalltalk either, but it still is possible to determine
abstract classes. You could use exactly the same methods to
determine abstract classes in Objective C.
Although I agree I am not a Smalltalk guru by far, I can still say
that's wrong.
Maybe you should reserve judgement until you learn how Smalltalk does
it, as I suggested.
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.
As I've said, I am about to study the Smalltalk refactoring (am
actually looking forward to that), but regardless Smalltalk-
savviness, I do know ObjC pretty well. There is *no way* to use and/
or detect abstract classes reliably there (unless compiler and
runtime both get seriously limited). Sure, the tool may scan the
project whether the class is instantiated or not--which is bound to
fail since a class may be instantiated dynamically without ever
mentioning its name anywhere. Or from a loadable bundle. And so
forth...
Smalltalk has exactly the same issues. Think about what an abstract
class means (method signatures declared without filling in
implementations) and then go read the Cocoa documentation on -
doesNotRecognizeSelector:. Well formed abstract classes should be
calling this method on themselves for their abstract methods. A tool
can easily determine if any such simple self-calls of this selector
exist. Thus a tool can determine abstractness of Objective-C classes.
In Smalltalk this is done by looking for use of the
#subclassResponsibility method (which was incidentally, declared on
NSObject in OpenStep but apparently dropped for Cocoa).
Note that refactoring assumes - to a certain extent - well-formedness
of the code base you are refactoring. Certainly you could create a
class which ought not to be instantiated but doesn't use this
pattern, and then the automated tool wouldn't find it. Just like you
could replace all the language keywords with #define macros to make
the language look nothing like C and syntax coloring wouldn't work.
That doesn't make syntax coloring useless.
- Greg
_______________________________________________
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