in reply to Re: The trap of reference numification
in thread The trap of reference numification

In my experience object IDs almost always use the stringified reference as a hash key (the usual way for inside-out objects.) Or Scalar::Util::refaddr is used (as in Class::Std and PBP.)

refaddr returns the numified reference, but Scalar::Util already turns warnings off when munging that. (And SU does it in a rather bizarre way with a regex and hex instead of using direct numification for reasons that remain mysterious to me.)

I don't think there are many common uses of numified references outside those two contexts.

Update: Actually it looks like the issue with refaddr is fixed in recent versions. It uses int now.

Replies are listed 'Best First'.
Re^3: The trap of reference numification
by demerphq (Chancellor) on Nov 12, 2005 at 11:17 UTC

    And SU does it in a rather bizarre way with a regex and hex instead of using direct numification for reasons that remain mysterious to me.

    The answer to that is simple: overloading. Up until later perls (and even in them im not sure) there was no way to bypass overloaded nummification. Thus 0+$ref is inherently dangerous on a blessed ref. However there is and has always been a way to bypass overloaded stringification which conveniently contains the reference address in hex. Thus the only generally safe pureperl way to get the address of a ref is via this technique.

    Having said that SU doesn't use the pure perl code except on older perl builds on OS'es/Machines that dont have XS installed. The XS code it uses for refaddr() is much more efficient and bypasses all of these problems.

    ---
    $world=~s/war/peace/g

[reply]
Re^3: The trap of reference numification
by dragonchild (Archbishop) on Nov 11, 2005 at 19:46 UTC
    Comparisons between objects. Depending on my mood, I'll use eq or == interchangably. Before we go ahead and do this, there needs to be considerable discussion. This will end up being a bigger change than expected.
    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]
      Comparisons are one thing, but I seriously doubt you do math ops on them (like in this case, using the modulus operator). If the warning recognized that situation, I suspect it would be pretty close to The Right Thing.
      Caution: Contents may have been coded under pressure.
[reply]
        So, you're proposing that the warning should warn whenever a reference is numified, save when the numified value is used in a == (any other exceptions)? Talk about a weird exception to a weird case. And you think we get laughed out now ...
        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]
      I don't think anyone was proposing that it be done without major discussion. I assume that the usual erudite discourse and flamewars to light up the night sky will take place on p5p. Personally, I think the change would be worth the effort.
[reply]
        If 5.10.0 ever gets released, then I would agree. Putting it into 5.8.8 is just a recipe for disaster.
        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]

In Section Meditations