Mailing List Archive

Curious about behavior of ref and methods
Given a class Foo, with Instance methods doSomething and new, this

fragment of a Class method has to be written just so to avoid load
and/or run time complaints:

if (ref($myfoo) && (ref($myfoo) eq 'Foo'))
{$myfoo = $myfoo->doSomething ( 'data' => $data );
}
else
{$myfoo = new Foo
('data' => $data, 'filename' => $filename);
}

1) If I don't test the ref for being non zero first, I get a warning about the
compare, ie it doesn't like:

if (ref($myfoo) eq 'Foo')

because the 0 returned at runtime when $myfoo is NOT an object makes the

compare undefined. At the very least this runs counter to the examples in
the manual or else implies that you always KNOW that myfoo is a pointer.

2) If

{$myfoo = $myfoo->doSomething ( 'data' => $data );

is instead written as the more normal (for me!):

{$myfoo = doSomething $myfoo ( 'data' => $data );

it fails at load time. claiming a syntax error near "$myfoo ("

3) Similarly, if


{$myfoo = new Foo
('data' => $data, 'filename' => $filename);

instead uses the $type argument of the method instead of being explicitly
defined:

{$myfoo = new $type
('data' => $data, 'filename' => $filename);

It collect the same sort of load time warning.

I'm curious as to the why's because even if wrong, the code seems

intuitively correct, which makes me wonder about underlying syntax...
Re: Curious about behavior of ref and methods [ In reply to ]
Dale Amon writes:
> if (ref($myfoo) && (ref($myfoo) eq 'Foo'))

This is not a bug, but it should look like

if (defined ref($myfoo) && (ref($myfoo) eq 'Foo'))

I wish that there were a special _undefined_ value sv_undef_nowarn
that would not give a warning...

> 2) If
>
> {$myfoo = $myfoo->doSomething ( 'data' => $data );
>
> is instead written as the more normal (for me!):
>
> {$myfoo = doSomething $myfoo ( 'data' => $data );
>
> it fails at load time. claiming a syntax error near "$myfoo ("
>

This is one of the cases I complained a couple of days ago, about
broken parser for object syntax. Unfortunately, I did not keep an
archive of constructions that refuse to compile, but there were
plenty.

> 3) Similarly, if
>
>
> {$myfoo = new Foo
> ('data' => $data, 'filename' => $filename);
>
> instead uses the $type argument of the method instead of being explicitly
> defined:
>
> {$myfoo = new $type
> ('data' => $data, 'filename' => $filename);
>
> It collect the same sort of load time warning.

Well, there is no difference at compile time between 2) and 3), right?

Ilya
Re: Curious about behavior of ref and methods [ In reply to ]
Thanks - you pretty much confirmed my suspicions, ie that the first
one is an annoying fall out caused by having false and undefined look
the same; and that the other is a an actual compiler bug.