* Dave Rolsky ([EMAIL PROTECTED]) wrote:
> On Sun, 4 Nov 2001, Matt Sergeant wrote:
>
> > I'm totally against the use of AUTOLOAD. I must admit I thought it was
> > cute seeing it used in Damian Conway's book to generate accessors on the
> > fly, but really, all it's doing is saving a tiny bit of typing. P5EE is
> > about the long term, not saving the initial module developers 5 minutes
> > worth of effort in typing. And AUTOLOAD really is a maintainence disaster
> > (and again, doesn't really work with OO).
>
> I second this sentiment. Plus if you want to just save the typing for
> simple accessors, its quite easy to create these at compile time via a bit
> of code in a BEGIN block.
>
A sample scenario is as follows ...
Imagine a persistent object that we only want to save when its
destroyed/commited and to do so we need to mark it as `dirty'
i.e. changed since it was loaded (There are also some interesting
bits connected to transactions with this scenario, but I digress).
Now if we want we can either ...
Ignore the proble altogether (aka the ostrich method) and save
it every time.
Compare it to the original state (saved somewhere), which is
probably as costly as just saving it again.
Use a specialised P5EE version of Class::Methodmaker or similar
that marks it as dirty upon sets. However if anyone accesses the
object directly (in what I would regard as bad but typical Perl
programming). Or we could assume people mark it as dirty with
their own custom set operations.
Tie it and automatically mark it as dirty if some does a set.
Now I've been playing with my own secret P5EE compliant[1] persistence
``engine'' (whatever the hell that means) and I like the 4th option
with the tie in turn calling the get/set method to do so in the store
section and a dirty bit being set because of it.
Greg
[1] Which is impossible as we don't have standards for P5EE
persistence yet, but never mind.
--
Greg McCarroll http://217.34.97.146/~gem/
