FQN confusion

From Erights

Revision as of 15:13, 17 March 2008 by Kevin Reid (Talk | contribs)
Jump to: navigation, search

(In this message, I use "FQN of an object" to mean object.__getAllegedType().getFQName().)

                      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 <import> 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; <PassByCopy> 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?

Proposals

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

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

E-on-CL partially implements this.

Discussion

Personal tools
more tools