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: Sat, 23 Apr 2005 23:13:19 +0100
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@hidden www.metaobject.com
The simplicity of power HOM, IDEAs, MetaAd etc.
1d480c25f397c4786386135f8e8938e4
_______________________________________________
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