Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

Re: Re: Re: A different OO approach

by shotgunefx (Parson)
on Dec 15, 2002 at 20:38 UTC ( [id://220043]=note: print w/replies, xml ) Need Help??


in reply to Re^2: A different OO approach
in thread A different OO approach

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

Replies are listed 'Best First'.
Re^4: A different OO approach
by adrianh (Chancellor) on Dec 15, 2002 at 21:32 UTC
    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 ;-)

      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."
        In the simplest form...seems extreme for a module.

        I'm afraid I'm the sort of weirdo who will write a module for a one-liner if it means I don't have to type it twice. I'll then code something to inline it automatically if efficiency proves to be an issue :-)

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

        It's not that they're more complex, it's that when I refactor code they tend to move around a fair bit between classes. Since I change them a lot, forgetting to tweak a DESTROY method or update a list of attributes is exactly what I'm likely to do. It's an artifact of my development style.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://220043]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others studying the Monastery: (4)
As of 2024-03-19 07:58 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found