Cocoa mail archive
Re: Java vs. Objective-C for Cocoa
FROM : Thomas Davie
DATE : Sat Apr 23 22:43:18 2005
>> ... 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
DATE : Sat Apr 23 22:43:18 2005
>> ... 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
