Jonathan Worthington wrote: > Jon Lang wrote: >> >> Invocants: >> >> * Does anyone object to roles having an invocant, and that invocant >> referring to the class that is doing the role? >> >> > > Yes; on further reflection, the ability to type that invocant raises all > kinds of possible WTFs without a good enough use case. So I'd really rather > we don't go down this road.
How does this situation differ from the ability to type a method's invocant? I'm thinking that an argument might be made that you don't get to specify any invocant's type: a method's invocant would always be typed as the class to which it belongs (with the value set as the object calling it), while a role's invocant would always be typed as a type reference (i.e., the :: sigil), with the value being the class composing it. Would any significant functionality be lost in such a move? >> Longnames: >> >> * Are placeholder parameters ever considered to be part of a >> function's longname? (I'm expecting that they aren't: if you want a >> longname, you ought to specify it in a formal signature.) >> >> > > Placeholder parameters result in a signature being generated based upon > them, as far as I can tell (and so far as we've implemented in Rakudo). So > yes, they would all count in the long name - or at least, the positional > ones. Also note that if you do have placeholder parameters it's illegal to > write a signature on the block too. True: forbidding placeholder parameters from counting as part of the longname would effectively forbid functions that use placeholder parameters from _having_ a longname; and if you've explicitly asked for one (via the "multi" keyword), you should get one. >> Placeholder parameters: >> >> * does the use of placeholder parameters interfere with the use of the >> slurpy parameters normally provided by the default signature (i.e., >> *...@_ and *%_)? I'm guessing not. >> > > We only generate *...@_ and *%_ for subs when there is no signature; the > presence of placeholder parameters generates a signature, so you'd not get > them. Exception: methods, where by S12 we always add a *%_ unless the method > defines its own slurpy named parameter. Is this the desired behavior, or merely the current behavior? I can see a case for wanting the placeholder parameters to be pushed onto front of the default signature instead of replacing it. -- Jonathan "Dataweaver" Lang
