FQN confusion

From Erights

Latest revision as of 15:43, 17 March 2008

(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 <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
   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"