Re: Java vs. Objective-C for Cocoa
Re: Java vs. Objective-C for Cocoa
- Subject: Re: Java vs. Objective-C for Cocoa
- From: Thomas Davie <email@hidden>
- Date: Sat, 23 Apr 2005 21:43:18 +0100
... 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.
As I wrote a few times already, the trick is that Java (at least
far as those "re-factoring IDEs" know, it is a tad better with Java/
Cocoa, which uses NSSelectors pretty often) *does not* support a
big number of hi-level meta-programming paradigms, each of which
renders things like "the IDE knows for a message sent which method
of which class will be called" alas a nonsense. Just take:
- 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?
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.
Far as you see the sources as plain text and are aware of this POV
limitations, it's all right: use regexps or tops (which migh be
integrated into Xcode perhaps, though myself, I prefer regexps to
tops). As soon as you presume the tools actually understand the
messaging/class structure, oops. They do not and can not, for the
structure is *completely* dynamic, those tools are static. Game over.
Your main argument here appears to be that you can't tell what relies
on the code you're re-factoring... a binding somewhere could,
something in the nib somewhere could etc. I'd argue that this is no
barrier to re-factoring – the Haskell re-factoring project here at
Kent is perfectly capable of going and finding all the dependent
files and re-factoring them too.
But it's serviceable.
That all said, Xcode *could* improve many things, that's for sure!
And it *could and should* learn from other IDEs. But the automatic
re-factoring is not one of the things it could learn, for the
reasons stated above.
And of course, re-factoring *is* a tedious work, and it would be
*great* to have an automatic support for it. Alas, the way of the
strong-typed Java without a reflection (or with so little of it
that you can afford to ignore it) just can't be used efficiently in
a dynamic system, which hugely exploits meta-programming
techniques. Perhaps a better way can be found, but myself, at the
moment, I know of none but using the good old human brains. Them
computers are great for many things, but -- at the moment -- they
still are not intelligent enough for the task.
I think that arguing against re-factoring is particularly narrow
minded. I know that I spend a lot of my time re-factoring my code,
and any of that process that can be automated, I want to be
automated. Perhaps it is harder when using Obj-C (although you're
yet to convince me of this), but that's no reason for Apple (or some
random university) doing the research and making it work.
Bob
_______________________________________________
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