Re: Java vs. Objective-C for Cocoa
Re: Java vs. Objective-C for Cocoa
- Subject: Re: Java vs. Objective-C for Cocoa
- From: Ondra Cada <email@hidden>
- Date: Sat, 23 Apr 2005 22:29:32 +0200
Rick,
I fear I have to respectfully disagree.
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.
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.
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.
(I suspect this is driven primarily by the perspective of relatively
small code bases).
Would e.g., 800 000+ source lines of a project made twelwe years ago
for NeXTStep and actively used and maintained still in Mac OS X do to
qualify? :)))
Truth is though that Cocoa code base tends to be *far* smaller than
what other APIs need for the same task -- I guess to approach the same
functionality (if ever possible which I doubt) in Java at the very
least twice the number of source lines would be needed. Nowadays, when
we got bindings it is even more so: we indeed tend to have *much*
smaller code bases -- for they are sufficient to do the job.
The catch is that *exactly* those features which allow a Cocoa project
of, say, 10 000 source lines to offer more than a Java/Swing project of
100 000 lines, are the very very same ones which prevent the automatic
re-factoring you are longing for.
What the intelligent editor allows is extremely rapid and natural
transitions between levels of the code base. Finding all classes that
implement an interface or derive from a class is one relatively high
level view.
This can be done easily, far as I know the current Xcode 1.5 supports
it already, but it is very seldom ever needed (far as I can say).
Trick is, in Java the class structure is *important*. In ObjC it is
not: we got a real polymorphism, meaning we can (*without* reflection!)
send a message "copy:" to an object without knowing which class it
belongs to. The thing works properly for *different* classes each of
which implements its own "copy:", without inheriting it from a common
superclass or interface. That is not possible in Java (without
reflection).
Also, since a vast majority of protocols are (for good reasons)
informal ones; therefore an answer to the "who implements an interface"
question, whatever prompt, does not really help anything :)
Meanwhile the editor annotates the code view such that I can tell if a
particular method is an override or an implementation with 0 clicks
and less thinking.
*Each* implementation *can* be in fact an override and vice versa --
take categories or poseAsClassing. Take an override of valueForKey: --
which methods would you link it to as an override? :)
The trick is, again, that the static information your "re-factoring"
tool happens to have access to does not help much with how the things
will look at runtime. To figure the latter, you need a human
intelligence -- at least as of today. In future, perhaps, some AI may
be able to do that, though I personally doubt it.
When I want to override a method or implement a protocol I want to
type, say, Command-O(verride), get a list of methods I can override,
click on one of them, have XCode put in an empty def and put the
cursor at the first logical place to type. I mean, really, it's a
computer. Why is it making me think so much about this book keeping
crap?
In the bronze age :) this would be a nice idea indeed: to be able to
select, say, the NSTableViewDataSource informal protocol, choose
whether the table is editable or not, and let a macro generate the
method skeletons would be nice a couple of years ago.
There's no need for such things anymore though: we got bindings.
Today, you might consider it still nice for things like archiving. Not
for long: in a week, Core Data will come.
Anyway, bronze age, as I say.
Quite the contrary. Cocoa is far beyond the primitive approach Java
with its strong typing takes. That's why it does not have, in principle
can not have (and also does not need) the tools which are designed for
the mentioned approach.
You know, it's kind of like you blamed an aircraft workshop for a lack
of riveter, not knowing today things are glued together :))
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.
---
Ondra Čada
OCSoftware: email@hidden http://www.ocs.cz
private email@hidden http://www.ocs.cz/oc
_______________________________________________
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