There's nothing wrong with this approach. In fact, my own code is filled with instances of this pattern. But it has always annoyed me to saddle a function with a test that is useful only once in its lifetime. It's a perverse sense of aesthetics, I admit it, but that is, at any rate, the motivation behind the gyrations...
Yeah, I'm concerned too with "this kinda things": see for example Doing "it" only once which was brought up here by Limbic~Region, but inspired by a post I made in p6l. There, the situation was somewhat lower level in that it boiled down not to a matter of mangling the symtable, but even the optree itself. Unfortunately most people didn't get it in both places, that is p6l and here: just pointing out that there are many WTDI and asking "what's wrong with this one?" Both me, LR and those who actually understood are perfectly aware that there are many ways around it, but still find them all somewhat unsatisfactory for some reason.
To sum up what was going on in that thread, the mythological beast we were/are after is a statement modifier (or something like that) specifying that the statement itself must be executed once only, and then evaporate like it never existed, not being skipped upon a condition. There are fundamentally two categories of replies pointing out ways to do it without the mythological beast:
- use a counter and skip over the statement when it's positive;
- have a version of the loop with the statement that exits the loop when the statement is executed and then continue with a similar loop that does not contain the statement.
In the former approach you check a condition also after you're sure it won't be true anymore a priori, and you don't want it to be. In the latter you avoid this with some sort of code duplication that in certain circumstances may also require you some code factorization that would be otherwise unnecessary. Currently I would personally use the former when I'm not concerned about performance and the latter when I am, with a preference for the latter even in the first cases because I find it conceptually and aesthetically disturbing to perform unnecessary operations even if any overhead they introduce may be negligible. I long for a solution that gives me the best of both solutions on the base of conceptual and aesthetical considerations in that it should be syntactically simple like the first one and avoid unnecessary operations, like the second.
Somebody else, in that thread, pointed out that manipulations like those we were talking about were very common in early languages, but are now regarded as Evil™, and for good reasons that I can understand, the point still being that just like raw goto is also Evil™, Perl provides tamed forms of goto under the names of last, next and redo which are not and nevertheless make for very useful common Perl idioms. So, much in the same vein I do not long for generic means to achieve self-modifying code to be made excessively accessible, but for a tamed, specific, form of self-modifying code available as a teaspoonful of syntactic sugar simple enough to use from the typing-wise POV to make it elegant and appealing, and distinctive enough not to make it possible for one to use it inadvertently with the risk of being bitten in the neck by it.
I was just wondering whether there were fundamental problems with the approach (other than its neurotic convolutedness).
FWIW I find "its neurotic convolutedness" not to be terribly more relevant than the simple condition checking version.
| [reply] |
I can't think of a more fundamental problem with any code than being more complex than it needs to be, except maybe giving the wrong answer. | [reply] |