On Fri, Sep 08, 2000 at 01:59:30PM +0100, Piers Cawley wrote:
> Michael G Schwern <[EMAIL PROTECTED]> writes:
> > It may be good for rapid development projects, but I don't think we
> > should apply it to Perl.  
> 
> I want to be able to do it with Perl. Not sure I want to do perl with it.

Perl perl PERL p3rl PeRl  AUUUGGHH!  I ment "perl".

There's something to be said for case insensitive languages.


> I'm not entirely sure that 'refactoring' means what you think it
> means. Refactorings rewrite code to make it better. The dynamic or
> otherwise nature of the code is irrelevant.

Yes, you're right.  I just don't consider refactoring as a formal
technique to be useful unless it can be automated, given the large
scale of the changes necessary (in any decently large chunk of code).
Otherwise its just "changing the code".

<Krusty>I'm a lazy, lazy man.</Krusty>


> > Furthermore, refactoring loses much of its power when applied on
> > Open Source libraries since you are no longer in control of all code
> 
> Your point. But you can still refactor and leave the old interface in
> place but deprecated.

That means you have to change the name of the routine(s) effected each
time.  Bleh.


> Hmm... assuming you're talking about Martin Fowler's text on
> refactoring then most of the examples I've seen can be easily used in
> Perl programs or are unnecessary because of the nature of perl.

Yes, some are unnecessary.  A few can be automated.  The rest are next
to impossible to automate due to the dynamic nature of Perl.
Basically, the major problems are:

    AUTOLOAD
    $obj->$method();   # calling a method with a variable
    Symbolic references
    *foo = $sub_ref;   # dynamically generated subroutines
    Dynamic subroutine arguments

These kill most attempts at lexical analysis of Perl code.  If you can
guarantee they won't be there, things get alot easier.  But I use them
all the time.

Still one could probably automate some refactorings which will be
correct 80% of the time.  Not good enough for general use (most people
don't have unit tests) but perhaps for private.


-- 

Michael G Schwern      http://www.pobox.com/~schwern/      [EMAIL PROTECTED]
Just Another Stupid Consultant                      Perl6 Kwalitee Ashuranse
I'm successful because I'm lucky.   The harder I work, the luckier I get.

Reply via email to