develooper Front page | perl.perl5.porters | Postings from December 2017

Re: Revisiting smart match

Thread Previous | Thread Next
Leon Timmermans
December 24, 2017 18:02
Re: Revisiting smart match
Message ID:
On Sun, Dec 17, 2017 at 12:10 PM, Zefram <> wrote:

> With Sawyer's approval, I have merged the zefram/dumb_match branch into
> blead.  Sawyer expressed a desire for some examples in the documentation,
> so that still needs work.  But with the code getting into 5.27.7, we
> can get started on fixing the inevitable CPAN breakage.

So, I posted about this change outside of this tiny echo chamber [1], as
has brian d foy[2], and here are some of the reactions:

* This is an alarmingly bad design decision
* if whereis/whereso is confusing to me, a native english speaker, I can
only imagine what others would make of it
* Welp, that's going to break more than a few of my programs.
* I've never used smart match before, as I never felt it would fix any of
my problems, and this post convinced me I will never bother with ,in any
form or incarnation.
* I find whereso and whereis rather confusing, and if I'd use them I'd have
to consult the manual every time
* Unfortunately when/whereis/whereso are not among the keywords exposed as
functions in CORE::, so it is hard for me to see how to write code that
works across the divide other than (yukk!) stringy eval or (double yukk!)
source filters.
* 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/.
* p5p screwed the pooch on this.

Note in particular the lack of anyone saying they would want to use this
thing. We're dealing with a stillborn baby here; no one wants this

The problem here really is really a complete lack of organized process. In
particular two things were absent. The first is involvement of our
userbase. A simple survey could have revealed how they're using it now,
what issues they face and what features they may want. Likewise
communicating back about what our plan is would allow  The second is a lack
of defining what our problem with smartmatch is, and what we need from it
in the future, and how we transition between those states. Lacking that, we
just can't explain why these decisions were made. They still largely look
arbitrary to me despite following the discussions.

Quite frankly, I can't think of any way to fix by reverting this, and then
not try again until we have an actual plan of action.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About