<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><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: rodney_bates@lcwb.coop<br>> To: m3devel@elegosoft.com<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></body>
</html>