HaloO, On Saturday, 14. June 2008 18:43:05 Daniel Ruoso wrote: > Moritz convinced me that there's actually no real reason to support > > $nonlist.listmethod
I wouldn´t do that either. But I come to that conclusion from the line of thought that it is generally a bad idea to block an Any slot in a multi for a mere casting operation. The whole point of type based dispatch is to name the intended type in the first place. That is, a programmer choosing the item sigil $ in combination with a list operation should be punished with a dispatch error if he doesn´t know for sure that everything he sticks in the variable is a list anyway. Note that the other way around is bloody easy in Perl 6. A @ variable can handle items just fine! I´m aware that this makes me opt for solution three, the dropping of fallback from method to sub dispatch. But I consider that a good thing. They are nicely distinct syntactically, so why mix them semantically? > And if we stop, and think for more two seconds, we realise that > supporting that could end up having a lot of non-interesting side > effects, because an exported sub with the signature :(Any, Str) is most > likely to have a lot of false hits. Technically there are no false hits on an Any slot ;) In the case at hand it listifies the item and re-dispatches. IOW, the false hits will be surprises for unaware programmers who get unexpected dispatches silently. BTW, there´s the same problem with stringification of the separator. Combining that with the listification would end up blocking &*join:(Any,Any) globally. Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare "Simplicity does not precede complexity, but follows it." -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
