Front page | perl.perl5.porters |
Postings from August 2012
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.
> 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. :-)
> 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.
> IMO doing them half-arsed is worse than not doing them at all.
I would disagree. Better half-assed, than totally arse-less.
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!
Of course, I'd much prefer fully integrated junctions throughout the
Perl 5 core. But, given that's extremely unlikely, then I'd still prefer
half-arsed junctions in the core, with the possibility (e.g. via
overloaded smartmatching) to maybe three-quarter-arse them.
>> If CodeRef testing comes first, I'm screwed.
>
> No you're not. If you solve the problem at the other end, it's
> possible to write a solution that would actually work.
Sure, but *I* can't write that solution (in Perl).
The core-elves would have to solve it.
And solving junctions was just one example. When the next new idea--
type objects, or grammar objects, or DNA alignment objects, or query
objects or constraint objects--needs to be implemented (or even just
prototyped as a class), we're going to need to overload smartmatching
on that too.
> That will require an approach that is much less superficial than what
> you're approaching here though, sadly.
I agree.
But since that is probably not going to happen for junctions, and even
more probably not going to happen for the other half-dozen sample
use-cases that I enumerated above, then I'd rather have a superficial
solution than no solution at all.
Damian
Thread Previous
|
Thread Next