FQN confusion

(In this message, I use "FQN of an object" to mean object.__getAllegedType.getFQName. FQN stands for "Fully Qualified Name".)

E              Java mapping Object variable     foo             foo Guard variable      Foo             Foo Maker variable      makeFoo         makeFoo Object's FQN        makeFoo$foo     Foo Guard .getFQName  Foo             Foo or                makeFoo$foo Guard's FQN         ...$Foo         Class Maker's FQN         makeFoo         StaticMaker Problem: In E conventions, "Foo" is the FQN and name of a guard, but in Java mapping "Foo" is the FQN of an instance.

Problem: In E conventions the FQN of an interface-ish guard (def PassByCopy { ... }) is the same as the FQN (in Java style) of what it describes, which seems wrong;  is not itself (necessarily) PassByCopy.

Question: What should be the FQNs of native objects in E-on-CL? That is, what does 1.__getAllegedType.getFQName return?

Question: What should be the FQNs of guards defined in E, and how does one write E code to implement this?

All instances lowercase
An uncapitalized FQN is always used for instances and interface names. That is, the table of examples becomes:

E              Java mapping Object variable     foo             foo Guard variable      Foo             Foo Maker variable      makeFoo         makeFoo Object's FQN        makeFoo$foo     foo Guard .getFQName  foo             foo or                makeFoo$foo Guard's FQN         ...$Foo         Class Maker's FQN         makeFoo         staticMaker or                               makeFoo

This implies that "interface Foo {}" and Java class names must be automatically decapitalized in their getFQName responses, though.

E-on-CL partially implements this.

--Kevin Reid 10:15, 17 March 2008 (CDT)

Discussion

 * "FQN confusion"
 * "Repost: FQN confusion"