On p5p, where this is already being discussed, Rick Delaney presented a simpler snippet that demonstrates the problem.

package F;
sub foo { "foo" }
       
package G; @ISA = qw(F);
print \&foo; # creates entry in G's symbol table

package main;
my $o = bless [],"G";
print $o->foo;
[download]

CODE(0x8149624)
Undefined subroutine &G::foo called at - line 9.
[download]

I'm not sure why perl-diddler didn't post this much more readable snippet...

What's the matter with defined &foo?

Exists can't be applied to simple vars since there isn't sufficient state stored to be able to distingish between 'always been undef' and 'had a value, now undef'.

Dave.

I don't think it makes semantic sense for exists to be applied to functions.

Nonetheless there are semantics for it.

sub E; # exists, but not defined
sub D { 1 }; # exists _and_ defined
# sub N does _not_ exist

$\="\n";

print exists(&N) ? "N exists" : "N doesn't exist";
print exists(&E) ? "E exists" : "E doesn't exist";
print exists(&D) ? "D exists" : "D doesn't exist";

print defined(&N) ? "N is defined" : "N is not defined";
print defined(&E) ? "E is defined" : "E is not defined";
print defined(&D) ? "D is defined" : "D is not defined";
__END__
N doesn't exist
E exists
D exists
N is not defined
E is not defined
D is defined
[download]

print "Just another Perl ${\(trickster and hacker)},"
The Sidhekin proves Sidhe did it!

Assuming of course, that &foo is equivalent to "simple var" in your sense. If you see globs as aggregates then defined &foo makes sense. And it's easy to see globs as aggregates, as you can do *foo{THING}. So defined (and exists) applied to global things would just translate to check the "slot in the glob" determined by sigil. Now, I don't know what really goes on down there in perl land, but from the outside this picture works for me.

lodin

exists can indeed be used on subs; go back and reread the documentation. It takes the form exists &foo or exists &{foo}, where foo is the name of a sub (sans sigil) or a simple scalar variable containing a code reference or (2nd form only) an arbitrary expression yielding a code reference.

Update: just read through your code example. IMO there are no bugs there; you are created an undefined sub KA::boom. Such a sub takes precedence over a parent's boom. This can be useful in the case of a class using AUTOLOAD:

package Parent;
sub boom { die "please don't call me" }

package Child;
sub boom; # exists but not defined, same as your \&boom but created at
+ compile time
sub DESTROY {}
sub AUTOLOAD { die "call me instead" }

package main;
bless({},"Child")->boom
[download]

It's possible taking a reference to a function shouldn't behave this way. Unfortunately, in practice, with the way Perl is implemented, it needs to. In order to be able to take a reference to a function that has not yet been defined you have to add a symbol table entry. ->can, defined, etc. all need to work with this symbol table entry, because you've essentially made a promise that you will define the subroutine.

If you remove this behavior then it will be required that all subroutines be defined before ever being referred to. Given the dynamic nature of Perl you can't even check this promise until the subroutine is called; a subroutine could be defined at any point during compile- or run-time.

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.

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.

Um..sorry, but who are you and where did you give me help (i.e. in this forum or elsewhere?)

I had the example pared down to a simple test case, which, when one ran it, printed out what was going on. No one seemed to like that -- they just wanted the raw code without the clear output.

I posted that to p5p, and someone posted about a 10-line case that demonstrated 1 example of the same bug. People grokked that example and easily understood it. So I built-up from that example & added back in the other test cases to make sure I had bracketed my problem -- no, it didn't happen "here", yes, it happens here. Here is code that points the the problem in the perl internals...seems that the undefined value overrides the parent-method search...etc.

If you were the person who posted the code to p5p, it showed me what type of example people wanted, thanks, but the code posted showed the problem (but not as succinctly) in multiple ways to provide more information about what was going on, like how the 'can' function printed out coderef to two functions before the bogus reference, but after, the unreferenced function still had same "can" value (same CODEREF(hexnum)) while the referenced function had a different "can" value. This seemed to show that perl created a new value to store & reference as the "coderef" -- but one that was also incorrect.

I'm sorry if you feel I didn't give you enough credit for something you remember doing. If you provided help, thank you. I do appreciate your attempts to do so, but just because you may have given me help doesn't mean I "got" the help and that's when a light turned on in my head. The last person to help me from this forum was telling me to print out the reference, before the access error. This frustrated me, as I had a special routine written just to display the value -- it checked if it was a valid reference, if so, it printed the "ref $obj-pointer" value, then tested the pointer against all (2) classes (using "isa") and printed out membership information. Then it looped through the list of methods with "can" to verify that perl still thought I "could" do all of the methods through that reference. I.e. I printed out its value and a bunch of information about it -- stuff that was already in the program before anyone suggested I print the value.

Thanks again for any help you provided, I didn't mean to slight anyone, but until I had the problem encoded and posted to p5p, it wasn't too clear to me that anyone even believed it was a real bug in perl.

linda

Apparently you don't remember your own thread here, and the eventual solution. Perhaps you stopped reading. The end of the thread is here.