| > Excellent. Until, of course, we have to implement it. We'll implement
| > it by calling some vtable method on P1, that much is obvious. But which
| > one? Our implementation of the set_p_p op can't know whether or not P1
| > wants a string, an integer, or a number. Or something entirely different.
| > Indeed, P1 might not know what it wants unless it knows what P2 has to
| > offer.
|
....
|
| This is the other way around. In C++ this would be a constructor while
| the morph version would be a cast operation.
....
| We need diffrent operations for diffrent kind of things
| * set or set_pointer
| * set_value or lets call this one set
| * clone (maybe this is just a special form of set_value)
(from the peanut gallery)
Some sort of object "adaption" mechanism would be helpful,
traditionally object oriented programms do this with inheritance
which IMHO, sucks. Following are the relevant excerpts from a
PEP which I proposed for the Python community; it reflects a
great deal of thought as to how a dirt simple and very flexible
type mechanism would work. Below please find the first few
paragraphs; some of the context may be wrong but it should give
you an idea as to where a few of us were headed.
Abstract
This proposal puts forth an extensible mechanism for the
adaptation of an object to a context where a specific type, class,
interface, or other protocol is expected.
This proposal provides a built-in "adapt" function that, for any
object X and protocol Y, can be used to ask the Python environment
for a version of X compliant with Y. Behind the scenes, the
mechanism asks the object X: "Are you now, or do you know how to
wrap yourself to provide, a supporter of protocol Y?". And, if
this request fails, the function then asks the protocol Y: "Does
object X support you, or do you know how to wrap it to obtain such
a supporter?" This duality is important, because protocols can be
developed after objects are, or vice-versa, and this PEP lets
either case be supported non-invasively with regard to the
pre-existing component[s].
This proposal does not limit what a protocol is, what compliance
to the protocol means, nor what a wrapper constitutes. This
mechanism leverages existing protocol categories such as the type
system and class hierarchy and can be expanded to support future
protocol categories such as the pending interface proposal [1] and
signature based type-checking system [2].
Motivation
Currently there is no standardized mechanism in Python for asking
if an object supports a particular protocol. Typically, existence
of particular methods, particularly those that are built-in such
as __getitem__, is used as an indicator of support for a
particular protocol. This technique works for protocols blessed
by the BDFL (Benevolent Dictator for Life), such as the new
enumerator proposal identified by a new built-in __iter__[9].
However, this technique does not admit an infallible way to
identify interfaces lacking a unique, built-in signature method.
More so, there is no standardized way to obtain an adapter for an
object. Typically, with objects passed to a context expecting a
particular protocol, either the object knows about the context and
provides its own wrapper or the context knows about the object and
wraps it appropriately. The difficulty with these approaches is
that such adaptations are one-offs, are not centralized in a
single place of the users code, and are not executed with a common
technique, etc. This lack of standardization increases code
duplication with the same adapter occurring in more than one place
or it encourages classes to be re-written instead of adapted. In
either case, maintainability suffers.
It would be very nice to have a standard function that can be
called upon to verify an object's compliance with a particular
protocol and provide for a wrapper if one is readily available --
all without having to hunt through a library's documentation for
the appropriate incantation.
Requirements
When considering an objects compliance with a protocol, there are
several cases to be examined:
a) When the protocol is a type or class, and the object has
exactly that type or is a member of the class. In this case
compliance is automatic.
b) When the object knows about the protocol and either considers
itself compliant or knows how to wrap itself appropriately.
c) When the protocol knows about the object and either the object
already complies or can be wrapped accordingly.
d) When the protocol is a class, and the object is a member of a
subclass. This is distinct from the first case (a) above,
since inheritance does not necessarily imply substitutability
and must be handled carefully.
e) When the context knows about the object and the protocol and
knows how to adapt the object so that the required protocol is
satisfied. This could use an adapter registry or similar
method.
For this proposal's requirements, the first case should be come
for free and the next three cases should be relatively relatively
easy to accomplish. This proposal does not address the last case,
however it provides a base mechanism upon which such an approach
could be developed. Further, with only minor implementation
changes, this proposal should be able to incorporate a new
interface type or type checking system.
The fourth case above is subtle. A lack of substitutability can
occur when a method restricts an argument's domain or raises an
exception which a base class does not or extends the co-domain to
include return values which the base class may never produce.
While compliance based on class inheritance should be automatic,
this proposal should allow an object to signal that it is not
compliant with a base class protocol.
For more reading... http://python.sourceforge.net/peps/pep-0246.html
Best,
Clark
