Re^11: Assignable Subroutines

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.

Comment on Re^11: Assignable Subroutines

Replies are listed 'Best First'.
Re^12: Assignable Subroutines by eric256 (Parson) on Jan 26, 2005 at 16:51 UTC
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]

Replies are listed 'Best First'.

Re^12: Assignable Subroutines
by eric256 (Parson) on Jan 26, 2005 at 16:51 UTC

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]