[M3devel] alternate implementation of opaque types?

[Jay]

I agree COM/Java/C# interfaces are very good for structuring large systems, maintaining opacity, and are reasonably simple and efficient.


They preclude direct access to public data, for better and worse.


They are achievable in Modula-3, like in C, tediously and you invent your own idiom (a separate object, with back pointer to the "real" one, and small functions to forward to it.)


I don't know what Oberon/golang do here.


 - Jay

On Apr 8, 2013, at 3:37 AM, Dirk Muysers <dmuysers at hotmail.com> wrote:

> 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/af1d20cd/attachment-0002.html>