develooper Front page | perl.perl5.porters | Postings from August 2012

Re: fixing smartmatch (again (still))

Thread Previous | Thread Next
From:
Peter Rabbitson
Date:
August 31, 2012 15:55
Subject:
Re: fixing smartmatch (again (still))
Message ID:
20120831150259.GA28937@compucapital.com
Interesting, my mail to the list itself got eaten... anyway

On Fri, Aug 31, 2012 at 10:42:05AM -0400, Ricardo Signes wrote:
> * Peter Rabbitson <rabbit-p5p@rabbit.us> [2012-08-29T09:00:47]
> > My 2c on this last point. The fact that you are having the same discussion
> > repeatedly over the course of a year indicates that the definition of this
> > feature does not "collapse" to a straightforward set of semantics, no matter
> > how many times you reexamine it. Combine this with the general drive to make
> > perl5 *less* ambiguous - and all of a sudden FC's suggestion seems the
> > sanest of all so far.
> 
> So far, my entire experience has been that it *does* collapse into a
> straightforward set of semantics.  I proposed them in 2011 and again in 2012.
> The discussion has largely been "let's add more cases," but those fail under
> the weight of their complexity.

This is so much like US congress ;)))

> So, I don't think the current ~~/when proposal introduces serious ambiguity.  I
> think if it gets rejected, it will be because its simplicity ends up meaning it
> brings too little utility to the table for the cost.

I do not feel this is actually the spirit of this thread. If indeed all we 
are still talking about is this:

> ## The New ~~ Operator
> 
>     $a      $b                  Meaning
>     ======= =======             ======================
>     Any     undef               ! defined $a
>     Any     ~~-overloaded       ~~ overloading is used
>     Any     Regexp, qr-ol       $a =~ $b
>     Any     CodeRef, &{}-ol     $b->($a)
>     Any     Any                 fatal

Then perhaps it would be beneficial to start *yet another* thread to 
explicitly solicit votes on the utility of such a change, with *no* 
modifications. A "take it or leave it" call for ++ or --.

In case this thread doesn't materialize, my yet another 2c on this issue 
alone: For me personally having an extra operator to service the above table 
is madness, but then again I feel the same about the utility of //=

> 
> I certainly do agree with the implicit suggestion that it would be insane to be
> having this discussion again in 2013. ;)

Right, and I am glad we are on the same page here. Regardless of the 
technical merits, please, by all means, whatever happens, do not give up 
until some sort of way moving forward is actually enacted (just agreeing on 
something is not sufficient on p5p).

rjbs++

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About