The obvious place to encapsulate all interactions with that attribute, is within that method.
Only if all of your validations are completely unique. Otherwise, that's lacking in abstraction. People are already getting sick of writing the same redundant validation code all over the place, hence the utility of Regexp::Common, Params::Validate and others. There is a proven need for abstraction here.
recieving the values one at a time through the STORE method of a tied array makes for horrible problems. […] What happens if the programmer doesn't provide a TEMP method? [a dozen questions of temporization semantics]
These are all good points. They need to be resolved as they affect uses of tie. The STORE issue is a problem in many contexts. The semantics you're asking about need to be clarified.
Discussing these issues in the context of lvalue subs is a red herring, though. Why not think about ways to fix the problems with tieing (which affect all uses of tieing and should be addressed in any case), rather than spending so much energy trying to invent a new (and likely also partially broken) mechanism to implement lvalue subs?
That's where Larry is…
Anyone who remembers writing Pascal and having:
I don't understand how that is relevant to the discussion at all. I don't know how that is supposed to show any validation attempt (are you trying to constrain the length of the strings?), and in any case, just because Pascal's type system sucked doesn't prove anything about type systems in general. Haskell and ML are counterexamples. I thought you liked Haskell?
Makeshifts last the longest.
In reply to Re^6: Assignable Subroutines
by Aristotle
in thread Assignable Subroutines
by dragonchild
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |