[capidl] scopes
Jonathan S. Shapiro
shap@eros-os.org
Tue, 18 Sep 2001 11:43:49 -0400
This is a multi-part message in MIME format.
------=_NextPart_000_0113_01C14037.2F03C640
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
The current CapIDL grammar provides for three scopes in which symbols =
can be defined
top level
module
interface
It also lacks an "import" mechanism.
Because many of the target languages do not support scoping mechanisms =
comparable to namespaces, I'm inclined for the moment to simplify this =
-- even at the risk of reducing expressive power (at least temporarily)
Tentatively, I am inclined to think that we are descibing capabilities =
(interfaces), and that any module relationship between these =
capabilities is an accident of implementation. In principle, some other =
module or program might implement the same interface, and it's type =
would not change by virtue of now appearing in a second module.
Given this, I'm sorely tempted to remove everything *except* interface. =
However, for better or worse there are capability "families" that =
motivate a module-level collection mechanism -- not for use as a scope, =
but for use as a collection point for service-granularity (as opposed to =
capability granularity) documentation.
I have not considered *any* of this carefully. Can anyone give =
well-motivated arguments for (or against) each of these container =
layers, and argue for/against making them scopes? Does nested scoping =
even make sense in CapIDL? What does it mean to export an interface on a =
nested class outside of a VM, for example?
Jonathan
------=_NextPart_000_0113_01C14037.2F03C640
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>The current CapIDL grammar provides for =
three=20
scopes in which symbols can be defined</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2> top =
level</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> module</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> =
interface</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>It also lacks an "import" =
mechanism.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Because many of the target languages do =
not support=20
scoping mechanisms comparable to namespaces, I'm inclined for the moment =
to=20
simplify this -- even at the risk of reducing expressive power (at least =
temporarily)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Tentatively, I am inclined to think =
that we are=20
descibing capabilities (interfaces), and that any module relationship =
between=20
these capabilities is an accident of implementation. In principle, some =
other=20
module or program might implement the same interface, and it's type =
would not=20
change by virtue of now appearing in a second module.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Given this, I'm sorely tempted to =
remove everything=20
*except* interface. However, for better or worse there are capability =
"families"=20
that motivate a module-level collection mechanism -- not for use as a =
scope, but=20
for use as a collection point for service-granularity (as opposed to =
capability=20
granularity) documentation.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I have not considered *any* of this =
carefully. Can=20
anyone give well-motivated arguments for (or against) each of these =
container=20
layers, and argue for/against making them scopes? Does nested scoping =
even make=20
sense in CapIDL? What does it mean to export an interface on a nested =
class=20
outside of a VM, for example?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Jonathan</FONT></DIV></BODY></HTML>
------=_NextPart_000_0113_01C14037.2F03C640--