Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine

Re^2: New Module Announcement: Object::InsideOut

by jdhedden (Deacon)
on Nov 03, 2005 at 21:24 UTC ( [id://505516] : note . print w/replies, xml ) Need Help??

in reply to Re: New Module Announcement: Object::InsideOut
in thread New Module Announcement: Object::InsideOut

Because the object ID is stored in the object's scalar ref (i.e., $$self), overloading ${} deferencing is not allowed. I document this fact in the POD.

However, all other forms of object deferencing through overloading are supported: Stringify, numerify, boolify, arrayify, hashify, globify and codify. Object::InsideOut simplifies defining these operations through the use of subroutine attributes. For example, your code would become:

use Test::More 'no_plan'; package Foo::Bar; { use Object::InsideOut; sub numify :Numerify { 42 } } package main; my $obj = Foo::Bar->new(); is(0 + $obj, 42);

Remember: There's always one more bug.

Replies are listed 'Best First'.
Re^3: New Module Announcement: Object::InsideOut
by diotalevi (Canon) on Nov 03, 2005 at 21:28 UTC
    If you treat the scalar as an opaque object, store nothing inside it and use overload::StrVal as the key instead, you can allow ${} to be overloaded as well. Data::Postponed uses blessed scalars as the object and allows anything what so ever to be overloaded.
      Then you are back to the same performance problems encountered with Class::Std, namely you have to calculate the object ID on every access.

      It is an engineering trade-off that I feel is more than justified. By storing the object ID in the object's scalar, the only thing you give up is the capability to overload the ${} operator.

      Remember: There's always one more bug.

        And the ability to subclass foreign code without knowing about its implementation.

        Makeshifts last the longest.