From: Lothar Scholz <mailinglists@...>
Date: 2003-08-14T20:36:14+09:00
Subject: Re: AW: [ann] AEditor 0.10, folding added

Hello Geoff,

Thursday, August 14, 2003, 10:52:18 AM, you wrote:

GY> The parser would be the easy part (probably).

Right. Stealing it from the ruby source code does not take a long time.
The biggest problem is that no one seems to be interested in
maintaining a precise BNF grammer of the language. With the grammer and bison
it shouldn't take longer then a day.

GY> Once you have the parser, consider renaming the method Foo#bar to
GY> Foo#foo():

GY> ------8<-----
GY> class Foo; def bob; end; end
GY> class Bar; def bob; end; def foo; Foo.new; end; end

GY> a = Foo.new
GY> b = Bar.new
GY> a, b = b, a

GY> a.bob
GY> b.bob
GY> ------8<-----

GY> So far, it would be relatively simple to track variable assignment and
GY> work out which variables are instances of Foo and then rename references
GY> from Foo#bob() to Foo#foo

tracking variable assignment becomes an O(exp n) problem if you must
follow all paths. So its really unuseable in real world code.

GY> And although in the code above, you could determine fairly easily what
GY> type of object will be returned by Bar#foo(), it would be very easy to
GY> think of situations where it wouldn't be easy and, in the case of
GY> compiled C extensions, not possible.

I was thinking a while about tracking the types of arguments and
results during the runtime of testcases. But this was only to support
more exact tooltips (code insight). It is very obvious to see that
tracking information at runtime can only give a partial set of
information.

GY> AIUI, refactoring is supposed not to change the behaviour of the code:

Right, i think that when you offer refactoring, a lot of programmers become
more lazy in the design phase. And this is bad, because refactoring in
Ruby/Python/PHP/Perl can't do the same as refactoring in java. They will run
into problems very soon and much sooner if the projects are growing and
become multi person projects where everyone has it's own coding style.

GY> The problem could be partially solved by designing strict rules for
GY> writing a style of Ruby which could be refactored in well defined ways,
GY> but I don't think that it would be feasible to do for an otherwise
GY> unknown Ruby script.

And this would eliminate the elegance of some ruby solutions and
eliminate quite a few reasons to use ruby. So it's not a good
decision.

-- 
Best regards,
 Lothar                            mailto:mailinglists@scriptolutions.com