http://qs1969.pair.com?node_id=219810


in reply to A different OO approach

I liked Abigail's take as well. The DESTROY problem is easy to get around. 
my (%Attr1, %Attr2,%Attr3);
my @USED = (\%Attr1, \%Attr2, \%Attr3);

sub DESTROY {
   my $self = shift;
   delete $_->{$self} foreach @USED;
}

[download]
The serialization is a larger problem. I don't like the idea of everyone having to agree on a standard way of doing things to get the benefits of prior work. (This is Perl after all.) There are hooks in Data::Dumper and Storable, for serialization, it seems to me, that it might make better sense to provide a serialization hook instead. (Though getting the modules to recognize this from subclasses is another issue. Perhaps a patch to Dumper that looks for a Freezer method automatically if the class isa Dumper. (Same for Storable). Seems like it would be easier to patch the few main serialization modules then every other module on CPAN that you may want to inherit from.

-Lee

"To be civilized is to deny one's nature."

Replies are listed 'Best First'.
Re^2: A different OO approach
by Aristotle (Chancellor) on Dec 15, 2002 at 02:25 UTC
    my @ATTR = \my (%Attr1, %Attr2, %Attr3);

    Makeshifts last the longest.

[reply]
[d/l]

      ++ That is very nice. I didn't realise that you could use my and \() like that. Learn something new every day!

      The only pain is that you have to remember to do:

      my @A = \my %Foo;

      [download]

      not

      my @A = \my (%Foo);

      [download]

      ... which could lead to some nasty buggettes if you're not careful.

[reply]
[d/l]
[select]
        Odd. I didn't even notice. I'm not sure I understand - I shuffled parens around but there's no difference. This is funny and sort of embarrassing.. what am I missing?

        Makeshifts last the longest.

[reply]
      I thought I remembered seeing it done something like that. I had tried my \(%Attr1,%Attr2,%Attr3). Thanks for the tip.

      -Lee

      "To be civilized is to deny one's nature."
[reply]
Re^2: A different OO approach
by adrianh (Chancellor) on Dec 15, 2002 at 01:30 UTC
    The DESTROY problem is easy to get around...

    That just moves the problem from keeping DESTROY in sync, with keeping USED in sync :-)

    The serialization is a larger problem. I don't like the idea of everyone having to agree on a standard way of doing things to get the benefits of prior work.

    I'm not sure I follow this argument?

    If you have a complex serialisation problem you'll be writing custom freeze/thaw methods anyway so it's not an issue.

    If you're not - and basically want something that has all the attributes in it for you to Dump/freeze/thaw, then a base class would seem the best solution to put a generator for this sort of thing?

    ... or am I missing the point again... it is late...

[reply]
      I don't see keeping @USED in sync a problem. It's a fairly simple thing to do, and if you use a function generator to make your accessors, then you really can't forget.

      I'm not saying a base class doesn't have any merit, but what about everthing that already exists on CPAN? How would this play with them? Ideally, I shouldn't have to know the internals of a base class if I want to inherit from it.

      Most freezing and thawing is done with a handful of modules, patching those modules to look for a certain method before serializing would let someone inherit from these "inside out" modules in a fairly transparent fashion, regardless of whether the inheriting class used a common "base" module or not. In fact the descendant wouldn't have to know or care how the object was implemented. To it, it would work pretty much like any other hash based object. The Serialization routine could just return the appropriate data blessed into a helper class. The helper class when accessed through a method, could turn itself into a proper "inside out" object.

      The other thought would be using a HoHoH as you do, would probably be at least 30% slower than Abigail-IIs method of just using lexical hashes. For many things, speed is not a priority, but for objects that will be called often (parsers, tokenizers, etc) this could be a big hit. So my main argument would be that if it would interfere with using other modules in a transparent fashion, I think it would be of limited value in the general case.

      -Lee

      "To be civilized is to deny one's nature."
[reply]
        I don't see keeping @USED in sync a problem. It's a fairly simple thing to do, and if you use a function generator to make your accessors, then you really can't forget.

        I'm stupid. If I have to do some monkey coding then at some point I will forget to do it properly. It also offends my sense of once and only once.

        I can move attributes around classes a lot during refactoring and, for me, it's asking for trouble. If the perl can do it, it should do it :-)

        I like this solution and, as you say, building it into a function generator or similar solves the problem nicely.

        Most freezing and thawing is done with a handful of modules, patching those modules to look for a certain method before serializing would let someone inherit from these "inside out" modules in a fairly transparent fashion, regardless of whether the inheriting class used a common "base" module or not.

        Ah. I see what you're getting at. Good point.

        The other thought would be using a HoHoH as you do, would probably be at least 30% slower than Abigail-IIs method of just using lexical hashes.

        I agree completely - but it's not my proposal. You confuse me with fruiture - it's his RFC ;-)

[reply]

In Section Meditations