<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<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"></HEAD>
<BODY style="PADDING-LEFT: 10px; PADDING-RIGHT: 10px; PADDING-TOP: 15px"
id=MailContainerBody class=hmmessage leftMargin=0 topMargin=0
CanvasTabStop="true" name="Compose message area">
<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: 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>