Front page | perl.perl5.porters |
Postings from August 2012
On Fri, Aug 24, 2012 at 1:40 AM, Damian Conway <damian@conway.org> wrote:
> Leon Timmermans wrote:
>
>> I suspect in practice junctions may be the only use-case for it. I
>> can't think of any other use-case.
>
> Interesting. I can think of numerous other use-cases...
>
> 1. In this very thread we've already seen Robert Sedlacek excellent
> suggestion for type objects, for which I've already demonstrated
> several possible ~~-overloadings.
>
> 2. I'd also very much like to be able to overload ~~ for
> Regexp::Grammar objects.
>
> 3. And I can imagine that a similar overloading of ~~ for objects
> encapsulating Marpa grammars would be of even greater value.
>
> 4. The bioinformatics people might well like to be able to overload
> ~~ to perform searches or alignments on objects representing DNA
> and RNA sequences.
>
> 5. I can also imagine ~~ overloaded to support Query objects:
>
> if ($db ~~ $query) {...}
>
> 6. And I already have plans to allow InputConstraint objects, for
> abstracting input filtering using my IO::Prompter module, by
> being internally smartmatched:
>
> my $input = prompt 'Enter a number', must=>$constraint_obj;
>
> In fact, in almost any circumstances where I want an API to offer client
> code some kind of inversion-of-control, it's likely that I'll want to
> clients to be able to pass an object or class encapsulating that
> control, which my code will then smart-match against.
>
> So I think there are, in fact, endless use-cases for overloaded
> smartmatching.
As doy already explained, I have an issue only with LHS. In fact I
wrote Smart::Match, I'm absolutely convinced that right handed
overloading is useful and sensible. It's left handed overloading that
seems problematic to me.
>> Why do you expect that to work with smart-match when it doesn't with
>> subroutine calls, or a dozen other things?
>
> Because then at least there will be *one* way to make it work
> correctly. :-)
I don't find that a convincing argument. That's 5.10 logic to me.
Getting it out now is not better than getting it right.
>> If ¬«is_prime(any(9,10,11))¬» is not equivalent to ¬«any(is_prime(9),
>> is_prime(10), is_prime(11))¬», it's not a junction in the first place.
>> It's just an abstraction that fakes it half of the time and leaks like
>> a sieve the other half. Supporting them in a few circumstances and not
>> in others seems silly and wrong to me.
>
> Well, I agree. But doing them full-arsed will require fundamental changes
> to Perl 5's subroutine and method dispatch semantics. And I don't believe
> that's being proposed...or even contemplated.
I can imagine a «use junctions» CPAN module that would enable it, it's
'just' a matter of rewriting ops. Though I'm not sure it would work
well with other Perl 5 features.
>> IMO doing them half-arsed is worse than not doing them at all.
>
> I would disagree. Better half-assed, than totally arse-less.
I think core should have higher standards than that; we shouldn't add
features that lightly.
> It's like OO. Until the advent of Moose, Perl's approach to OO has
> always been half-arsed. But better that half-arsed OO than to have had
> no Perl OO at all for the past two decades!
However, fact is that we can build Moose on top of our traditional OO.
It's unfriendly and cumbersome and a whole bunch of other adjectives,
but you can build something seemingly sensible and complete on top of
it (even if the insides are sometimes non-sensible). That is a trait
I'm missing in what you're proposing.
Leon
Thread Previous
|
Thread Next