* Aristotle Pagaltzis <pagaltzis@gmx.de> [2015-09-11T17:25:04] > However, there is one case for it: if `when` is defined in terms of > smartmatch, then these rules would allow writing e.g. > > given ($mode) { > when ('enable') { ... } > when ('disable') { ... } > # ... > } I have a lot of sympathy for this position, and maybe I'd say I'm on the fence, but I lean heavily to not doing it (yet) because I start to lose my mind when these differ in behavior so radically: my $x = 1; ... when 1; ... when $x; I would be happy to be convinced, here, so have at me! Perhaps the real issue is documenting this in a way that makes the above not surprising, even if you only read the first few lines of the docs. I'm not sure. * Aristotle Pagaltzis <pagaltzis@gmx.de> [2015-09-11T18:04:29] > That said, I think this could be acceptable, but for one thing: that it > uses the same overload method for $x ~~ $obj as for $obj ~~ $x. Ugh, tell me about it. When I wrote the ~~ overloads, I was unhappy by the crap needed. Maybe we should add ~~x and x~~. Using the third arg to the overload sub (a) is tedious (b) will lead to mistakes (c) makes the feature feel unnatural. With x~~ and ~~x, ~~ could become a deprecated fallback during the transition. Writing sample code that overloaded ~~ really made this clear. (See my previous post.) > > but it has the practical benefit of keeping autodie working. > [...] > But if I understand the problem correctly, it’s not the code of autodie > itself, it’s the interface that autodie has advertised so far, i.e. the > cost we’re talking about isn’t patching autodie itself, it is patching > all of the users of the autodie smartmatch interface. Is that correct? That is correct. autodie enthusiastically embraced ~~, encourating users to write: given ($@) { when (undef) { say "No error"; } when ('open') { say "Error from open"; } when (':io') { say "Non-open, IO error."; } when (':all') { say "All other autodie errors." } default { say "Not an autodie error at all." } } -- rjbsThread Previous | Thread Next