Beefy Boxes and Bandwidth Generously Provided by pair Networks vroom
There's more than one way to do things
 
PerlMonks  

Re: A Class:: module I don't want to write

by perrin (Chancellor)
on Nov 23, 2005 at 02:28 UTC ( #510984=note: print w/ replies, xml ) Need Help??


in reply to A Class:: module I don't want to write

I'd say fix MethodMaker, wrap Accessormaker, or suck it up and inherit from Accessor. No need to write a whole new thing.


Comment on Re: A Class:: module I don't want to write
Re^2: A Class:: module I don't want to write
by Ovid (Cardinal) on Nov 23, 2005 at 06:39 UTC

    Problems:

    As for CMM, my response got long enough that I made it a meditation.

    Update: I finally got CMM to install and this failed with a "Can't coerce array into hash" message:

    { package Foo; use Class::MethodMaker [ scalar => 'name']; sub new { bless [], shift } } my $foo = Foo->new; use Data::Dumper; print $foo->name, $/; print Dumper $foo;

    If I switch that to a hashref, it works. A module adding methods to my class shouldn't make assumptions about the implementation.

    Cheers,
    Ovid

    New address of my CGI Course.

      Do what you think is best and explain your justifications in the documentation. It sounds like you should start from scratch. "I created this new module, because adding to the old modules wouldn't get the job done." IMHO, these "not invented here" commandments are guidelines that may not apply to every situation.

      I started using Class::Std to build getters and setters. Then, I discovered Object::InsideOut met my needs better. The author of Object::InsideOut explains why he created a similar module. I accepted his justifications. I have a colleague that says the author of Object::InsideOut should have improved Class::Std. But, I say the authors had his reasons and the result works better.

      Starting over is not always bad. But don't reinvent without a reason.
      Doesn't an accessor method generator have to make assumptions about how your object's data is stored? I don't see how it could access the data if it didn't. Support could be added to these modules for array-based objects and the like as separate options, but you'd still need to tell it what your object looks like, or else use a multi-level get/set like Class::Accessor so you can define that part in your code.
        Doesn't an accessor method generator have to make assumptions about how your object's data is stored?
        Not if the generator takes care of storing the data. The generator could treat the object as if it were an inside-out object, and store attribute data in a hash - either a package variable, or a lexical hash using a source filter (a source filter doesn't have to parse the source, it can also be used to add something to the code - as what generators are basically doing). Then it doesn't really matter whether the object is an inside-out object, or a hash-based one, or something else.
        Perl --((8:>*
        Not nessesarily. You may create an accessor as a closure over some local hashref. Then, store data in this hash with "self" object references as keys.
        sub create_accessor { my $hash = {}; return sub { # accessor my ($self, $value) = "_ return $value ? $hash{$self} : $hash{$self} = $value; } }
        This sub will return an accessor, storing value without knowing anything of object structure :)

        --
        Sergey Martynoff

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (6)
As of 2014-04-20 08:16 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (485 votes), past polls