Austin Hastings <[EMAIL PROTECTED]> writes:
> --- Piers Cawley <[EMAIL PROTECTED]> wrote:
>
> >
> > Both of your proposed options are, frankly, vile. The
> > multimethod/generic function approach has the advantage of putting
> > the 'burden' of writing the generic function on the implementor
> > rather than on the user. Given that implementation happens once
> > and something is used countless times, that seems like a decent
> > trade off to me.
>
> Dictionary.com sez:
>
> "vile
> adj. vil·er, vil·est
> 1. Loathsome; disgusting: vile language.
> 2. Unpleasant or objectionable: vile weather. See Synonyms at
> offensive.
> 3.
> - a. Contemptibly low in worth or account; second-rate.
> - b. Of mean or low condition.
> 4. Miserably poor and degrading; wretched: a vile existence.
> 5. Morally depraved; ignoble or wicked: a vile conspiracy."
I choose 2.
> Is this one of those BOFH things where you insult the hell out of
> someone and then give them a pat on the head, and six months later
> they're arrested while sneaking into the London Zoo wearing a
> leather corset and silk panties? (*)
I gave him a pat on the head? I told him that his proposed solutions
were unpleasant or possibly loathsome, and that he should throw them
away and stick with my proposed generic subroutines solution and you
call that a pat on the head? Coo.
> Otherwise, I'm left to wonder. As I read Mike's post, he's proposing
> that we regularize a feature of the language, make it extensible,
> and potentially use a conceptual framework based on an existing
> syntactical element.
>
> Yours, on the other hand, gives (I hope) the extensibility, doesn't
> require the syntactic bits but does appear to require that every
> such method be implemented twice.
Um. Not really implemented twice no. One subroutine implementation
can act as the facade for an awful lot of overloaded methods in the
class. Look at the grep implementation again:
class Array {
method grep ( Block &block ) {...}
method grep ( Rule $rx ) { ... }
method grep ( rx/<expr>/ $expr ) { ... }
sub grep ( Object $selector, @*ary ) is exported { ... }
}
A single generic sub is used to provide a functional interface to a
bunch of methods. Now, when we add grep behaviour to the
'CunningCollection' class, we will need to overload the generic sub
so that, in the case of
grep .selector, $some_cunning_collection;
the $cunning_selector doesn't just get stuffed into an array. One
could also imagine a scenario where someone implements a new
'selecting' object:
class NewSelector {
method grep ( $self: @*args ) {
grep $self.as_block, *@args;
}
sub grep ( NewSelector $selector, @*args ) is exported {
$selector.grep( *@args );
}
}
And I fail to see how Mike's proposed syntax will deal with
this. Remember that the one time (per class admittedly) cost of
setting up a generic sub buys us a good deal of not having to use
gratuitous punctuation (or ghod help us 'is given') at use time.
map { .[0] }
sort { $^a[1] cmp $^b[1] }
map { [ $_ => some_transform($_) }
grep /.../, @array
happily stays as it is; I fail to see what recasting that as
map { .[0] } <-
sort { $^a[1] cmp $^b[1] } <-
map { [ $_ => some_transform($_) } <-
grep /.../, @array
or any other 'noisy' suggestion buys us. It just seems like the wrong
kind of Laziness to me.
