You have 3 situations
1 the refs came from \&somefunc
2 the refs come from evaling strings of code
3 the refs are closures and therefore have some data associated with them
For 3, it looks like B::Deparse does't handle the data at all so even
if the deparsed subs are identical they may behave totally
differently.
For 1 a simple comparison does the trick.
For 2 B::Deparse works and might be the only way but then again, it
might be better to just get access to the original string of code
before it gets compiled,
F
On 6/26/05, David Landgren <[EMAIL PROTECTED]> wrote:
> Tels wrote :
> > -----BEGIN PGP SIGNED MESSAGE-----
> >
> > Moin,
> >
> > On Sunday 26 June 2005 07:18, Collin Winter wrote:
> [...]
> >>After tinkering with B::Deparse for a bit, I think this particular
> >>"oddity" may just be a result of poorly-written docs (or, more
> >>probably, poorly-read on my part). The module seems to do the right
> >>thing in all cases I could come up with (i.e., it only optimises out
> >>truly-useless constants), so it should be safe to use for this
> >>particular purpose. With this matter sorted, I've started on the code
> >>and requisite tests to make the new stuff work.
> >
> >
> > Just for clarification: this means that:
> >
> > is_deeply( sub { 1 + 2; }, sub { 3; } );
> >
> > should/will pass because the subs compile to the same code?
>
> is_deeply( sub {cos(0) + sqrt(4)}, sub {3} );
>
> does as well, fwiw. So do looping constructs that map to the same thing:
>
> is_deeply(
> sub { my $x=0; $x += $_ for 1..10; $x },
> sub { my $x=0; for( 1..10 ) { $x += $_ }; $x },
> );
>
>
> Michael Schwern wrote at the beginning of this thread:
>
> > What it *shouldn't* do is what Test.pm does, namely execute the
> > code ref and compare the values returned. It would just compare
> > the refernces.
>
> Why should it not do that? Is this because of subs with side effects?
> Isn't that more an issue of "Doctor, it hurts when I hit my knee with a
> hammer"?
>
> David
>
>
