Front page | perl.perl5.porters |
Postings from August 2012
* Peter Scott <Peter@PSDT.com> [2012-08-31T16:04:53]
> I'm afraid I have gotten lost among the proposals. The original one
> in this thread included:
>
> Any Simple $a eq $b
>
> got whittled down to "unambigous Num/str", but I missed the part
> where that was removed altogether. FC's post of restricting ~~ to
> *only* Scalar/Simple was where I chimed in, although perhaps I
> missed a nuance in how he proposed special-casing it.
FC's suggestion was that when have three meanigns:
when (NUM) { ... } # numeric literal, means $_ == NUM
when (STR) { ... } # string literal, means $_ eq STR
when (EXPR) { ... } # other expression, evaluates normally as in "if"
Smartmatch (~~) was to be abolished.
> I objected to the original/current table for the same reasons AFAICT
> as you do. I'm afraid that your proposal, while much smaller and
> probably memorable, if it doesn't include a Simple case, will spawn
> a neverending chorus of "Why can't I do 'when (42)'?" That seems to
> be the *only* use case that some people want ~~ for and it seems
> quite reasonable for them to want it.
I did not eliminate when(42), but $x~~42.
That is, ~~ must have an entry from the table on the rhs. Only when is special
cased. The thinking here is that nobody is clamoring to put a numeric or
string literal on the right hand side of ~~. It saves nothing over eq or ==.
On the other hand, eliminating the first two tokens in "$_ eq 'foo'" or
"$_ == 4" in each when statement like that is a win.
This means that ~~ has exactly four valid types of rhs, which you agreed were
simple and probably memorable. When has three behaviors: numeric literal,
string literal, and "anything else," where the final case is taken as the rhs
to a smartmatch, with the topic as the lhs.
I think this means your remaining objection is that it is too confusing that
these two things differ:
when (42) { ... }
$x = 42; when ($x) { ... }
> Yet I can't see the Simple case working because of the string/number
> dichotomy that has been hashed over and over. And if they *can* do when(42)
> then they will want to do when($ULTIMATE_ANSWER) and when(ULTIMATE_ANSWER)
> and if they can't, it becomes embarrassing to try and explain why.
I agree that it could prove a point of confusion. I'm not sure I think it's a
big point, or the sort of thing I'd be embarassed by, but I agree it's not the
simplest thing possible.
Where else do we require a numeric or string literal rather than anything else?
As the VERSION argument in 'use' or 'require' for one... and nothing else
springs to mind. Right now I'm on the fence, anyway.
Please let me know if there's more to your remaining objections than that.
> I think this tunnel has no light at its end. IMHO. Sorry.
No need to feel sorry! :) If it turns out that this is the case, I'll be
very glad to have had your input on sorting it out. I think no matter what,
we'll feel better than we did with the current when and smartmatch. ;)
--
rjbs
Thread Previous
|
Thread Next