[M3devel] alternate implementation of opaque types?

[Dirk Muysers]

If M3 would merge interfaces and modules, like Oberon and golang
have done, with the addition of selective export (hidden, readonly, public)
of record/object fields and  mixins (aka called "interfaces" in Java and C#),
it wouldn't need the extra complications of opaque types at all.


From: Jay K 
Sent: Sunday, April 07, 2013 9:07 PM
To: Rodney M. Bates ; m3devel 
Subject: Re: [M3devel] alternate implementation of opaque types?


My goal is 1) more efficient code 2) ease of compiling w/ good typeinfo.


If the private/opaque parts were always at the end, then compilation of client code that only knows the public/transparent part would be trivially efficient and typeful, not having all the information/type shown, but at least some.


> The language allows private things before or after public, or more complicated combinations,


I didn't realize.


 - Jay



> Date: Sun, 7 Apr 2013 10:48:57 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] alternate implementation of opaque types?
> 
> 
> 
> On 04/06/2013 04:59 PM, Jay K wrote:
> > Is it conceivable/practical/possible/more-efficient to implement opaque types such that the "opaque" part is at the end instead of at the beginning?
> >
> 
> This is neither an implementation nor a language design question, but a programmer's option.
> The language allows private things before or after public, or more complicated combinations,
> e.g., private, public, private. In fact, arbitrary combinations are possible, although how
> to put them together gets tricky and requires a lot of separate compilations.
> 
> Here is a public-private-public example that is, I think, believable:
> 
> INTERFACE Stack
> ; TYPE T <: Public
> ; TYPE Public = OBJECT METHODS
> push ( I : INTEGER )
> ...
> END (* Public *)
> ; END Stack .
> 
> (Module Stack is not shown. It will have a revelation with private fields and overrides for push, etc. )
> 
> Later, somebody else wants to add:
> 
> INTERFACE StackWithStats
> ; IMPORT Stack
> ; TYPE T = Stack . T OBJECT
> PushCt : CARDINAL := 0
> ...
> OVERRIDES
> push := Push
> ...
> END (* T *)
> ; PROCEDURE Push ( s : T ; I : INTEGER )
> ; END StackWithStats .
> 
> MODULE StackWithStats
> ; PROCEDURE Push ( s : T ; I : INTEGER )
> = BEGIN
> INC ( s . PushCt )
> ; Stack . T . push ( s , I )
> END Push
> ...
> ; BEGIN END StackWithStats .
> 
> >
> > We do suffer from the "fragile base type" problem either way, right?
> > Currently when the opaque part changes size, we have to recompile all users of the transparent part, at least to generate new runtime type information that they all contain, right?
> > Granted, that information should probably be single-instanced per type and accessed indirectly via a function call, possibly imported from the .dll/.so implementing the type.
> >
> >
> > With my proposed change, you can recompile less actually. Though we probably wouldn't bother.
> >
> >
> > As to knowing the size and being able to do a create, well, the size might be buried in the type information anyway, or a creating function exposed from where the full revelation is made.
> >
> >
> >
> > - Jay
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130408/3914a798/attachment-0002.html>