Front page | perl.perl5.porters |
Postings from August 2012
On Wed, Aug 22, 2012 at 02:58:45PM +0200, Robert Sedlacek wrote:
> 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.
I agree - I'm curious to see what the actual use cases for this table
element are, since it's the one part of this proposal that I'm still
kind of questionable about.
-doy
Thread Previous
|
Thread Next