The DEFCAPSULE proposal is going to run into the same problem that
plagued C: where to emit the V-table?
These days, most linkers have a notion of a "weak" symbol or a
"mergeable" symbol that can address this problem directly.
But one possible way to go -- and one that eliminates the extra
indirection cost to get to the encapsulated data -- is to distinguish
between capsule declarations and capsule type instantiations:
(defcapsule (C 'a ... 'z)
... methods ...)
(definstance (C 'a ... 'z) SomeStructureType)
The purpose of the definstance is (1) to generate a vtable, and (2) to
add
C: (constructor (by-ref SomeStructureType) -> (C 'a ... 'Z)
into the list of constructors that are in scope.
After which you can write:
(C (SomeStructureType ... args ...))
and get back a reference to a heap-allocated thing that looks like:
+-----------------+
| ptr to vtable |
+-----------------+
| expanded |
| instance of |
| structure type |
+-----------------+
My opinion at the moment is that both use-cases are motivated. The
original allows multiple, distinct capsules to reference the same object
(think: thinned interface). The one described above eliminates some
indirection, and may be useful when the goal is simply to hide
information.
But in the end, I don't think that the added complexity of multiple
implementations here is justified. For the moment, I would prefer to
require that capsules must be instantiated over :ref structures, leaving
open the possibility that this might be extended later.
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
