On Mon Jun 15 06:12:13 2015, mt1...@gmail.com wrote: > On 06/13/2015 04:06 PM, Elizabeth Mattijsen (via RT) wrote: > > Hi, > May I react on this? Would it be easier to have perl6 throw an error > when there is a named parameter in the call while it isn't defined in > the method. Something like 'Named parameter 'x' not defined by push' > in > the example set below. It would start me thinking... It would in any > case be better than saying nothing. >
Methods ignoring unknown named parameters has been discussed many times over the years. The reason they do so is to properly support deferral to base classes, which may not know how to handle options that subclasses add. We've seen practical use of this, and I believe there's even an outstanding ticket that's a result of NQP's methods failing to do this (when we delegate to an NQP method from a Perl 6 one in Grammar.parse, if I recall correctly). In general, methods are late bound and flexible, subs are compile-time-bound and more restricted. So methods being more forgiving over unknown named parameters fits the pattern. More notably, nobody in the years of discussion on the topic has proposed a viable alternative that keeps deferral working. You can't do it with a static analysis because the place you need the ignoring to happen it is in the target of a deferral, and that could be any method. There's no sensible way I can see to track usage of the nameds down the call stack (defining "usage" is hard enough, and even then I suspect the performance implications would not be pretty). In summary, there's a design trade-off here, and we've come down on the side of "let's make inheritance useful". Thus, ticket rejected. /jnthn
