FROM : Ondra Cada
DATE : Sat Apr 23 23:41:02 2005
Thomas,
On 23.4.2005, at 22:43, Thomas Davie wrote:
> 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.
Just tell me how.
Take the simplest possible case: there is a menu item in the main menu,
which sends a message "doThis:" to a MyView instance, which just
happens to be the First Responder.
There is another, completely unrelated view, which happens to have a
method "doThis:". That view's window's controller disables the
aforementioned menu item through menu validation, so its truly
independent.
You decide to re-name the latter "doThis:" (the one which is not called
from main menu) to "doThat:".
Of course the tool can easily find in the NIB that "doThis:" is
sent(*). How on earth though would it know whether the actual receiver
is an instance of the former class, or an instance of the latter one?
You do know it, since you have written the code. An automatic tool
though would have to analyze the code as for its dynamic behaviour --
which ages ago Turing proved is impossible.
(*) which would, incidentally, not be so in many other cases, when the
message name is stored in an app-proprietary structure the toolchain
knows nothing of.
---
Ondra Čada
OCSoftware: <email_removed> http://www.ocs.cz
private <email_removed> http://www.ocs.cz/oc
DATE : Sat Apr 23 23:41:02 2005
Thomas,
On 23.4.2005, at 22:43, Thomas Davie wrote:
> 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.
Just tell me how.
Take the simplest possible case: there is a menu item in the main menu,
which sends a message "doThis:" to a MyView instance, which just
happens to be the First Responder.
There is another, completely unrelated view, which happens to have a
method "doThis:". That view's window's controller disables the
aforementioned menu item through menu validation, so its truly
independent.
You decide to re-name the latter "doThis:" (the one which is not called
from main menu) to "doThat:".
Of course the tool can easily find in the NIB that "doThis:" is
sent(*). How on earth though would it know whether the actual receiver
is an instance of the former class, or an instance of the latter one?
You do know it, since you have written the code. An automatic tool
though would have to analyze the code as for its dynamic behaviour --
which ages ago Turing proved is impossible.
(*) which would, incidentally, not be so in many other cases, when the
message name is stored in an app-proprietary structure the toolchain
knows nothing of.
---
Ondra Čada
OCSoftware: <email_removed> http://www.ocs.cz
private <email_removed> http://www.ocs.cz/oc






Cocoa mail archive

