[M3devel] An awkward interaction of language properties

[Rodney M. Bates]

At first I thought this was the answer, but. alas, on closer look no.
If I make Relatives opaque, I would need to reveal it as DTContainer.T.
But a revelation must be a type constructor, not just a type name.
I would have to have two different types, Container.T and the type of
Relatives, each opaque, both revealed as the same type.  You can't do
that, because every opaque type declaration creates a unique type and
requires a unique type expression as its revelation. (It has to be
BRANDED too.)

I could break the cycle differently by making DataStruct2.Node
opaque.  Container has no need to know about the field Relatives,
so that could be in a revelation of Node, not imported by Container.
But that would require that Node be a reference type, and
I really want not to have to make values of Node be separately
heap-allocated.

On 02/17/2012 11:37 PM, Mika Nystrom wrote:
> Yes I should think if you declare the Container type in one interface,
> to be<: ROOT you can then refer to that from the other interfaces.
> Then you REVEAL the actual details in another interface that's not
> imported by the others but only where it is needed.  Both the interfaces
> you have can be generic.
>
>      Mika
>
>
> Henning Thielemann writes:
>>
>> On Fri, 17 Feb 2012, Rodney M. Bates wrote:
>>
>>> The only way I can think of is to make the Relatives field be a REFANY,
>>> and not import DTContainer into DataStruct2.  This loses static safety,
>>> but at least it will be replaced by dynamic safety, at the cost of
>>> runtime narrow checks every time I use Relatives.
>>
>> Some REVEAL tricks instead of REFANY?
>