Michael G Schwern <[EMAIL PROTECTED]> writes:
> On Thu, Sep 07, 2000 at 01:49:36PM -0400, Peter Allen wrote:
> > They have a catchy slogan for it. They call it the
> >
> > test --> code --> design
> >
> > development cycle.
>
> That sounds bad. I've heard about this style. Code now, refactor
> later. Its supposed to avoid the need for sweeping architectural
> decisions early in the project, allow you to recover from bad design
> decisions and return flexibilty to old code.
>
> 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.
> We have a very good idea of what our requirements are (especially
> compared to most software out there), a solid prototype to work from
> (perl 5), and some very solid ideas of what the architecture should
> be. Furthermore, I don't think there are any refactoring tools for
> C. I've only heard of them for Java and Smalltalk (maybe C++).
Refactoring is a process that can be done with tools, or it can be
done by hand. With tools is easier. I have a dream that one day it
will be possible to write refactoring tools for perl code, but the old
fashioned doing it by hand with a bunch of unit tests to catch
stupidity is good enough 'til then.
> Refactoring is simply the automated alteration of code without
> effecting its purpose. A simple example would be reversing the order
> of arguments in a subroutine. A refactoring tool would be able to do
> this for you automatically and in all code which uses that subroutine.
> Handy. It does this by defining a set of simple operations which a
> refactoring tool must be able to perform. From those simple
> operations, it can do much more complicated things.
>
> Unfortunately, Perl's dynamic nature makes most refactoring
> impossible.
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.
> Furthermore, refactoring loses much of its power when applied on
> Open Source libraries since you are no longer in control of all code
> which uses said library. In a controled environment, you can alter
> interfaces to your heart's content. With Open Source, if you alter a
> function's interface you may break the code of hundreds of programs.
Your point. But you can still refactor and leave the old interface in
place but deprecated.
> Still, it has its uses and can be helpful in localized parts of the
> code. I've been going through the catalog of refactorings and trying
> to determine what can currently be done in Perl and how much change in
> Perl it would take to reimplement the rest. It doesn't look good, but
> I'll publish what I've got once its complete.
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.
--
Piers
