<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-CA" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">Snip<o:p></o:p></span></p>
<div id="mail-editor-reference-message-container">
<div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt"><br>
> <br>
> Interfaces: all interfaces can be implemented by value classes and identity<br>
> classes. Full stop. If you have a particular need to limit the kinds of<br>
> implementing classes, you can use a sealed interface and provide the<br>
> implementation yourself, or you can make it an informal part of the contract.<br>
> But, like access control, synchronization, and other fine-grained,<br>
> implementation-oriented features, identity is not something interfaces can<br>
> explicitly control.<br>
> <br>
> This approach has a two-state categorization scheme for classes expressed with<br>
> one keyword ('value' and identity). This corresponds to one JVM flag<br>
> (ACC_IDENTITY, for {reasons}). Interfaces have only one state.<br>
> <br>
> What do we lose?<br>
> - You can't force an abstract class/interface to be implemented by *only* value<br>
> classes<br>
> - You can't force an interface to be implemented by *only* identity classes<br>
> - You can't declare an abstract class or interface whose type will refuse to<br>
> support the 'synchronized' keyword<br>
> <br>
> I don't think any of these are enough to justify the extra costs of 3 states or<br>
> an 'identity' keyword. (For awhile, I was considering keeping around the<br>
> 'identity' keyword, just for the purpose of interfaces. But, eh, nobody is<br>
> going to use it.)<br>
<br>
Removing the 'identity' keyword is a good things, but i'm not so sure about not allowing users to declare a value interface, because i think that sealing the interface does not convey the right semantics.<br>
<br>
The problem is that in the future, a VM may want to flatten a sealed interface (with all its subtypes being value type), currently this is possible on stack but not on heap because '!' can not be used on anything but a value class.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">I’m not clear on how this would work at the VM level. To flatten on heap we need a single known layout that we can embed in the containing object / array. If we added value interfaces back into the language,
we’d still be unable to know the field layout to embed in the containing object.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">An interface that is sealed to a single value class may be a good candidate for layout heroics (and in some distance future, maybe an interface that is sealed to a small set of layouts could be flattened),
but in both cases, the key determinate is that the interface is sealed to a set of value classes. Whether the interface is marked as value or not is irrelevant.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt"><br>
<br>
I think we should allow an interface to be prefixed by "value" so<br>
- the compiler adds the interface in the Preload attribute<br>
- '!' is allowed on that interface (in that case all subtypes must be either a value interface or a value class with an implicit constructor)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Guidance on when to add a class to the preload attribute is something that still needs to be worked out. A good first approximation is anywhere we had put a “Q” descriptor is a good candidate but there may
be others (like the sealed interface case) that are interesting.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">--Dan<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt"><br>
<br>
regards,<br>
Rémi<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</body>
</html>