Re: Mr. Ternary is greater than Mrs. If Else

[Moron]

It seems to me that the strict refs section of the manual has gone a bit wonky. To understand all this now needs a bit of history.

Once upon a time there were compiled languages whereby subroutine parameters and indeed data referenced in the same scope could be passed around by a number of different ways: by name, by reference, by value, by descriptor being the four I know about. In a compiled language, passing by reference means simply by address instead of immediate value.

Perl has facilities for mimicking these mechanisms which I won't go into for all cases ... oh what the hell ... here goes:

by name: e.g. passing "fred" for access to $fred. This extends to anything passed literally, i.e. if you pass an expression by name, it is passed without evaluation for evaluation by whatever picks it up whereas by value it is first evaluated and then that value is passed.

by reference: this time there is no address because Perl is not a compiled language, so a Perl reference is the key in the *symbol table (see under though about Perl implementation).

by value: same as for compiled languages except that @_ is used instead of a system stack (or argument block for the case of Fortran) to pass parameters to subroutines.

by descriptor: a string descriptor for a compiled language is the starting address of two memory locations where one contained the length and the other the starting address of the string. Perl very probably uses string descriptors internally, but provides programmer access to them via the symbol table to get the string value and a length function to get at the length directly. Similarly, compiled languages sometimes have array descriptors but whereas Perl might probably uses them internally, access to them for Perl programmers is provided via the symbol table - the length of the array is in this case also symbolically accessed for Perl.

Compiled languages also use a code reference mechanism that Perl has mimicked - for compiled languages these are resolved into memory addresses by the linker - a linker takes chunks of ("object" machine) code that have symbolic references to each other and builds an image for loading whereby all the references (everything in the symbol table in fact) are resolved into relative addresses. The Perl interpreter does not do any linking but maintains code references in the (runtime) symbol table (update: compiled languages do not retain the symbol table at runtime unless a special debugging version is being compiled and linked).

Therefore ALL Perl references are "symbolic" which is a rather glib shorthand for "are maintained in the symbol table rather than using addresses in memory as references". (Update: but not all symbolic references are by name :))

(* It might be in terms of Perl implementation that there is a different symbol table implementation for different "types" - one for named and one for anonymous (in implementation, still having an internal id such as HASH + id), but however it might be split up, the collection of such implementations whether in separate structures or not is technically still "the symbol table" as far as Perl programmers can be concerned.)

If the manual were amended to (updated for readability):

"strict refs

"This generates a runtime error if you use symbolic named references (see perlref)."

update: perlref also needs to explain more clearly the distinction between named and anonymous symbolic references

Then the examples and the exception suddenly would make sense when related to the amended rule...

"There is one exception to this rule: $bar = \&{'foo'}; &$bar;is allowed so that goto &$AUTOLOAD would not break under stricture."

breaking this into pieces ... \& means taking a code reference but to get a code reference for 'foo' requires look-up by name in the symbol table. So a special exception has been made to allow named access to the symbol table even when strict refs is in force - get the rule right and at last we can see what the use of the word "exception" is all about.

__________________________________________________________________________________

Update: I would say, however, that the OP example isn't doing anything with the code references and can dispense with them. The OP example also isn't doing anything with what the terniary operator returns, so making a code reference of it doesn't do anything either and if-else is indicated. An example of where the terniary operator is indicated:

    
    my $batchsize = @ARGV && ( $ARGV[0] =~ /^-b(\d+)/ )
        ? $1
        : 1000;

Here the terniary operator prevents having separate assignments which would mean also having to declare the scalar separately from the assignments, making the terniary the more practical choice.