Beyond Inside-Out

Discussion in 'Perl Misc' started by anno4000@radom.zrz.tu-berlin.de, May 29, 2007.

  1. -berlin.de

    -berlin.de Guest

    I'd like to draw the attention of the group to a writeup of mine
    on perlmonks: http://www.perlmonks.org/?node_id=617945

    It is about an alternative to the inside-out technique of class
    implementation that, I believe, is as powerful in enabling
    inheritance, but easier to handle. It comes in the form of
    a module named Alter, a preliminary implementation of which
    is available at

    http://www.tu-berlin.de/zrz/mitarbeiter/anno4000/alter/

    Alter exports a function named ego(), which is used to associate
    (set and retrieve) an independent piece of data with each object.
    The salient point is that the result of the call Alter::ego( $object)
    doesn't only depend on $object, but also on the calling class.
    Thus, different classes can maintain different views of each
    object without getting in each other's way.

    Unlike inside-out classes, Alter-based classes don't need extra
    support for garbage collection and thread cloning. Like inside-
    out, they do need help in serialization. The standard modules
    Data::Dumper and Storable don't do anything for them. It seems
    possible to provide general inheritable methods for Alter-based
    objects to handle these things. This is also something that is
    hard to do with inside-out classes.

    Anno
    -berlin.de, May 29, 2007
    #1
    1. Advertising

  2. -berlin.de

    Dr.Ruud Guest

    -berlin.de schreef:

    > Unlike inside-out classes, Alter-based classes don't need extra
    > support for garbage collection and thread cloning. Like inside-
    > out, they do need help in serialization. The standard modules
    > Data::Dumper and Storable don't do anything for them.


    "not anything" is too little, because both have hooks for integration
    with classes.

    --
    Affijn, Ruud

    "Gewoon is een tijger."
    Dr.Ruud, May 29, 2007
    #2
    1. Advertising

  3. -berlin.de

    -berlin.de Guest

    Dr.Ruud <> wrote in comp.lang.perl.misc:
    > -berlin.de schreef:
    >
    > > Unlike inside-out classes, Alter-based classes don't need extra
    > > support for garbage collection and thread cloning. Like inside-
    > > out, they do need help in serialization. The standard modules
    > > Data::Dumper and Storable don't do anything for them.

    >
    > "not anything" is too little, because both have hooks for integration
    > with classes.


    Oh yes, but the hooks must be supplied. If you give an inside-out
    object to Data::Dumper, without help it will dump an undefined blessed
    scalar: "bless( do{\(my $o = undef)}, 'SomeClass' )". The same goes
    for Alter-based classes.

    A difference is that with inside-out classes, essentially every class
    must provide the hooks individually. Only the class knows which
    object fields need to be dumped. With Alter-based classes, there is
    the possibility of general methods to handle dumping, thawing and
    freezing, that work with all objects and can be inherited or imported.

    Anno
    -berlin.de, May 29, 2007
    #3
  4. -berlin.de

    -berlin.de Guest

    Abigail <> wrote in comp.lang.perl.misc:
    > -berlin.de (-berlin.de) wrote
    > on M September MCMXCIII in <URL:news:>:
    > // Dr.Ruud <> wrote in comp.lang.perl.misc:
    > // > -berlin.de schreef:
    > // >
    > // > > Unlike inside-out classes, Alter-based classes don't need extra
    > // > > support for garbage collection and thread cloning. Like inside-
    > // > > out, they do need help in serialization. The standard modules
    > // > > Data::Dumper and Storable don't do anything for them.
    > // >
    > // > "not anything" is too little, because both have hooks for integration
    > // > with classes.
    > //
    > // Oh yes, but the hooks must be supplied. If you give an inside-out
    > // object to Data::Dumper, without help it will dump an undefined blessed
    > // scalar: "bless( do{\(my $o = undef)}, 'SomeClass' )". The same goes
    > // for Alter-based classes.
    > //
    > // A difference is that with inside-out classes, essentially every class
    > // must provide the hooks individually. Only the class knows which
    > // object fields need to be dumped. With Alter-based classes, there is
    > // the possibility of general methods to handle dumping, thawing and
    > // freezing, that work with all objects and can be inherited or imported.
    >
    >
    > That's not true. You can quite easily write a generic function that
    > provides the hook; said function can be exported.
    >
    > Just define your attributes as:
    >
    > our @ATTRIBUTES = \my (
    > %attr1,
    > %attr2,
    > ...
    > );
    >
    >
    > and your exported hook can access the attributes without any problems.


    Aha. A package variable that gives access to all attribute hashes of
    the class. You might as well use the code slot of *ATTRIBUTES and
    make it a method

    sub ATTRIBUTES { \ ( %attr1, %attr2, ...) }

    That's good, but it isn't good enough. You can access the attributes
    of the class an object is blessed into, but you don't know about
    other classes it might have been initialized to. That data has to
    be dumped as well. One could try to follow the ISA tree, but that's
    not reliable. Essentially, a general-purpose dumper needs to look
    at an object (that's all it has) and know about all data that is
    associated with the object. That is still hard to achieve with
    inside-out objects.

    > (This remarks is about Inside-Out Objects, I don't know whether that's
    > true for Alter based objects).
    >
    > The fact remains is that you need to do some work - but that's to be
    > expected. Inside-Out Objects is a technique to provide encapsulation.
    > Serialization as done with Data::Dumper and other standard modules use
    > by default a technique that only works in the absense of encapsulation.
    >
    > With strong encapsulation, serialization is not possible. (Because the
    > serialized object is by definition not encapsulated - it can be modified
    > and fed back to the object).


    That is a very clarifying remark, thanks for that.

    Inside-out objects provide encapsulation in a lexical scope, that's
    the strongest kind Perl has to offer. Once the scope is left there's
    no going back. (Except padwalking, there's always an exception.)

    Encapsulation with Alter objects is package based. Only code compiled
    in the class package can access the object's attributes in that class,
    but any such code can, in the original class code and elsewhere. That
    is a weaker form of encapsulation.

    Besides that, since the Alter mechanism is based on magic, it is easy
    to breach encapsulation even further, if required. Just provide the
    requisite magic tools in the interface. An Alter object carries all
    its data in all classes in a hidden hash, keyed by class. Give the
    dumper access to that hash and you're done.

    Anno
    -berlin.de, May 30, 2007
    #4
  5. On 30 May 2007 09:37:22 GMT, -berlin.de wrote:

    >Abigail <> wrote in comp.lang.perl.misc:

    [snip]

    Anno,


    due to time constraints (in synergy with the fact that much of this is
    far above the top of my head) I've not been closely following the
    discussions either here or in PM, but for what I've read they're both
    extremely valuable and interesting. So may I ask you to be so gentle
    and for completeness to report there -as time permits- anything you
    judge to be worth of what's said here? The other way round is easy,
    because you already linked to the root node of the thread...


    Michele
    --
    {$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
    (($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
    ..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
    256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
    Michele Dondi, May 30, 2007
    #5
  6. -berlin.de

    -berlin.de Guest

    Abigail <> wrote in comp.lang.perl.misc:
    > -berlin.de (-berlin.de) wrote


    [snip]

    > `' You can access the attributes
    > `' of the class an object is blessed into, but you don't know about
    > `' other classes it might have been initialized to. That data has to
    > `' be dumped as well. One could try to follow the ISA tree, but that's
    > `' not reliable.
    >
    > Not reliable as in 'you might want to modify @ISA before you serialize'?
    > If you modify @ISA at run time, Inside-Out objects will have a problem
    > anyway, as that prevents the right DESTROYs to be called if the object goes
    > out of scope. OTOH, if an object once belonged to class Foo, got data
    > associated with it in class Foo, then Foo is removed from @ISA, and then
    > it is serialized, why would you want to Foo data to be serialized? After
    > all, it's no longer a Foo.


    Imagine a situation where objects are initialized for two or more
    inheritance situations which can be switched at will. At any time
    there is only one @ISA tree to guide serialization (or destruction,
    for that matter), but all the data is needed for the whole to work

    I have come to consider @ISA a crutch for this purpose. Sometimes
    there is nothing else, but if possible I want to be able to look at
    an object and see which data is has. With Alter objects that *is*
    possible.

    >
    > `' Essentially, a general-purpose dumper needs to look
    > `' at an object (that's all it has) and know about all data that is
    > `' associated with the object. That is still hard to achieve with
    > `' inside-out objects.
    >
    >
    > That is hard to archieve. Period. A general purpose dumper method cannot
    > make any assumptions on how a class is implemented - or it wouldn't be
    > a general purpose dumper.


    True, an entirely general-purpose dumper would be impossible. Make
    that a dumper general enough to dump/restore any object that uses the
    Alter technique (plus, of course, the object body proper). That is
    possible, while I don't see a dumper general enough to dump all
    inside-out objects, not without some additional registry.

    [...]

    > `' Inside-out objects provide encapsulation in a lexical scope, that's
    > `' the strongest kind Perl has to offer. Once the scope is left there's
    > `' no going back. (Except padwalking, there's always an exception.)
    >
    >
    > Yes. But unlike what many people think, Inside-Out Objects is not about
    > "preventing other classes to access the data at all costs". It's not about
    > preventing the data to be accessed - it's about preventing *accidental*
    > access. If you put your attributes in 'our' hashes instead of 'my' hashes,
    > other classes can access the data, but since they have to be specific about
    > it, there's no accidental access.


    Yes, that's a relevant distinction. The problem isn't that one class
    *can* access the other's data, but that it *will* access the other's
    data (or die) if it tries to use the object for its own purpose. That
    is the problem inside-out is there to solve, not privacy.

    Anno
    -berlin.de, May 30, 2007
    #6
  7. -berlin.de

    -berlin.de Guest

    Abigail <> wrote in comp.lang.perl.misc:
    > -berlin.de (-berlin.de) wrote
    > on M September MCMXCIII in <URL:news:>:
    > `' Abigail <> wrote in comp.lang.perl.misc:
    > `' > -berlin.de (-berlin.de) wrote
    > `'
    >
    > `' > `' Essentially, a general-purpose dumper needs to look
    > `' > `' at an object (that's all it has) and know about all data that is
    > `' > `' associated with the object. That is still hard to achieve with
    > `' > `' inside-out objects.
    > `' >
    > `' >
    > `' > That is hard to archieve. Period. A general purpose dumper method cannot
    > `' > make any assumptions on how a class is implemented - or it wouldn't be
    > `' > a general purpose dumper.
    > `'
    > `' True, an entirely general-purpose dumper would be impossible. Make
    > `' that a dumper general enough to dump/restore any object that uses the
    > `' Alter technique (plus, of course, the object body proper). That is
    > `' possible, while I don't see a dumper general enough to dump all
    > `' inside-out objects, not without some additional registry.
    >
    >
    > An object using the Alter technique (or any other technique) could have
    > as one of its attributes another object, which could be an inside-out
    > object (or something else that uses strong encapsulation, like an object
    > based on closures). At that point the dumper would break down.


    Yes. It shows again that a truly universal dumper is impossible.
    However, the type of dumper I have in mind would at least know about
    the attribute and have a chance to complain when it can't deal with
    it. Relying on the inheritance tree may bypass attributes altogether.

    Anno
    -berlin.de, May 31, 2007
    #7
  8. -berlin.de

    -berlin.de Guest

    Michele Dondi <> wrote in comp.lang.perl.misc:
    > On 30 May 2007 09:37:22 GMT, -berlin.de wrote:
    >
    > >Abigail <> wrote in comp.lang.perl.misc:

    > [snip]
    >
    > Anno,
    >
    >
    > due to time constraints (in synergy with the fact that much of this is
    > far above the top of my head) I've not been closely following the
    > discussions either here or in PM, but for what I've read they're both
    > extremely valuable and interesting. So may I ask you to be so gentle
    > and for completeness to report there -as time permits- anything you
    > judge to be worth of what's said here? The other way round is easy,
    > because you already linked to the root node of the thread...


    I think it would be disruptive to *report* the contents of this
    thread on perlmonks (or the other way around). I have pointed
    out on monks that there is this parallel discussion, not prominently
    but it's there. And, of course, in participating in both threads I'm
    ferrying information back and forth as opportunity allows or demands.

    Anno
    -berlin.de, May 31, 2007
    #8
  9. On 31 May 2007 15:04:15 GMT, -berlin.de wrote:

    >I think it would be disruptive to *report* the contents of this
    >thread on perlmonks (or the other way around). I have pointed
    >out on monks that there is this parallel discussion, not prominently
    >but it's there. And, of course, in participating in both threads I'm
    >ferrying information back and forth as opportunity allows or demands.


    Well, it was not about reporting *everything*, but only significant
    stuff, which AIUI is what you're already doing...


    Michele
    --
    {$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
    (($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
    ..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
    256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
    Michele Dondi, May 31, 2007
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Neil Zanella
    Replies:
    0
    Views:
    614
    Neil Zanella
    Nov 16, 2003
  2. Alex D.
    Replies:
    1
    Views:
    9,544
    Alex D.
    May 20, 2005
  3. John Dalberg

    Can't go beyond page 2 in Crsytal Reports

    John Dalberg, Jun 27, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    405
    John Dalberg
    Jun 27, 2005
  4. Fernando Guillen

    Out of range on Dates beyond 2038/01/19

    Fernando Guillen, Dec 11, 2008, in forum: Ruby
    Replies:
    9
    Views:
    147
    Fernando Guillen
    Dec 12, 2008
  5. Michele Dondi

    (Anno's) "Beyond Inside-Out"

    Michele Dondi, May 29, 2007, in forum: Perl Misc
    Replies:
    2
    Views:
    88
    Michele Dondi
    May 29, 2007
Loading...

Share This Page