Re: Java vs. Objective-C for Cocoa

FROM : Marcel Weiher
DATE : Sun Apr 24 00:13:19 2005

On 23 Apr 2005, at 21:29, Ondra Cada wrote:
> On 23.4.2005, at 20:15, Rick Kitts wrote:
>

>> ... XCode is, in my estimation, bronze age largely because it
>> appears to not assist in agile methods. In particular it doesn't
>> well embrace refactoring.

>
> Definitely. The reason is also well-known: it's since that what you
> Java folk understand under the name is plain impossible for
> Cocoa/ObjC/meta-programming based development.


Sorry Ondra, that is simply not true.  Refactoring (and especially the
Refactoring Browser) come from Smalltalk, and I hope you're not going
to try and argue that Smalltalk has a less powerful meta-programming
facility than Objective-C?

[snip]


>
> - target / action paradigm: try to change an action method of class A
> without changing the same action method of class B, and then fix all
> the NIBs accordingly :)
> - First Responder stuff (remember? Any object can send any message to
> the responder chain -- without a clue which instance of which class
> happens to be the one who gets it at the moment)
> - categories, poseAsClassing, message forwarding: are you quite aware
> that it is pretty common that a class which does not implement xxx,
> and none of whose superclasses implements xxx, actualy *does respond
> to* xxx?
> - KVC/KVO/bindings: pray tell me, how do you want to change a method
> name of one class so as the KVC/bindings, where the method happens to
> be called by name, which name happens to be stored in somewhere
> (might be a NIB, might be a model, might be a plist, might be
> anything) works appropriately?


Actually, I would say that it KVC/KVO/bindings are the culprit here, by
encoding important structural information ("code" by any other name) in
unchecked, usually string-based data structures.

> And more and more, there's Core Data, which probably exploit similar
> techniques, there's HOM -- agreeably not a standard part of Cocoa,
> but, far as I can say, pretty often used (and *should* be used even
> more often -- heck, in my personal opinion Apple should embrace HOM
> into Foundation!), and more.
>
> The trick is, with those "re-factoring" tools you break reflection in
> your plain Java, but you rightfully don't care, for reflection is
> hardly ever used. The extreme power of Cocoa though is based
> *especially* on (an ObjC rough equivalent of) reflection.


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...)

>> From other comments on the list it is evident that folks unexposed
>> to refactoring with an intelligent editor (i.e. non-Java coders)
>> don't grok the value of this

>
> Quite the contrary: we who use a decent API which massively exploits
> the charm of meta-programming based on (a rough equivalent of)
> reflection know quite well that (a) re-factoring (alas) cannot be
> automated (that is, not this way, there may be a different one I
> don't know of), (b) the advantages are *definitely* worth to.


Once again:  Smalltalkers who use the Refactoring Browser AND use
meta-programming are going to disagree with you rather vehemently.

[snip]

Cheers,

Marcel


--
Marcel Weiher                          Metaobject Software Technologies
<email_removed>        www.metaobject.com
The simplicity of power            HOM, IDEAs, MetaAd etc.
        1d480c25f397c4786386135f8e8938e4