Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW

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

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


    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.


    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?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://510984]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (6)
As of 2018-05-21 15:25 GMT
Find Nodes?
    Voting Booth?