Brent Dax writes:
> Damian Conway:
>
> # Brent Dax wrote:
> #
> # > method x ($me: $req, ?$opt, +$namedop, *%named, [EMAIL PROTECTED]) { ... }
> # >
> # > Yikes. And I thought we were trying to get *away* from
> # > line noise?
> # > :^)
However that's an example explicitly demonstrating all the variations.
In practice I'd've thought that many people will have a coding style
that nearly-always uses positional parameters and that many other people
will always use named parameters. And a C<?> to make an argument
optional isn't that hard to remember.
> # > Seriously, can't we use something rather prettier, like this?
> # >
> # > method x($me: $req, $opt is optional, $namedop is
> # > named, *%named, [EMAIL PROTECTED]) { ... }
> #
> # It's quite possible that the following equivalences might hold:
> #
> # ?$x same as $x is optional
> # +%y same as %y is named
> #
> # So that you could choose.
>
> Sweet.
I don't like the alternatives being available. Having more than one way
to approach things (named or positional parameters; typed or untyped
variables) is good; having more than one syntax for doing exactly the
same thing can be confusing.
Yes, there are other places in Perl with alternative syntaxes.
C<qq[...]> for C<"..."> is very useful. But it's at least similar
(punctuation before and after some text) and there's an excellent reason
why the 'standard' syntax is defective in some circumstances, and most
people use which ever syntax is most appropriate for the text in
question.
And there are places where an alternative syntax has been declined -- or
at least declined as a standard part of the language, leaving people
free to define equivalences if they want -- such as comments with
something other than C<#>.
My problem with the above alternatives is that they make the language
bigger: there's more to learn. Even if as an individual you decide just
to use on of the forms[*0] you still have to know the other version,
because you're going to encounter other people's code using it.
Things like this make Perl awkward to teach. For things like C<qq>
there's an obvious benefit, and it's worth it. But there doesn't seem
to be a benefit here, merely different people having different
preferences (which isn't surprising). Permitting both syntaxes (so that
people with a strong preference can use the one they personally prefer
and grimace at code written by those of the opposite persuasion) is an
uneasy compromise.
I'm concerned that this is an example of the '"Mozilla" preferences
problem': many discussions on features in 'Mozilla' led to the addition
of another preference so that different people can have the feature work
different ways. This shuts up both sides (of those who had strong views
either way), while bloating the program with yet another confusing
preference setting and baffling casual users as to why it contains so
many options rather than working right in the first place.
The second problem with the alternatives is that somebody who uses the
symbolic version and gets used to using it may scan a parameter
declaration that uses the wordy form. But not being used to the wordy
form, the crucial traits aren't spotted among the other words in there,
so he/she misinterprets the declaration.
It's not just a case of knowing about the alternative syntax, but the
fact that every time you read a declaration you have to check for both
versions -- "well, that's either a required positional parameter, or
it's something else which'll be described in a few words' time once I've
got past the type of this variable and a few other traits".
I'm not particularly bothered which syntax we choose (40% in favour of
the symbolic over the wordy) but much more concerned (85%) about there
only being _one_ syntax. (In other words, I'd rather not have the
syntax that I prefer than have multiple alternative syntaxes).
[*0] And it strikes me as quite likely that most people will fix on
one of them -- why would anybody flip between them? -- which provides
another source of pointless style arguments.
Smylers
