<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>I agree COM/Java/C# interfaces are very good for structuring large systems, maintaining opacity, and are reasonably simple and efficient.</div><div><br></div><div><br></div><div>They preclude direct access to public data, for better and worse.</div><div><br></div><div><br></div><div>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.)</div><div><br><br>I don't know what Oberon/golang do here.</div><div><br></div><div><br></div><div> - Jay</div><div><br>On Apr 8, 2013, at 3:37 AM, Dirk Muysers <<a href="mailto:dmuysers@hotmail.com">dmuysers@hotmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div>
<meta content="text/html;charset=iso-8859-1" http-equiv="Content-Type">
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style>
<meta name="GENERATOR" content="MSHTML 8.00.6001.19403">
<div><font face="Arial">If M3 would merge interfaces and modules, like Oberon and
golang</font></div>
<div><font face="Arial">have done, with the addition of selective
export (hidden, readonly, public)</font></div>
<div><font face="Arial">of record/object fields and </font><font face="Arial">mixins </font><font face="Arial">(aka called "interfaces" in Java and
C#),</font></div>
<div><font face="Arial">it wouldn't need the extra complications of opaque types
at all.</font></div>
<div style="FONT: 10pt Tahoma">
<div><br></div>
<div style="BACKGROUND: #f5f5f5">
<div style="font-color: black"><b>From:</b> <a title="jay.krell@cornell.edu" href="mailto:jay.krell@cornell.edu">Jay K</a> </div>
<div><b>Sent:</b> Sunday, April 07, 2013 9:07 PM</div>
<div><b>To:</b> <a title="rodney_bates@lcwb.coop" href="mailto:rodney_bates@lcwb.coop">Rodney M. Bates</a> ; <a title="mailto:m3devel@elegosoft.com
CTRL + Click to follow link" href="mailto:m3devel@elegosoft.com">m3devel</a> </div>
<div><b>Subject:</b> Re: [M3devel] alternate implementation of opaque
types?</div></div></div>
<div><br></div>
<div dir="ltr">My goal is 1) more efficient code 2) ease of compiling w/ good
typeinfo.<br><br><br>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.<br><br><br>> The language allows private things before or
after public, or more complicated combinations,<br><br><br>I didn't
realize.<br><br><br> - Jay<br><br><br>
<div>
<div id="SkyDrivePlaceholder"></div>> Date: Sun, 7 Apr 2013 10:48:57
-0500<br>> From: <a href="mailto:rodney_bates@lcwb.coop">rodney_bates@lcwb.coop</a><br>> To:
<a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>> Subject: Re: [M3devel] alternate implementation of
opaque types?<br>> <br>> <br>> <br>> On 04/06/2013 04:59 PM, Jay K
wrote:<br>> > 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?<br>> ><br>> <br>> This is neither an implementation
nor a language design question, but a programmer's option.<br>> The language
allows private things before or after public, or more complicated
combinations,<br>> e.g., private, public, private. In fact, arbitrary
combinations are possible, although how<br>> to put them together gets tricky
and requires a lot of separate compilations.<br>> <br>> Here is a
public-private-public example that is, I think, believable:<br>> <br>>
INTERFACE Stack<br>> ; TYPE T <: Public<br>> ; TYPE Public = OBJECT
METHODS<br>> push ( I : INTEGER )<br>> ...<br>> END (* Public
*)<br>> ; END Stack .<br>> <br>> (Module Stack is not shown. It will
have a revelation with private fields and overrides for push, etc. )<br>>
<br>> Later, somebody else wants to add:<br>> <br>> INTERFACE
StackWithStats<br>> ; IMPORT Stack<br>> ; TYPE T = Stack . T
OBJECT<br>> PushCt : CARDINAL := 0<br>> ...<br>> OVERRIDES<br>> push
:= Push<br>> ...<br>> END (* T *)<br>> ; PROCEDURE Push ( s : T ; I :
INTEGER )<br>> ; END StackWithStats .<br>> <br>> MODULE
StackWithStats<br>> ; PROCEDURE Push ( s : T ; I : INTEGER )<br>> =
BEGIN<br>> INC ( s . PushCt )<br>> ; Stack . T . push ( s , I )<br>>
END Push<br>> ...<br>> ; BEGIN END StackWithStats .<br>> <br>>
><br>> > We do suffer from the "fragile base type" problem either way,
right?<br>> > 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?<br>> > 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.<br>> ><br>> ><br>> > With my proposed change, you can
recompile less actually. Though we probably wouldn't bother.<br>>
><br>> ><br>> > 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.<br>>
><br>> ><br>> ><br>> > - Jay<br>>
<br></div></div>
</div></blockquote></body></html>