#1 make AUTOLOADed accessors more efficient

[Chris Mungall]

automated accessor methods

Currently the go-perl object model uses automated accessor
methods. Each class defines a list of attributes with the
_valid_params subroutine. When that attribute is accessed at run-
time,
if no accessor is explicitly defined then the AUTOLOAD method in
GO::Model::Root is invoked, providing a "hidden" accessor method

This is a common perl idiom (See the Conway book). The way it is
currently implemented in go-perl (and the way it is mostly
implemented) comes with a substantial performance hit. The
advantage
may seem slight - the programmer does not have to write boilerplate
code defining gets/sets for all accessors. In fact, the programmer
still has to write the pod docs for every attribute (and this is a
little sloppy in places)

ChrisL measured the current go-perl AUTOLOAD implementation as
being
10x more inefficient than explicit perl accessor methods. Even
bearing
in mind that this is probably dwarfed by performance in other areas
(especially wrt AmiGO), it seems obvious that this area needs
addressed.

The most obvious way forward is to explicitly define accessor
methods
for all attributes, and do away with the AUTOLOAD altogether. This
wouldn't take a huge amount of effort.

However, there are many advantages in keeping a more declarative
approach and retaining the _valid_params metadata.

First of all, it should be possible to have the best of both worlds -
it should be fairly easy to make the automated approach as fast as
the
explicit method approach. The obvious way is to autogenerate the
method subroutine at module-load time.

In addition, it leaves open the door for ultra-fast-and-lean
implementations. For example, we could auto-generate C-code for all
accessor data and methods (you can see the beginnings of an
aborted
implementation of this in GO::AppHandles::AppHandleCWrapper)

We could also do both - have explicitly define accessor methods as
well as the _valid_params metadata. In fact this is how things are
done now, in a slightly ad-hoc way.

Whichever route we go, it seems clear that some amount of tidying
up
and documentation would be welcome in this area

[Nobody/Anonymous]

ZkWK6O Fantastic blog post. Will read on...

[Nobody/Anonymous]

Cf3PD9 <a href="http://qfhfexlyguip.com/">qfhfexlyguip</a>, [url=http://zrbipsyxhiok.com/]zrbipsyxhiok[/url], [link=http://oeirxbrhvzrt.com/]oeirxbrhvzrt[/link], http://sjyinnafqken.com/