Re^2: Curious: are anon-hashes in random order? (updated)

[perl-diddler]

So constant will always define four subs, which return the value associated with each key in the hash. It is equivalent to the following code; the order in which the subs are defined does not matter. (By the way, I think that defining subs with the same name as those Perl builtins is likely to cause confusion later.)

Never has in my usage -- you have to use the constants prefixed with '&' -- while putting '&' in front of those keywords is guaranteed to cause an error. So how could it cause confusion?

If I understand mem correctly, it's essentially doing the same thing as the code with the BEGIN block above. Also, remember that use Module LIST is exactly equivalent to BEGIN { require Module; Module->import( LIST ); }.

Well, as mentioned elsewhere, it's a side effect of perl, not really a feature of mem -- though mem supports the side-effect in perl by guaranteeing not to throw an error for that type of usage, making it an ideal candidate for the shorter usage.

mem's primary purpose was to allow packages that were already defined in a file to be "used" from the "in-memory" copy already parsed, rather than searching through your module path on disk, as is perl's default behavior. It allows easier inclusion of multiple "packages" in the same file -- which makes sense when the packages are related, meant to be data structures, or similar. Of course mem is only needed when you are 'use'ing the module vs. having the module function as a data structure.

When I declare struct's in perl, it takes about 3-4 lines (sorry, Data::Vars, is _still_ in my personal library and hasn't be cpanned yet -- stable, but publishing it would require alot of added tests and docs to be written), but using it is fairly simple:

> tperl  # an alias
{ package foo;
  use Data::Vars [qw(a b c) ], {c=>sub{ {} }};  #c gets a default
1}
package main;
my $p = foo->new({a=>1});        # a passed as arg
$p->b = [qw(one two three)];     # b assigned to at runtime
P "p=%s", $p;                    # and result
'
p=foo{a=>1, b=>["one", "two", "three"], c=>{}}

The primary purpose behind most of my modules is to simplify, save space and unnecessary typing. FWIW, 'c' is initialized with a sub around the hash so the same hash isn't assigned to each new copy of the data-structure.

[choroba]

> use the constants prefixed with '&'

But then it's not parsed as a constant, i.e. it isn't inlined:

$ perl -MO=Deparse -e 'use constant c => 42; print c; print &c;'
sub c () { 42 }
use constant ('c', 42);
print 42;
print &c;
-e syntax OK

[haukex]

Hi perl-diddler,

So how could it cause confusion?

You as the author may be able to keep track of the keywords vs. subs, and Perl may be able to resolve the ambiguity most of the time, but it's not too difficult to accidentally cross the line where Perl may pick the wrong definition (for example, there's the warning "Ambiguous call resolved as CORE::continue(), qualify as such or use & at ..."). Also, another reader of your code (including a future maintainer - or even your future self) could easily become confused between next and &next, etc.

It's just one of those cases where as long as you know what you are doing and your script isn't intended for distribution then it's probably fine; but if you do intend the code for a wider audience then I was just pointing out that there are some good rules of thumb / conventions, such as not to define subs with the same name as Perl builtins unless you intend to replace them, and that constant names are typically uppercased.

Regards,
-- Hauke D

[perl-diddler]

Well, in this case, the code had been in a loop. The loop got large, so moved contents out, but then the loop control words no longer worked. In this case, the loop control words made it clear the derived sub, where the code in the main loop would go next. I used those constants (and have done similar in the past) for exactly those reasons -- even though the loop contents were no longer "inline", due to the use of such constants to indicate what they did in their previous loop the code was actually easier to understand -- more clear.

If I had come up with a new or different set of constants, I don't think it would have been as clear. As for constants being upcased? That's so 80's. :-) Seriously -- all caps hurt my eyes and fingers typing -- I'll usually capitalize something, but there are many cases where doing so hurts perception and understanding.

An example would be several math constants (displaying these on pm in code blocks, is bugged, so you'll have to use your imagination a bit: ( But the 3 chars are Φ (Phi), ɸ (phi) and π (pi) ).

  sub Phi () { .5 * (5.**.5 - 1) }   sub Φ  () { goto &Phi }
  sub phi () { .5 * (1. + 5.**.5) }  sub ɸ  () { goto &phi }
  sub pi  () { 4 * atan2(1, 1) }     sub π  () { goto &pi }

If you upper-cased these, how would you tell Phi from phi. In the greek names (on the right which display as characters on modern systems), they are also the upper and lower case version of the greek phi. Pi, uses a lower case 'pi' just as it is in the english text version.

Anyway, it's all about context... ;-)...