FQN confusion
From Erights
Kevin Reid (Talk | contribs) (→All instances lowercase: adjust Maker's FQN entry, signature) |
|||
| (One intermediate revision not shown) | |||
| Line 1: | Line 1: | ||
(In this message, I use "FQN of an object" to mean | (In this message, I use "FQN of an object" to mean | ||
| - | object.__getAllegedType().getFQName().) | + | object.__getAllegedType().getFQName(). FQN stands for "Fully Qualified Name".) |
E Java mapping | E Java mapping | ||
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)
