Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot

Re: OO-call bug uncovered & autovivified functions: defined? exists?

by Somni (Friar)
on Oct 29, 2007 at 00:29 UTC ( #647763=note: print w/replies, xml ) Need Help??

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

You figured it out? Odd, I seem to remember spending a chunk of time cutting down your code in order to determine what the problem was, then providing you with some simple examples. Thanks for the credit.

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.

  • Comment on Re: OO-call bug uncovered & autovivified functions: defined? exists?

Replies are listed 'Best First'.
Re^2: OO-call bug uncovered & autovivified functions: defined? exists?
by ikegami (Patriarch) on Oct 29, 2007 at 01:15 UTC

    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

    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.

Re^2: OO-call bug uncovered & autovivified functions: defined? exists?
by perl-diddler (Chaplain) on Oct 29, 2007 at 01:48 UTC
    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.


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

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://647763]
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others avoiding work at the Monastery: (8)
As of 2023-12-11 11:37 GMT
Find Nodes?
    Voting Booth?
    What's your preferred 'use VERSION' for new CPAN modules in 2023?

    Results (41 votes). Check out past polls.