MJD> That is evidently not the case here.  The four strings were
  MJD> hardwired into a compile-time list constant.

the specific case here may show hardwired sub names. but that is rarely
the case and the problem could be solved with multiple methods. showing
a symref solution which may be ok here will potentially influence others
to use it where it is dangerous. that is a prime reason never to show
any symref solutions, especially here where there are many newbie eyes.

  MJD> I do not see the purpose of checking members of a compile-time
  MJD> list against the keys of a compile-time hash for verification.
  MJD> If you don't trust the list, why would you trust the hash?  Why
  MJD> wouldn't you check the hash keys against a second hash, just to
  MJD> be double sure?

the dispatch table is a also style to protect against potential
changes in the future as well. the OP never said that the list of sub
was fixed or would be permanently hardwired. i prefer to make the
assumption the code will change as we all know code does change.

  MJD> Yes, but in this case the addition flexibility does not appear to
  MJD> be required.  So you would be paying a programming and
  MJD> maintenance cost for an unnecessary feature.  This violates the
  MJD> rule that says that everything should be as simple as possible.

or as simple as possible for a reasonable amount of safety and
flexibility. applying the simple as possible rule only leads to no
strict as who needs the clutter of declarations?

  >> a dispatch table allows this to work under use strict

  MJD> That is not a benefit.  'use strict refs' is only a means to an
  MJD> end, to avoid certain types of reference *errors*.  Those errors
  MJD> are not relevant here.  To argue that symbolic references are bad
  MJD> *because* they result in 'strict' failures is circular reasoning.

that may be correct, but it is a useful way to discuss it with
newbies. we emphasize use strict to eliminate the newbie use of
symrefs. but that always isn't clear so saying that that solution won't
run under strict refs can be easier to understand.

  MJD> At best, your argument shows that 'strict refs' may be defective,
  MJD> because it may impede this entirely non-erroneous use of symbolic
  MJD> references.

i think it is an erroneous use of symrefs. there is no compelling reason
to use symrefs here so they shouldn't be used. symrefs should be used
when there is no other reasonable solution. a dispatch table is a very
reasonable solution here.

  >> it doesn't matter that subs are being used here instead of variables,
  >> symrefs can lead to all sorts of hard to fix problems and are
  >> obsfucating at best even when they work

  MJD> That is a non-reason.  "It causes problems" is just FUD unless you can
  MJD> identify a real problem that is caused.  So far you have not done so.

  MJD> Zero reasons is not enough, no.

then we disagree. i reiterate what i have said before, unless you know
when not to use symrefs, you should not use them. they are not needed
for basic stuff like sub dispatching. sure they work and sure the
newbies who ask for a way to create variables by name can use them as
well. discouraging its use for simple stuff is worthy in and of
itself. that is one reason there. allowing for flexibilty in the future
by having the keys not always match the sub names or controlling which
keys can call which subs are two more reasons for dispatch
tables. assuming hardwired sub names and keys is very limiting and
potentially dangerous. also it leads newbie to think that symrefs are ok
which is bad in general.

uri