[Bioperl-l] Re: Automatic generation of set and get methods

[Steven Lembark]

> I also like the explicitness of having all methods including accessors
> available in the source. But I've also felt at times burdened by cutting
> and pasting nearly identical code for every field. Here's my accounting
> of the pluses and minuses to help decide the best way to go. Feel free to
> add & comment:
> Advantages of accessor autogeneration:
>
>    * Frees developer from drudgery of writing routine accessor code
>    * Reduces chance of bugs within accessor code (e.g., from cut-n-paste)
>    * Guarantees predictability of accessors across all modules
>    * Simple tests could be autogenerated
>    * Documentation template could be autogenerated
>    * Reduces amount of routine code within a module so you can focus on
> the       business logic.
>
> Disadvantages of autogeneration of accessors:
>
>    * Code is less explicit; can't see all methods when reading module
> source    * Can't validate data when setting (but see below)
>    * Runtime bugs within autogenerated code harder to track down
>    * Performace hit (maybe, not sure about this)
>
> So I'm leaning towards autogeneration. I think it would improve the
> reliability and uniformity of Bioperl modules and allow developers to
> focus on the "interesting" parts of the code. If we enable the
> flexibility of specifying read/write vs. read-only accessors as I
> mentioned above, that would be great.

Why not use an AUTOLOAD? If most of of the code will be
autogenerated then probably 90% of it can be dealt with
this way. The few cases where autogeneration would fail
will require hand coding anyway.



> The lack of validation within autogenerated accessors is an important
> issue. It gets at Hilmar's complaint of not always wanting to allow a
> field to take on a value of undef. It could be formalized within the
> autogenerated setter using something like this:
<snip>
> Then you hand-code the sub validate_<field> methods to do all the
> checking you desire. We could autogenerate the throw call on validation
> failure if we specify that the validate method should return nothing on
> success and a string on failure explaining the reason for failure:
>
>             if( $self->can("validate_$field") ) {
>                 if( my $msg = $self->validate_$field ) {
>
>                 }
>             }


Ever use the design by contract module? The code would look
much like the examples so far.

Another [ratehr unlikely, I admit] alternative is to replace
hashes with closures for the objects. The closure can easily
validate that the operation is clean then forward the data
to a local accessor method. Combined with an AUTOLOAD that
instantiates the boilerplate operators it would save the
cut+paste overhead and still give necessary validation on a
class-by-class basis.



--
Steven Lembark                               2930 W. Palmer
Workhorse Computing                       Chicago, IL 60647
                                            +1 800 762 1582