in reply to Re: OO-call bug uncovered & autovivified functions: defined? exists?
in thread OO-call bug uncovered & autovivified functions: defined? exists?

If you remove this behavior then it will be required that all subroutines be defined before ever being referred to.

Could you please substantiate this? I don't see why the autovivifying behaviour of \&foo is required to call functions not yet defined. In fact, the doesn't seem to be any such need currently. 

>perl -e"print exists(&foo)?1:0; exit; foo();"
0

[download]

It's perfectly fine behaviour for sub foo; to create a stub, but that's an unrelated matter.

Replies are listed 'Best First'.
Re^3: OO-call bug uncovered & autovivified functions: defined? exists?
by Somni (Friar) on Oct 29, 2007 at 01:20 UTC
    Consider, you take a reference to \&foo in one part of your code. No symbol table entry is created, but somehow taking the reference Just Works. Later in the same code another reference is taken, \&foo. If no symbol table entry is created, how can these two references refer to the same subroutine?

    There has to be some agreement on what underlying subroutine these two references refer to. This has to agree with the subroutine body that, supposedly, is eventually created.

[reply]

      I see what you mean, but I don't see that as a requirement. The first reference taking could just as easily return undef. In the odd (strange and rare) case you need to take a reference to a function that hasn't been compiled yet, you could always declare it using a stub.

[reply]

        Perl has long allowed the taking of references to functions before they have been compiled or even declared. So support for that is indeed required until after the decision is made to no longer support that and after the deprecation cycle can happen.

        - tye        

[reply]
        Strange and rare? A simple dispatch table illustrates taking a reference before a function is seen, as the table typically comes before subroutines. 

        my %OPS = (
     frob => \&frobnicate,
     knob => \&knobnicate,
);

sub frobnicate { ... }
sub knobnicate { ... }

        [download]

        As for a reference evaluating to undef, the concept seems wrong. If a reference can't be taken it should be an error; if it can, you should get a reference. Are there any examples of this behavior in Perl now?

[reply]
[d/l]

In Section Seekers of Perl Wisdom