Beyond Inside-Out

[anno4000]

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:umper 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

 

[Dr.Ruud]

(e-mail address removed)-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:umper and Storable don't do anything for them.

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

 

[anno4000]

(e-mail address removed)-berlin.de schreef:


"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:umper, 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

 

[anno4000]

(e-mail address removed)-berlin.de ([email protected]) wrote
on M September MCMXCIII in <URL:// > (e-mail address removed)-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:umper 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:umper, 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:umper 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

 

[Michele Dondi]

Abigail <[email protected]> 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

 

[anno4000]

(e-mail address removed)-berlin.de ([email protected]) 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

 

[anno4000]

(e-mail address removed)-berlin.de ([email protected]) wrote
on M September MCMXCIII in <URL:`' > (e-mail address removed)-berlin.de ([email protected]) 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

 

[anno4000]

Abigail <[email protected]> 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

 

[Michele Dondi]

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