Re: Java vs. Objective-C for Cocoa
Re: Java vs. Objective-C for Cocoa
- Subject: Re: Java vs. Objective-C for Cocoa
- From: Marcel Weiher <email@hidden>
- Date: Sun, 24 Apr 2005 09:41:27 +0100
On 23 Apr 2005, at 23:30, Ondra Cada wrote:
You can find info on the Refactoring Browser at:
http://st-www.cs.uiuc.edu/users/brant/Refactory/
Yes and no. In theory, HOM does not bring (almost) anything new to
the "refactoring problems area". It, though -- and do please correct
me if I am overlooking something important -- considerably emphasizes
many of them which, in non-HOM environment, stay more or less latent.
Not that I can see.
An actual example: although the functionality is available for a long
long time, it is not too common to use a code like
[array makeObjectsPerformSelector:@selector(whatever)]; //1
and I daresay it is betwixt Cocoa programmers rather common to write
the explicit code of kind
for (NSEnumerator *en=[array objectEnumerator],Foo *foo;foo=[en
nextObject];) [foo whatever]; //2
You seem to think that refactoring is somehow type-dependent. I can't
think of a refactoring that is, especially as refactorings are
*behaviour-preserving*.
On the other hand,
[[array each] whatever]; //1
[[array do] whatever] would be more correct...
is extremely common with HOM, being almost an archetypal HOM example.
result = [[array collect] something] or queryResult = [[array
select] myPredicate..] are actually more common, in my experience.
I may be wrong (well I was often enough in the past), but I cannot
see a reasonable re-factoring algorithm for "whatever" in those //1
cases, due to the fact Cocoa containers are completely typeless. That
in //2 the re-factoring tool can do much better is self-evident.
Refactoring has nothing to do with type. If you rename the method
'whatever', you just change all senders. Of course, something like
"find all senders" and "find all implementors" etc. has been part of
Smalltalk browsers since the neolithic...
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