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.

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.

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.