|
Re^3: Hash key composition with a comma?
by Anonymous Monk on Mar 17, 2018 at 13:34 UTC
|
It's not at all hard to see it – an example is not necessary. The perldoc quoted in the first reply says everything: the trick works by means of join(), such that it would have been far better if the feature had not been a part of the language and programmers had to type a few extra letters into their 300-baud teletypes. If your data contains the separator-character, the code breaks. Whereas, if you (today) use hash-of-hashes and auto-vivification, you can quickly construct real multi-dimensional data structures without concern for what the hash-key values might be, and the code is no more cumbersome. Some of the "older" ideas in Perl were really good ones. But this is not one of them. | [reply] |
|
|
It's a variation of the Semipredicate problem.
Another variation are Null-terminated strings in C. *
In other words, if you use a "special" value (here the delimiter) you have to make sure that the input (here keys) can't include them, and that's why you even have the freedom to chose the delimiter by setting $;
Such approaches happen constantly in programming and people make sure that such values are excluded, IFF they need the benefits. (For example by escaping or the choice of delimiter in q , qq or even << here-docs.)
Calling for deprecation doesn't make sense here, since one doesn't easily and accidentally stumble over this feature.
It's similar to goto , it's rarely used, doesn't cause problems, but is sometimes extremely handy to simplify an algorithm, where speed matters.
*) and yes I once got bitten by this because a badly written WMLScript interpreter couldn't distinguish between a NULL byte and the ASCII character "0". But this interpreter was buggy, there was otherwise no possibility to introduce a NULL-byte into a string.
| [reply] |
|
|
| [reply] |
|
|
I second you, cause it's very hard to construct a scenario where multi dim hashes cause a bug, even if the programmer was so naive to allow random keys.
And the statement:
> If your data contains the separator-character, the code breaks.
Is not true. The constructed key would have more separator characters but wouldn't "break".
I'd really like to see a believable example, maybe I am missing something?
| [reply] |
|
|
|
|
|
|
|
|
|
An example, AKA proof, is actually necessary when one makes an assertion in the sciences.
Firstly, examples are not proofs "in the sciences" unless they are counterexamples.
Secondly, this is misplaced pedantry. It really is quite obvious that, when you rely on metacharacters, your data had better not inadvertently include them. This is not an assertion that needs to be proven to anybody with a modicum of programming experience. AM was entirely correct on that point.
I'll agree that AM's admonition against using the feature was hyperbolic. Sometimes it is better to avoid the pitfalls of some language feature than it is to avoid the feature itself. And we are entirely capable of doing so. (As Rolf points out.)
-sauoq
"My two cents aren't worth a dime.";
| [reply] |
|
|
|
|
|
|
|
|
|
|
|
