Front page | perl.perl5.porters |
Postings from September 2008
2008/9/29 David Nicol <davidnicol@gmail.com>: > On Mon, Sep 29, 2008 at 11:11 AM, Moritz Lenz > <moritz@casella.verplant.org> wrote: >> >> how could that be possible? Remember, prototypes change the parsing. If >> you have one sub foo() and one sub foo($), you'd get an ambiguous parse >> tree. > > Sensible rules for resolving such ambiguities are obviously needed. > One possibility is that ambiguous combinations would not be allowed. > Another possibility is longest wins. Longest wins would work for > unlink. > > foo; # would resoves to foo() > foo 27; # would resolve to foo($) > > >> Also &foo doesn't do prototype check von sub foo, so having multiple >> foo's with different prototype would lead to weird behaviour. > > &foo could be a syntax error after declaring polymorphic foo. What about runtime lookup, like $x="foo";&$x ? > Alternately, it could defer disambiguation to run-time, depending on > the current contents of @_. Alternately, it could invoke a > prototypeless foo or die in the absence of such. Prototypes in perl are more a mean of changing syntax, than doing type checking. Type matching will be a mere heuristic, and likely to confuse the users in every edge case. And run-time argument checking will be a sure way to slow down function calls...Thread Previous | Thread Next