Re: Refactoring tools available for Cocoa / ObjC?
Re: Refactoring tools available for Cocoa / ObjC?
- Subject: Re: Refactoring tools available for Cocoa / ObjC?
- From: Marcel Weiher <email@hidden>
- Date: Wed, 3 May 2006 21:09:08 +0100
"When people react instantly, they’re not thinking, they’re doing a
table lookup." -- Alan Kay
On 3 May 2006, at 16:44, Ondra Cada wrote:
a) a class that _cannot be_ instantiated, or (e.g. C++ a class
with pure virtual functions, Java abstract class)
(a) this (with an appropriate language support) is the only way a
re-factoring tool can take abstractness (ugh, is there such a
word? :)) into account.
This turns out not to be the case. I really suggest you take Greg's
advice and read how it works. Or, you could have read it in my post,
the one that you were responding to...
Begin forwarded message:
As you describe it, the transformation is not behavior-preserving,
the method used by the Refactoring Browser is. And you might
wonder about this "abstract class" business:
---- http://st-www.cs.uiuc.edu/users/brant/Refactory/ ------
How does the Refactoring Browser determine if a class is abstract?
Smalltalk doesn't have any language feature that denotes an
abstract class like C++ or Java. As a result, we check for a couple
things when looking for an abstract class. If the class contains
any method that sends #subclassResponsibility, the we consider the
class as abstract. A method that sends subclassResponsibility
signifies that users should override this method in every subclass
to have all the class' functionality to work. Another check we use
to determine if a class is abstract is to look for references to
the class. If the class is not referenced then the class is
considered to be abstract, since there is no way to create an
instance of the class.
Why does the Refactoring Browser care if a class is abstract?
The Refactoring Browser can only perform some refactorings if the
class is abstract. For example, it can only push a method down if
it can determine that the method can never be called on the class
that the method is being pushed out of.
------- snip ------------
This is a heuristic, and it is obviously possible to get around the
heuristic to make things break.
This is only a problem with the straw-man you've constructed, which
appears to be along the lines of "the refactoring tool makes absolute
guarantees and relieves you, the programmer, of all responsibility
for a refactoring."
This simply isn't so, no such claim has been made. You, the
programmer, are still responsible for your refactorings, just like
you are with any other modification you make to the code. You just
get a lot better support for making the change, meaning that (a) your
workload is dramatically reduced and (b) the chances of you breaking
code by doing the refactoring are dramatically lower.
Also, it is obviously possible and most likely useful to adapt this
and other heuristics to the environment, in Cocoa this would mean
looking for NSClassFromString(), @selector(), NSSelectorFromString(),
key-value-paths and nibs, etc.. Furthermore, a good refactoring tool
makes such things extensible, as I think the RB does.
So, just get rid of the straw-man and be happy... :-)
Cheers,
Marcel
_______________________________________________
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