FQN confusion

From Erights

(Difference between revisions)
Jump to: navigation, search
(record issue and E-on-CL's current approach)
(All instances lowercase: adjust Maker's FQN entry, signature)
Line 40: Line 40:
     or                makeFoo$foo
     or                makeFoo$foo
  Guard's FQN          ...$Foo        Class
  Guard's FQN          ...$Foo        Class
-
  Maker's FQN          makeFoo        StaticMaker
+
  Maker's FQN          makeFoo        staticMaker
 +
    or                                makeFoo
-
This implies that "interface Foo {}" and Java class names must be automatically decapitalized for their getFQName() responses, though.
+
This implies that "interface Foo {}" and Java class names must be automatically decapitalized in their getFQName() responses, though.
E-on-CL partially implements this.
E-on-CL partially implements this.
 +
 +
--[[User:Kevin Reid|Kevin Reid]] 10:15, 17 March 2008 (CDT)
==Discussion==
==Discussion==

Revision as of 15:15, 17 March 2008

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

Personal tools
more tools