Re^2: A different OO approach

[adrianh]

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...

[shotgunefx]

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."

[adrianh]

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 ;-)

[shotgunefx]

I very much agree with "once and only once", my origins as a programmer were steeped in Asm and C. I realized quickly how it sucked cutting and pasting code (or making changes), then hunting down all the errors I cut and pasted. But on the other hand, I do a lot of CGI and including a dozen odd modules (and there includes) can quickly kill response time. (mod_perl isn't always an option.)

I'm not advocating people not use modules, but for myself, when it is something like this, were it amounts to a a few lines of code, I tend to keep it in a snippet file and cut and paste it into the source. In the simplest form..

sub add   {
    my ($self,$name,$value) = @_;
    return if $name !~/^\w+$/;
    my $pack = ref $self;
    no strict 'refs';
    *{$pack.'::'.$name} = sub : lvalue { $Attrs{+shift}->{$name} };
}

seems extreme for a module. On the other hand, if your attributes are more complex it could easily become worthy of using a module.

And yes I was confusing you with the poster, my bad.

-Lee

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