TSa wrote:
HaloO,
Miroslav Silovic wrote:
What bugs me is a possible duplication of functionality. I believe
that declarative requirements should go on roles. And then packages
could do them, like this:
package Foo does FooMultiPrototypes {
...
}
I like this idea because it makes roles the central bearer of type
information.
Type information is secondary to the proposal, but I'll run with what
you said.
This (the example, above) is a promise made by a class to meet its own
specification.
In the RFC, I was trying to develop a method by which a module could
assert a stricture (consider this part of "use strict" in Perl 6 if you
will) that would constrain the CALLER of that module (as well as the
module itself, of course) to a particular signature template for a
multi. This allows us to centrally document a multi that might be
defined in many places, and have that documentation actively constrain
the multi to match. In this way, the user doesn't have to figure out
that max is a method on Array in order to find its documentation, and a
module that uses Array gets
Constraining a class to use the multis that it declares isn't really a
constraint. It's more of a second definition, and there isn't much need
for that in Perl 6.
I'm starting to think that "proto" was the wrong word, as it immediately
makes people think about C/C++ "prototypes", which are not at all the
same beast.
Of course, if you want to have a role that uses prototypes to constrain
a class, that's certainly doable:
role StrictMax { our proto max(Array @array) { ... } }
class MyClass does StrictMax { ... }
Sure, that works, but an unexported, type-specific proto is rather a
weak version of what I was suggesting.
Again, here's the example that I gave at the end:
=item max
=inline our proto max(@array, *%adverbs) is export {...}
C<max> takes an input sequence or array (C<@array>) and
returns the maximum value from the sequence.
Specific implementations of max may be defined which
allow comparators or other adverbs (C<%adverbs>) to
be defined.
=cut
