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 10:14:12 +0100
On 3 May 2006, at 03:14, Ondra Cada wrote:
On 3.5.2006, at 2:11, Marcel Weiher wrote:
The simple fact (which you keep ignoring) is that refactoring
tools were invented in Smalltalk.
Erm... no, I don't think I "ignore" anything. Just I judge some
things irrelevant.
Well, the fact that these tools not only exist but also were invented
on Smalltalk makes all theoretical arguments as to why they "can't"
exist for a dynamically typed language irrelevant, because they
obviously do.
This is the same as with any other theoretical argument: if the real
world demonstrably contradicts your theory, then it's time to scrap
your theory.
[regex, s&r, c&p discussion]
It is obvious that you can accomplish any refactoring task by manual
editing, and that it helps if that manual work is assisted by (regex-
powered) search/replace. In fact, that is how I currently do my
refactoring, because I use Xcode for both my Objective-C and my Java
coding. However, doing it this way is considerably more arduous/
painful than it needs to be. In fact, I was considering using
Eclipse for some refactoring tasks, and if you knew how deeply and
fervently I loathe that piece of software, you'd know I'd only
consider it if there were significant pain to be avoided.
For example, regardless where and how refactoring was invented, it
still has no reliable way to decide which class the message
"intValue" in [[array lastObject] intValue] belongs to
Is it in any way worse than a regex search? If not, why is this
objection at all relevant? Furthermore, based on my practical
experience with refactoring, I doubt that refactoring of such a
generic method is at all relevant.
There may be a point in such a tool if it can do things which (a)
reliably enough (b) considerably more easily than other tools
(namely regexp search&replace) would allow. All right, point out a
few such things.
Extract method.
Push/pull method/instance var down/up.
I've read wiki.cs.uiuc.edu/RefactoringBrowser/Refactoring+Browser's
+Refactorings up and down. All the tasks outlined there I can do
with a regexp s&r(*) easy enough.
Say, how do you, for example, "push down method"? Unless I got the
operation completely wrong from the description,
(i) you move its declaration and definition into another source
(**), that's easy enough with plain copy&paste without any special
tool at all;
Oh, let's look at the definition of "push down method" at http://
www.refactory.com/RefactoringBrowser/Refactorings.html :
"Push Down: Pushes a method down into all subclasses that don't
implement the method. This can only be allowed if the class is abstract"
(ii) now you would like to check all [[enum nextObject]
thePushedMethod] (and similar) cases in all project sources so as
you know whether [en nextObject] happens to be the subclass (in
which case it is all right) or whether it is the now method-less
superclass (in which case you have to change the code).
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 ------------
Well the description at wiki.cs.uiuc.edu/RefactoringBrowser/RB's
+Push+Down+Method does not help much in letting me know whether it
does this check at all (and if so how),
It doesn't do this precise check, since what you propose is
insufficient. It (a) pushes the method down to all subclasses that
don't implement it already, and then only does it if the class the
method was pushed from is abstract, and it has considerable smarts
for figuring out what is an abstract class.
[snip]
not that great feat, especially given that in ObjC (unlike
Smalltalk) "a:b:" and "b:a:" are utterly different things.
This is wrong. a:b: and b:a: are different selectors in Smalltalk
just as they are in Objective-C.
(*) presumed it supports properly NIBs and data models:
That is something a smart refactoring tool could do much better than
regex, as it could, for example, read a binary nib and look inside
that. Or a .wod file, for what it's worth. Good old polymorphism at
work...
For example, the Refactoring Browser already looks at (some) strings
and adjusts those:
---- snip ---
Rename: This refactoring renames a class and also renames every
reference to the class in the code. Even symbols with the same name
as the class will also be renamed so that "Smalltalk at: ..." will
work. However, if you are constructing class names using the asSymbol
message, then those strings will not be renamed.
---- snip ---
(***) which, I do agree, would help: I've got proficient enough in
writing things like "\[(.*) rangeOfString:(.*) options:(.*) range:
(.*)\]", but still it could help if this is done semi-automatically.
It absolutely would help.
Still it would be "only" a smarter syntax-aware regexp
No, it can be much more than that, because the refactorings (a) are
thought out to actually be behaviour preserving and (b) do a lot of
work behind the scenes automatically and safely, that would otherwise
be a series of manual search + edit steps.
(a thing in my personal and perhaps worng opinion in dire need for
Xcode, unlike a refactoring tool).
Well, there we agree: Xcode needs to be fixed first.
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