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

[perrin]

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

[Ovid]

Problems:

• Class::MethodMaker: see below.
• Class::AccessorMaker: assumes that I'm using blessed hashrefs. That won't fly.
• Class::Accessor: forcing people to use an extra level of inheritance is not a good thing. It should be a last resort.

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.

[esharris]

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.

[perrin]

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.

[Perl Mouse]

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.

[Martynoff]

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