Thanx for the post.
I think the first problem was the introduction of smartmatch at all without much more discussion. As previously noted - not by me - the pathological set of combinations which triggered specific behaviour was, presumably :-), clear to Damian, but not us journeyman. We didn't ever need that complexity. It should have been introduced with a tiny number of cases handled (e.g. only 'eq'), and when that proved successful, expanded systematically to include other cases. Sigh.
Frankly I refused to use it when I saw the list of combinations. There is no argument based on alleged 'logic' that I will accept. The issue is: How does the average programmer understand the consequences of comparing $a with $b in far too many ways? If the mental load is so great - forget it.
So a major revision is, to me, no problem, as long as the cognitive load is as small as possible.
(I'm posting this without going via Preview because far too many times, and after alleged fixes to the code, I've been auto-expired, and hence lost the text).
Cheers Ron
]]>Lastly, yes, the choice of 'whereis and whereso' is so bad it's embarrassing, since they are too close to each other to be obvious /to beginners/.
]]>I suppose I should suggest an alternative to 'whereis and whereso'. Literally off the top of my head, because I did not analyse it, I'd say something like case(string) and case(integer) might be better.
Sorry, what's that? It clashed with preexisting code!? Hmm, maybe, perhaps, sort of - but not with quote-less usages of string and integer, right?
Merry Christmatch. Hahaha. Hohoho.
]]>Oh there was no dearth of discussion at the time. And I argued against it strenuously. Nobody seemed to hear, though. 5.10 was the release where p5p tried to implement as much of Perl 6 as possible in Perl 5… almost a decade prematurely. In the end the only thing worth the trouble was //
. In most other respects, that release was a disaster.
Frankly I refused to use it when I saw the list of combinations.
RJBS nailed it: “27-way recursive runtime dispatch by operand type”.
And when
is even worse than smartmatch itself, it has its whole own extra set of rules on top.
Maybe documenting some rationale for at least "whereso" would help
It's probably inspired by the so
function from Perl 6, which simply coerces its argument to Bool - like the not
function but without the negation.
Things like "appearing as a value in an array", and other complexities, would be better accomplished by their own operators or functions.
]]>If someone were to make a Yancy::Backend::MongoDB (for the official driver) or a Yancy::Backend::Mango (for the Mango driver), I would gladly add it to the core distribution. There is a standard set of tests that all backends should pass, and I can help anyone who wants to write a backend to get their tests passing either via a Github Pull Request or via e-mail (doug@preaction.me) or via IRC on irc.perl.org #yancy.
A MongoDB backend would enable very simple collections to be edited: A document could have only simple field/value pairs, not complex values like objects or arrays inside. To allow editing more complex data, the editor would likely need to enhanced to support it. To start, the editor could just allow hand-editing the JSON in the object/array, but in the future, I would want a full form to edit internal objects. This is on the roadmap, but it is not started (I will likely start this as part of adding relationships to the data).
]]>