The proposed non-upwards-compatible changes below is already implemented in my non-checked-in draft of the next release, so it'll default to happening unless I'm argued out of it. Feel free to take this as a challenge. ;)
[?] Should we change import:... to return the Maker rather than the Type?
<background>
As discussed before on this list
http://crit.org/~ping/criticons/frames.html a Java class must be considered
by E to consist of two kinds of objects, which we refer to as a Type and a
Maker.
The Type, corresponding to an instance of java.lang.Class, serves two
descriptive purposes, but conveys no substantial authority. The Type 1)
describes (or will describe once we figure out a safe wrapping of CRAPI)
the protocol obeyed by objects that are members of that type. 2) a Type
provides
http://www.erights.org/javadoc/javadoc/org/erights/e/meta/java/lang/ClassSug
ar.html a way to verify (using the Joule verifier technique) that an object
is a member of the type. This is most useful when declaring slots:
define i : integer := x ... i := y
will fail if x or y aren't integers (or trivially coercible to integers)
The Maker is E's admittedly peculiar name for the object embodying the
static methods of the "public class Blah ..." declaration. A BlahMaker is
an object whose instance methods correspond to Blah's constructors and
static methods. Currently, these can convey substantial authority, but
that's a bug.
http://www.communities.com/company/papers/security/eforjava.html explains
the OriginalE design for securing java, the essence of which was to turn
off statically provided authority. An object's authority should be
strictly determined by which references it holds.
We will be restricting the E-to-java binding mechanism so that no substantial authority is provided via "import:", and we may design according to that assumption. "import:" is itself syntactic sugar for using the value of uriGetters["import"]. Since this is an instance, we could define it as providing (indirectly) authorities, such that we wouldn't have to change the E-to-java bindings, but this conflicts with the need to provide "import:" to generally untrusted programs, so that they can be broken up into multiple files.
What do I mean by "substantial"? A BlahMaker typically provides the ability to make new members of the Blah type. The Blah type provides the ability to check whether an object is a member of the Blah type. Without access to the Blah type or BlahMaker, you can make a Foo type and FooMaker that act identically, except that members of the Foo type won't be considered by the Blah type to be members of the Blah type. This ability to make branded objects and to recognize the brand is "insubstantial" (better terminology needed). Substantial rights are the ability to effect or be effected by the world outside oneself. Does this definition capture the issues well?
If neither the Type nor the Maker convey substantial authority, doesn't
that negate the arguments made in
http://crit.org/~ping/criticons/frames.html for separating them? It's
certainly grounds for reexamining the issues. However, the
no-substantial-authority restriction only holds for Types and Makers
obtained directly from "import:", ie, Types and Makers defined as file
scope (in either E or Java). For Types and Makers defined otherwise (in
either E or Java), I believe the argument for separation still applies. If
so, polymorphism simplicity argue that we should separate these roles at
file scope as well.
</background>
So when the two do have a difference in authority, we expect the Maker to be the one with substantial authority, such that it will often be sensible to obtain the Type from the Maker, but not the Maker from the Type. Currently,
import:foo.bar.Baz
imports Type Baz. If you want BazMaker, you have to ask the Type for its Maker:
define BazMaker := import:foo.bar.Baz maker
or
define Baz := import:foo.bar.Baz define BazMaker := Baz maker
I think I did this because I'd gotten too used to programming in statically typed languages, and so thought that you'd want to obtain the Type object far more often than you really do. After all, E does have optional variable-type-declarations:
define myBaz : Baz := BazMaker new(3)
even though it has no *static* type checking. However, in practice neither I nor MarcS hardly ever use the Types objects, but we often use the imported Maker objects. Also, asking the Type for the Maker is the wrong protocol wrt how it generalizes to non-file-scope Types and Makers. OTOH, in the non-file-scope case, it will usually be sensible to be able to ask a Maker for a Type describing the things that it makes.
All these argue to have import: return the Maker rather than the type. To get both, the new idiom is:
define BazMaker := import:foo,bar.Baz define Baz := BazMaker asType
Unfortunately, there's no way to write code compatible both with the current system and with this proposal. There's currently few enough E programs and programmers that we can still make such changes. Hopefully, we will soon lose this option. ;)
Opinions, especially criticisms, of these proposals will be a lot more valuable if they happen before the next release. I'd rather not backtrack out of non-upwards compatible changes. Thanks.
Towards jurisdiction-free commerce, --MarkM