On May 22, 2005, at 15:14, Mark Miller wrote:
> The EverReporter example also reveals something Java
got right, that Joe-E can correctly inherit, but that
the current E module system gets wrong. Currently, if
we place the above Foo definition in a Foo.emaker file,
... each importing evaluates 'interface Foo {}' fresh,
thereby giving each a separate identity. ...
>
> ... I propose that the Java-loading behavior is the
correct one, and that E should adopt it. If A and B
share access only to the same loader, from this loader
they should be able to obtain shared access only to
DeepFrozen objects, which does not thereby give them an
ability to speak to each other. However, these shared
objects may be Selfish, and may contain DeepFrozen
Selfish objects, like Sealer/Unsealer pairs or
Auditor/Guard pairs, so that if A and B come to be able
to speak to each other by other means, they can use
these common type-like identities to coordinate.
Kevin writes
E-on-CL implements this. The import__uriGetter will
cache the value of any emaker iff that value is
DeepFrozen, and DeepFrozen auditing of E objects is
available.
This is used to implement the FlexList and ConstSet
guards, and as an optimization.
Somewhat related: I plan to eventually have it cache
the *source* of any emaker whose value is *not*
DeepFrozen. This will prevent changes in the filesystem
from affecting the apparent state of import__uriGetter
(which claims to be DeepFrozen).
