On 24 March 2010 21:42, Jonathan S. Shapiro <[email protected]> wrote: > On Wed, Mar 24, 2010 at 12:26 PM, Michal Suchanek <[email protected]> wrote:
> >> You should be able to define the CTS types as structs and their >> ancestry as compatible types. The issue is again in the case you want >> to pass a parameter into CTS and it has to be a structure with a >> particular layout rather than an abstract type. > > Unfortunately this is inadequate. For example, there are circumstances > where you are returned a subclass instance and must pass it back > re-typed as its superclass. What does it mean in terms of code to make it the superclass? Surely the pointed to physical structure in memory does not change, so I would expect that the type only affects which lookup table is used (explicit or implicit) to access the structure which is not unlike what the abstract types do for us. The problem here is that you *also* need the exact physical layout to be compatible with CTS/C++/... This problem is also what you face in systems programming when physical layout of some structures is hardware dependent. > > I do agree that you can't succeed by getting 85% of the way there. You > either support the type system or you deal with it as a foreign > interface. > >> > This is certainly an issue in the usual way of implementing single >> > inheritance. >> >> Then don't do inheritance. Add the ability to merge the constraints >> constraint set C = constraint set A + constraint set B + additional >> constraint 1..n - there is no problem here, if a method is required >> multiple times it is just required. > > This doesn't address the problem of virtual methods. It does so long as you don't try to interpret them inside this system. They are part of the layout, not the interface. Picking the right one would be then an issue of translating between foreign types and native types, which you say you don't want to do for CTS interoperability. The only path then seems to be embracing the CTS object model fully. Thanks Michal _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
