Re^3: Writing general code: real world example

Meditation are good for meditating - so this thread is teaching me something about refactoring (which is theoretical), and something about tainting (which is practical). This is good for me.

I like very much your solution. In particular, it makes me reflect that an in-place detainting could be dangerous, because I could end up not knowing whether a variable has already been detainted or not. Your approach seems to divide variables into two groups: tainted and not, and this seems reasonable.

I only wonder how readability could be affected by this approach. The detainting method being under the surface, I fear that the naive programmer (er.. me) could be disorientated by seeing such an assignment and seeing $var used in potentially dieing places.

Flavio (perl -e "print(scalar(reverse('ti.xittelop@oivalf')))")

Don't fool yourself.

Comment on Re^3: Writing general code: real world example - and doubts! Select or Download Code

Replies are listed 'Best First'.
Re^4: Writing general code: real world example - and doubts! by Zaxo (Archbishop) on Apr 05, 2005 at 09:09 UTC
You're right, readability suffers with that approach. Because code is invoked at a distance, and there is no local indication of which variables are covered by the validation mechanism, the reader needs to absorb the ties before getting to the real code. That's likely to be missed by a maintainer. Documentation helps, comments help, but those may not be enough. You spotted the principal weakness. I'm not yet encouraging anyone to use Tie::Constrained in production. The API is not yet stable, simple as it is. I'll make a version 1.00 release when I think it's ready. If you have suggestions, I'd welcome them. After Compline, Zaxo	[reply]

Replies are listed 'Best First'.

Re^4: Writing general code: real world example - and doubts!
by Zaxo (Archbishop) on Apr 05, 2005 at 09:09 UTC

You're right, readability suffers with that approach. Because code is invoked at a distance, and there is no local indication of which variables are covered by the validation mechanism, the reader needs to absorb the ties before getting to the real code. That's likely to be missed by a maintainer.

Documentation helps, comments help, but those may not be enough. You spotted the principal weakness.

I'm not yet encouraging anyone to use Tie::Constrained in production. The API is not yet stable, simple as it is. I'll make a version 1.00 release when I think it's ready. If you have suggestions, I'd welcome them.

After Compline,
Zaxo

[reply]