TSa wrote:

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

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.


Reply via email to