At 03:58 PM 12/23/2001, brian moseley wrote:
> > Actually I think I was suggesting multiple inheritence
> > as the 3rd mechanism. But I think it is fairly mandatory
> > that the Transient object be an attribute or element of
> > the data structure hash or array. Because not only
> > objects should be serializable with transient elements,
> > but so should general data structures I suspect.
>
>hmm.. can you maybe sketch out a quick example? i think i
>understand but am still a little unsure.
Oh, forcing me to write Perl code which is quite horrible from lack of use...
First, you need the basic Transient (TransientMap) object to record what
fields are actually supposed to be transient..
package TransientMap
sub new {
my $package = shift;
my $map = shift || {};
my $self = { 'transient_map => $map };
return bless $self, $package;
}
sub is_transient {
my $self = shift;
my $element = shift;
return defined ($self->{'transient_map'}->{$element};
}
sub add_transient {
my $self = shift;
my $element = shift;
$self->{'transient_map'}->{$element} = 1;
}
THEN... all you need to do in defining an object that needs to be Transient
aware is just do something like the following:
package DataResource {
sub new {
my $package = shift;
my $some_data = shift;
my $self = { 'some_data' => $some_data };
my $transient _map => new TransientMap();
$transient_map->add_transient('some_transient_data');
$self->{'transient' => $transient_map};
}
Then, something like Data::Dumper could be modified to look at this hash
and realize that because there is an element of type TransientMap, it will
then ask for all other elements in the object hash whether they are
transient or not. Those elements that are listed in the transient map
object would not be serialized (and therefore not reconstructed as part of
the data structure upon revival).
This would also work for objects that are ref to array instead of ref to a
hash except that you would use add_transient(some number) to indicate the
index of elements in the array that should be transient.
The nice thing is that this also works for non-objects. You could literally
defined a section of a ref of an array or hash to be transient and have
Data::Dumper or other modules follow the same convention for deep data
structures and not just objects.
It's not as pleasant as your attribute syntax. I've never really seen that
syntax so I can't say that I am that familiar with it. I just know that
it's conceivable that we could follow a convention instead.
Another way to play the game is to an @TRANSIENT array which would be like
@ISA array. Just by convention, Perl or the serializers in Perl would
recognize the package level @TRANSNIENT array.. so you would define
something like
@TRANSIENT = qw (database_handle);
I don't like this idea as much as recognizing the TransientMap object
because then normal Perl data structures would not benefit from serializers
knowing about transient
This is because the above convention makes the @TRANSIENT tied to a package
definition instead of tied to the data structure.
> > This is not so in Java so much, but definitely in Perl
> > with it's more flexible ideas of what constitutes a data
> > structure vs object then serialization needs to be
> > equally flexible I suspect. Of course, this brings us
> > back to the discussion of what a Perl bean would be like
> > and how different it should be from Java.
>
>does it, or is that just a neat but independent extension of
>the idea?
I think it could bring back that discussion. Serialization is one of the
number one things that beans do that is cool. It's essentially like a
hierarchical config because the properties of the bean are written out to disk.
But it also could be premature. However, I did want to bring it up in case
it sparks something for others to think about.
