Robin Houston <[EMAIL PROTECTED]> writes:
> On Wed, Oct 24, 2001 at 12:35:31PM +0100, James A. Duncan wrote:
>> I was under the impression that code spat out by B::Deparse was
>> passing any test that wasn't reliant on order of BEGIN blocks (and
>> therefore things like pragmata where a little bit squew whiff[0]).
>
> That accounts for 90% of the problems. There are a few other issues
> too: for example if you inline pathological scalars, it's not obvious
> what to do:
>
> use constant lunacy => ($! = 5);
> my $zero = 0;
> print lunacy, $zero + lunacy;
>
> because B::Deparse will find an apparently literal constant which
> can't actually be written as a simple literal.
>
> Also, if you have
>
> sub CORE::GLOBAL::close { die "ha ha ha" }
> CORE::close (FOO);
>
> Then B::Deparse will Do The Wrong Thing. The obvious solution to that
> problem would be to *always* output calls to builtins as CORE::keyword
> -- but then readability suffers.
Hmm... readability is definitely an issue here, given that refactoring
is about improving readability...
> I do think that it's pretty good in the real world though, most of the
> time. It's certainly a *lot* tighter than it used to be.
Great. Actually, a good refactoring browser should let the user
eyeball the changes before it makes them, so there's always going to
be the opportunity to change the the generated code by hand (but that
introduces risk too. Best to 'extract method', then 'rename variable'
within the method to refactor it.)
I think I need to go away and read up on how the SmallTalk thing does
its magic (and any other literature on this). If we can get 'extract
method' working with perl 5 that will be *wonderful*.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
