FROM : Ondra Cada
DATE : Sun Apr 24 00:30:22 2005
Marcel,
(cannot argue about Smalltalk -- did not used the thing myself for too
many years, forgot too much. Perhaps Smalltalk uses better paradigms
for metaprogramming than Cocoa, I would not argue that. May you perhaps
show us what Smalltalk uses instead of, say, Cocoa bindings, and how it
gets automatically re-factored?)
On 24.4.2005, at 0:13, Marcel Weiher wrote:
> I don't really see your point here. Certainly something like HOM is
> largely transparent to refactorings (maybe apart from the __ trick it
> needs for another couple of days...)
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.
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
On the other hand,
[[array each] whatever]; //1
is extremely common with HOM, being almost an archetypal HOM example.
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.
---
Ondra Čada
OCSoftware: <email_removed> http://www.ocs.cz
private <email_removed> http://www.ocs.cz/oc
DATE : Sun Apr 24 00:30:22 2005
Marcel,
(cannot argue about Smalltalk -- did not used the thing myself for too
many years, forgot too much. Perhaps Smalltalk uses better paradigms
for metaprogramming than Cocoa, I would not argue that. May you perhaps
show us what Smalltalk uses instead of, say, Cocoa bindings, and how it
gets automatically re-factored?)
On 24.4.2005, at 0:13, Marcel Weiher wrote:
> I don't really see your point here. Certainly something like HOM is
> largely transparent to refactorings (maybe apart from the __ trick it
> needs for another couple of days...)
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.
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
On the other hand,
[[array each] whatever]; //1
is extremely common with HOM, being almost an archetypal HOM example.
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.
---
Ondra Čada
OCSoftware: <email_removed> http://www.ocs.cz
private <email_removed> http://www.ocs.cz/oc






Cocoa mail archive

