Front page | perl.perl5.porters |
Postings from June 2008
2008/6/27 Yuval Kogman <nothingmuch@woobling.org>:
> I can't find the thread where this was discussed.
>
> I think the but the new mandatory overloading for smartmatching of
> objects is too restrictive.
>
> Here are a few cases that I think could be changed:
>
>
> ./perl -Ilib -E 'my $obj = bless {}, "Foo"; $obj ~~ sub { 1 }'
> Smart matching a non-overloaded object breaks encapsulation at -e
> line 1.
>
> The subroutine in question does not break encapsulation in this
> particular instance and there are many valid uses.
Agreed.
> ./perl -Ilib -E 'my $obj = bless {}, "Foo"; $obj ~~ $obj'
> Smart matching a non-overloaded object breaks encapsulation at -e
> line 1.
>
> This case could be refaddr equality, comparing an object to itself
> doesn't sound like encapsulation breaking to me.
>
> Likewise all comparisons of non overloaded objects which aren't the
> same could just return false.
Not sure about that.
> ./perl -Ilib -E 'my $obj = bless {}, "Foo"; $obj ~~ "Foo"'
> Smart matching a non-overloaded object breaks encapsulation at -e
> line 1.
>
> This could be repurposed to call ->isa, it's *VERY* useful for
> checking exceptions.
>
> The problem is that the string would of course return true for
> $obj = "Foo" or $obj = ["Foo"], so this case is ambiguous, and maybe
> not such a good idea.
Indeed. But with $obj ~~ sub { $_[0]->isa("Foo") } you can implement it safely.
> ./perl -Ilib -E 'my $obj = bless {}, "Foo"; warn $obj ~~ undef'
> Smart matching a non-overloaded object breaks encapsulation at -e
> line 1.
>
> perlsyn says:
> Any undef undefined !defined $a
>
> !defined($obj) does not break encapsulation IMHO
Agreed.
> And while we're on the subject:
>
> ./perl -Ilib -E 'warn sub { warn "First" } ~~ sub { warn "second" }'
> Warning: something's wrong at -e line 1.
>
> ./perl -Ilib -E 'warn sub () { warn "First" } ~~ sub () { warn
> "second" }'
> Warning: something's wrong at -e line 1.
>
>
> This seems to contradict the documentation that implies that
> subroutines with a prototype of "" are treated more like values
> (which fwiw I think is wrong, I prefer the current behavior that
> compares refs, if I wanted to check the value i'd deref the sub)
Another bug...
> At any rate
>
> Code() Code() results are equal $a−>() eq $b−>()
>
> doesn't seem to apply to anything.
>
> I'd argue that anyway it ought to be $a->() ~~ $b->() but I don't
> see that it's ever used.
Yes.
Send patches for all those points?
Thread Previous
|
Thread Next