Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re^2: Beyond Inside-Out

by Anno (Deacon)
on May 30, 2007 at 16:27 UTC ( #618237=note: print w/replies, xml ) Need Help??


in reply to Re: Beyond Inside-Out
in thread Beyond Inside-Out

I'd be interested in a concise summary of the features/benefits. Right now I really only see one:

  • Classes get "inside-out" property storage without needing to define fields and associated data storage hashes/arrays explicitly.

    I see three major points going for the Alter proposition. Rewording the one you mention,

  • In an Alter-class you get to keep Perl's original model, "an object is just a reference...", only each class gets to see its own reference. The ingenious twist of using a hash "inside-out", keyed by the object('s id) is not needed. If you want your object to "be" a hash keyed by field name, that's fine. If it's naturally a scalar, or code, you can have that too.

  • Second, Alter objects get garbage collection and thread support from Perl, the class has nothing to do with that. Destructors can be freely used for other purposes.

  • Third, though this hasn't been conclusively demonstraded in code, it is possible to provide generic hooks for Data::Dumper, Storable and the like that support all Alter classes and which can be inherited or even imported. With inside-out classes, this is hard to achieve because only the class knows where its data is stored. An Alter-object carries all its data with it, ready to dump and able to be restored.

    As for the cost, you have rightly observed that both techniques require the call to either id() or ego() on each access, with equal possibility of caching. The call to id() is essentially free, except for the call overhead, but ego() has a hash access in the path, which counts. Preliminary benchmarks show that the impact is measurable, but not dramatic. At the moment I am less concerned with efficiency but with getting it right.

    On a broader note, inside-out has shown what it takes to make black-box inheritance work in Perl. In particular, some kind of out-of-band storage is needed for which it cleverly uses the existing refaddr() as a primitive. My goal is to design a primitive (ego()) for out-of-band storage expressly for the purpose. In that sense I consider the sketch of the Alter module we're discussing a step beyond inside-out.

    This discussion (and another one on clpm) is helping me to spot potential problems and limitations of the approach.

    Anno

  • Replies are listed 'Best First'.
    Re^3: Beyond Inside-Out
    by xdg (Monsignor) on May 30, 2007 at 18:30 UTC
      Alter objects get garbage collection and thread support from Perl, the class has nothing to do with that. Destructors can be freely used for other purposes.
      An Alter-object carries all its data with it, ready to dump and able to be restored

      I think these are only true if the object reference is a hash/array that stores the references for each class. If so, you give up encapsulation and the ability to do "black box" (aka "foreign") inheritance.

      If Alter uses inside-out techniques behind the scenes and the object reference is a key into data storage maintained by Alter with the references for each object for each class, then you still have all the garbage collection and threading problems inherent to inside-out objects.

      Even if you use Hash::Util::Fieldhash, that just pushes the issues into the Perl core and it's not backwards compatible before 5.9.4 (at least, I think not).

      -xdg

      Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

        Alter objects get garbage collection and thread support from Perl, the class has nothing to do with that. Destructors can be freely used for other purposes.

        An Alter-object carries all its data with it, ready to dump and able to be restored

        I think these are only true if the object reference is a hash/array that stores the references for each class. If so, you give up encapsulation and the ability to do "black box" (aka "foreign") inheritance.
        No, that's not so. An Alter object stores its data in a hash that is magically (in the technical sense) attatched to the object (which can be of any type). Magic is unique in that it is inaccessible to normal Perl (except through the interface you want to provide), but is serviced in garbage collection and thread cloning.

        Anno

          Alter object stores its data in a hash that is magically (in the technical sense) attatched to the object

          Ah! Now I get it. A magical hash that is attached to any object? Yes, that does sound like what object properties are supposed to be.

          -xdg

          Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

    Log In?
    Username:
    Password:

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

    How do I use this? | Other CB clients
    Other Users?
    Others drinking their drinks and smoking their pipes about the Monastery: (2)
    As of 2018-08-15 03:17 GMT
    Sections?
    Information?
    Find Nodes?
    Leftovers?
      Voting Booth?
      Asked to put a square peg in a round hole, I would:









      Results (158 votes). Check out past polls.

      Notices?