> I believe this example captures an important requirement that has been
> expressed both by Bill Janssen and by Andrew Koenig (needless to say I
> agree): abilities should be able to imply contracts that go beyond a
> collection of methods (without necessarily being able to express those
> contracts in code).
Yes. For that matter, I would like an ability to be able to say things
about a + b regardless of whether it happens to be implemented through
__add__ or __radd__ -- which is yet another reason why abilities need to be
more than just collections of methods.
> Note that I haven't shown syntax for declaring the various abilities.
> That is because I don't have a concrete proposal yet. However, I would
> prefer syntax that looks declarative (similar to a class declaration)
> for the normal case.
A thought borrowed from ML: You wrote
def __and__(self, other: MinimalSet):
and that reminds me of ML's syntax:
fun f(x, y: MininmalSet) = (* whatever *)
In the ML version, we're saying that f's first argument can be of any type
(that meets whatever other type constraints are implied by f's body, and the
second argument must be of type MinimalSet in addition to those constraints.
Seeing this analogy, I am tempted to carry it further. In ML, I can write
val foo = bar: MinimalSet
which binds foo to the value of bar, and also implies a (compile-time) type
check that bar has type MinimalSet. So consider extending that analogy to
Python:
foo = bar: MinimalSet
which would verify (at run time) that bar has the MinimalSet ability, and
then bind foo to the same object as bar. If bar doesn't have the MinimalSet
ability, this would do whatever would have happened if you tried to call the
__and__ function above -- probably raise an exception.
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
