Accessor and mutator autogeneration via class-method call

[javier.amor.garcia@…]

I am toying with the idea of making a method in gconfmodule that takes care of reating the mutators and accessors for the module. The method will take the name of the module and a argument list of hash references. Each hash will provide a simple definition of the attribute so we can create the methods.

The fields available for the definitios may be:

name - the name of the attribute type - the type of the attriubte (default: object) The type may be:

• object: the attribute is stored in the object itself (i.e

$self->{attr} = $value)

• a gconf type: bool, int, string, list

read - wether to make an accesor to the attribute (default: true) write - wether to make a mutator to the attribute (default: true) check - a sub reference that will be called when setting new values, if the sub returns false a exception will be throw. (the sub also can throw their own exceptions, in fact this is encouraged). (default: values are not checked)

A simple example of use (only 3 attributes!):

package EBox::Macaco; use base 'EBox::GConfModule; use strict; use warnings;

EBox::GConfModule::attributes(PACKAGE,

{name => 'mood', check =>

\&correctMoods},

{name => fleas, type => 'integer'}, {name => 'hideColour', type => 'string',

write => 0}

);

This call would be roughly equivalent to write this:

sub mood {

my ($self) = @_; return $self->{mood};

}

sub setMood {

my ($self, $newMood) = @_; unless (correcMoods($newMood)) {

throw EBox::EXceptions::InvalidData?(data => 'mood', value => $mood);

}

$self->{mood} = $newMood;

}

sub fleas {

my ($self) = @_; return $self->get_int('fleas');

}

sub setFleas {

my ($self, $fleas) = @_; return $self->set_int('fleas', $fleas);

}

sub hideColour {

my ($self) = @_; return $self->get_string('hideColour');

}

As you see it pays the worth. Besides the writing avoided we may reap other benefits for uniformity of access.

Cons:

• defined in run time so it add overhead to the modules' loading. I

think that is not outer-weight the benefits but we can avoid his use in the more used modules like Global or Firewall

[javier.amor.garcia@…]

The new model framework does this