in reply to Re^9: Assignable Subroutines
in thread Assignable Subroutines

How do you change it there? What is the mechanism by which you are going in and fiddling those bits? Presumably, it's some sort of access layer. Presumably, the access layer is made up of objects. And, presumably, you need a mutator.

Once you want a mutator, you want the syntactic sugar that goes with assignable subroutines.

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

Replies are listed 'Best First'.
Re^11: Assignable Subroutines
by hardburn (Abbot) on Jan 26, 2005 at 14:31 UTC

    Which is why I mentioned Class::DBI and similar layers. Once your method is running SQL statements (as opposed to simply changing an internal variable), it's no longer a trivial mutator. Complex mutators are a different beast :)

    "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

[reply]

      So the argument is then over trivial versus non-trivial. In my expereince there are no trivial mutators. Even if they seem trivial at the begging of a project they allow you the ability to move to non-trivial implementations later without rewriting all of your code. I've always read that its good practice not to access your data directly anywhere except in your 'trivial' getters and setters. This allows you to move to more complex storage mechanisms in the future.


      ___________
      Eric Hodges
[reply]

In Section Meditations