On 2/26/07, Michael G Schwern <[EMAIL PROTECTED]> wrote:
Joshua ben Jore wrote:
> On 2/25/07, Yuval Kogman <[EMAIL PROTECTED]> wrote:
>> Is there a function that is to this as overload::StrVal is to
>> stringification?
Wouldn't that just be CORE::ref $obj ?
No. I don't know how to solve this problem without just wrapping
"CORE::ref" directly. I'm installing a wrapper around
PL_ppaddr[OP_REF] and have a TODO test that says I also wrap
op->ppaddr in all the code compiled before UNIVERSAL::ref is loaded.
The compiled form of CORE::ref() and ref() is identical so I don't
think I can know the difference. It seemed that way on my 5.8.8 and I
didn't look elsewhere.
Since this change is happening at such a low level, there's no way to
prevent the wrapper XS from being involved. At that point, the only
API it responds to is the %UNIVERSAL::ref::hooked hash which is just a
list of superclasses. If the object in ref( OBJ ) is true for
sv_derived_from( hooked_class, obj ) then that obj's scalar(->ref) is
returned instead.
Perhaps anywhere a person has said `no UNIVERSAL::ref' as a user
pragma, that's a place to also defer to the original ref(). I don't do
it now but it doesn't seem like a wrong idea. I opted to go for a
minimal API and add on as necessary.
Perhaps anywhere obj->ref shouldn't be able to call back into obj->ref
and instead go to CORE::ref( obj ) instead. This is dicier.
# ok, obvious
sub ref { ref shift }
# Less obvious what the right thing to do is
sub ref { foo( shift ) }
# imported &foo from elsewhere
sub foo { ref( shift ) }
I'm also pondering whether there's a nice time or place for a nasty
action at a distance to announce itself to the user. If the user runs
the code under the debugger a warning pops up saying "Woah there!"
So you see, I'm much less certain about this part of the API and thus
I just didn't code it.
Josh
