in reply to Re^2: Assigning to the CODE slot of a GLOB whose REF is held in a lexical?
in thread Assigning to the CODE slot of a GLOB whose REF is held in a lexical?

You're explicitly overwriting the globref with a scalar. <P.You need to use the right syntax to assign to the SCALAR slot of the referenced glob. 

[ 7:53:35.32] P:\test>perl -l
my $globref = \do { local *GLOB };
print $globref;

## Assign to the SCALAR slot in the glob referenced by $globref
${ *$globref } = 123456789;

print $globref; ## Still a GLOB
print ${ *$globref }; ## Contains our value

## This is where the trouble comes in.
*$globref = sub{ print 'test' };

print ${ *$globref }, $/, &{ *$globref };
^Z
GLOB(0x224fc8)
GLOB(0x224fc8)
123456789
Not a GLOB reference at - line 13.

[download]

However, I did just discover this. 


[ 7:56:55.39] P:\test>perl -l
my $globref = do { local *GLOB; \*GLOB; };
print $globref;

## Assign to the SCALAR slot in the glob referenced by $globref
${ *$globref } = 123456789;

print $globref; ## Still a GLOB
print ${ *$globref }; ## Contains our value

## This is where the trouble comes in.
*$globref = sub{ print 'test' };

print ${ *$globref }, $/, &{ *$globref };
^Z
GLOB(0x1824284)
GLOB(0x1824284)
123456789
test
123456789
1

[download]

If I return the reference to the localised GLOB from with the do block, then everything works fine, without the need to pre-assign something to the actual GLOB before hand.

I'm pretty sure that I picked up on the idiom of 

my $globref = \ do{ local *GLOB; };

[download]

from a usually reliable (and wizardly:) source, but I'll need to check that.

As I understand it, localising the GLOB effectively give you access to a new (anonymous) typeglob ensuring that if the code is called multiple times, you get a new once each time, without needing to go the Symbol route of creating sequence numbered globs in a special namespace.

However, my understanding may well be wrong. This could just be what I assumed the do local construct was doing. Hmmm. Off to try and relocate some sources and refresh my memory.

Replies are listed 'Best First'.
Re^4: Assigning to the CODE slot of a GLOB whose REF is held in a lexical?
by revdiablo (Prior) on Nov 17, 2004 at 17:53 UTC

    As a foreward, I hope you don't get the wrong idea about my replies. I'm not trying to beat the point into the ground, I'm just trying to figure out exactly what's going on. If you're getting tired of this thread, feel free to ignore my reply.

    You're explicitly overwriting the globref with a scalar. <P.You need to use the right syntax to assign to the SCALAR slot of the referenced glob.

    Well, this doesn't overwrite the glob reference with a scalar reference:

    my $globref = \*GLOB;
*$globref = 1;
print $globref, "\n"; # prints GLOB(0x.......)

    [download]

    But you're right that I'm not using the right syntax. I really meant to do this (which works as expected):

    my $globref = \*GLOB;
*$globref = \1;
print $globref, "\n"; # prints GLOB(0x.......)

    [download]

    Compared to this (which overwrites the entire glob reference, strangely):

    my $globref = \do { local *GLOB };
*$globref = \1;
print $globref, "\n"; # prints REF(0x.......)

    [download]
    If I return the reference to the localised GLOB from with the do block, then everything works fine

    Hmm, I thought about trying this, but got distracted. I'm glad you thought to try it for me. ;-) Perhaps it's something with the way local is returning the glob?

    As I understand it, localising the GLOB effectively give you access to a new (anonymous) typeglob

    That's what I thought when I first saw you use the idiom, but now I'm not sure what's going on. If you find out, please let me know. This is very curious. :-)

[reply]
[d/l]
[select]
      If you find out, please let me know. This is very curious. :-)

      Well, I tracked down my impecable source of the idiom.

      # Incantation.

      But in my tests, my $globref = do{ local *GLOB; \*GLOB }; seems more reliable? If I get a chance later, I'll try my test code under 5.6.1 and see if some things changed between versions.

      Examine what is said, not who speaks.
      "Efficiency is intelligent laziness." -David Dunham
      "Think for yourself!" - Abigail        "Time is a poor substitute for thought"--theorbtwo
      "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon
[reply]
[d/l]
        I'll try my test code under 5.6.1 and see if some things changed between versions.

        I get the same results from 5.005_03 as I do from 5.8.4. If nothing else, at least this behavior hasn't changed for a while...

[reply]

In Section Seekers of Perl Wisdom