[M3devel] alternate implementation of opaque types?

[Jay K]

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/20130407/1a8951d1/attachment-0002.html>