Front page | perl.perl5.porters |
Postings from August 2012
On Wed, 2012-08-22 at 21:44 +1000, Damian Conway wrote:
> So, in light of those discussions, here's my current preferred option...
> ______________________________________________________________________
>
> Smartmatch (~~) table
> =====================
>
> $a $b Meaning
> ===== =================== ========================
> Any undef ! defined $a
> Any ~~-overloaded [1] $b->ol_method($a, 'rev')
> ~~-ol Any [1] $a->ol_method($b)
> Any CodeRef, &{}-ol $b->($a)
> Any Regexp, qr-ol $a =~ $b
> Any unambiguous Num [2] $a == $b
> Any unambiguous Str [3] $a eq $b
> Any Any die
>
>
> [1] Includes junctions, whose overloading distributes the
> smartmatch over their elements in their several ways.
>
> [2] If $b has an internal numeric representation but no
> internal string representation (or if some putative
> internal flag assures us it was originally a number).
>
> [3] If $b has an internal string representation but no
> internal numeric representation (or if some theoretical
> inner flag promises us it was initially a string).
Do you have any specific use-case for bidirectional overload acceptance?
The ~~ operator seems to be closer to =~ than == (or eq) semantically,
so the sides have different meaning. This is how I'd see it:
23 ~~ $obj # does 23 match the overload?
$obj ~~ 23 # does the $obj match 23?
I can see how this would be useful for some object types. But it also
might make certain other cases impossible. Say I have an object
representing a type itself:
23 ~~ $IntType
$IntType ~~ 23
I'd find it odd if that would work, but won't if I represent the type
check as a code reference. Also, I wouldn't be able to match the object
itself, right? For example:
$IntType ~~ sub { ... }
would ask the object on the left to match, but not the code reference?
This also means that an externally passed object could, unintentionally,
change the meaning of my given/when constructs.
Is it maybe possible to have separate overloads for 'smartmatcher' and
'smartmatchee' (couldn't find better terms right now)? I think that
would resolve this problem, while still allowing objects to smart-match
in a specific way.
> The when construct
> ==================
>
> Form Meaning
> ================== ==================================
> when (EXPR) {...} if ($_ ~~ (EXPR)) {...; break}
> when {BLOCK} {...} if ($_ ~~ sub{BLOCK}) {...; break}
I do wonder if `when {...}` could (internally) be an `if (do {...})`
instead of `if ($_ ~~ sub { ... })` for performance reasons, but that's
a different matter.
I fully agree with the rest of your tables.
regards,
--
Robert 'phaylon' Sedlacek
Perl 5 Consultant for
Shadowcat Systems Limited - http://shadowcat.co.uk/
Thread Previous
|
Thread Next