Okay. We now think that we know how objects will be done in BitC. This
subsumes all currently identified use-cases for existential types,
without most of the complexity. It also, curiously, reveals a failure of
generality in our current MAKE-CLOSURE operation.
OBJECTS and METHODS
An object in BitC is simply a structure with some associated methods. We
will at some point add a notion of field hiding, but that is not
essential to the type system or to getting started with objects.
A method is a function having the following properties:
1. It is declared as part of an object declaration.
2. Within the method associated with object type O, the reserved word
"this" designates a structure instance whose type I is some subtype
of O.
- If O is a reference type, then "this" is of type (ref O).
- If O is a value type, then "this" is of type (by-ref O).
3. Methods may optionally be virtual, which means that their
implementation can be overridden during object extension
(subclassing).
4. The language syntactically guarantees that the type relation I<=O
is ensured in all applications of any method O.m. A consequence of
this is that methods and functions are not copy compatible, even
when they have the same signature.
While methods are syntactically associated with their object
declarations, a method does not occupy storage within its object.
Finally, objects differ from structures in regards to storage. There is
a hidden pointer at the "front" of the object representation.
If o is an object instance of type O, and m is a method of O, then
(o.m ... )
is an invocation of that method in which /this/ is bound to /o/.
If m is a declared method of object type O, then
(define (O.m ...) body)
can be used to give the implementation of the method.
Note that given this definition, the current implementation of
(misnamed) MAKE-CLOSURE can be viewed as a composition of MAKE-THUNK and
construction of a procedure object, where a procedure object is truly an
object in the sense described above.
The issue that I have NOT addressed here is the issue of subtyping and
supporting syntax. That clearly needs to be addressed, and we will
address it in a future note.
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
