Aaron Sherman wrote:
I certainly hope not, as I agree with you! That's not the goal at all,
and in fact if that were a side effect, I would not want this to be
implemented. The idea of having types AT ALL for protos was something
that I threw in because it seemed to make sense at the end. The really
interesting thing is to match signature shapes, not types. That is, max
doesn't take two positional arguments, and a max that does is probably
doing something that users of max will be shocked by. To this end, a
programmer of a library *can* issue an assertion: all implementations of
max will take one (no type specified) positional parameter and any
number of adverbial named parameters (again, no type specified).
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 {
...
}
Of course, I hadn't quite thought this through - as packages aren't
classes, there would probably have to be heavy constraints on what
FooMultiPrototypes may declare.
This would also allow you to reuse multi prototype sets.
Also, I don't think you answered Trey's concern, that your mechanism
allows you to declare what classes may export but not what they *have*
to export, which I would also view as more important - your mechanism
seems to only serve to ban extensions and convenience methods, but
doesn't give any extra promises on the class behaviour. To extend your
example, if a library developer provides a three-argument max, it won't
get in the way and won't break any existing contracts. But if the same
developer doesn't also provide 2-argument max on that same class, it may
very well break any code that works with that class.
