FQN confusion - Revision history

Markm at 15:43, 17 March 2008

2008-03-17T15:43:46Z

New page

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

--[[User:Kevin Reid|Kevin Reid]] 10:15, 17 March 2008 (CDT)

==Discussion==

* [http://www.eros-os.org/pipermail/e-lang/2006-May/011263.html "FQN confusion"]
* [http://www.eros-os.org/pipermail/e-lang/2006-December/011723.html "Repost: FQN confusion"]

[[Category:Unresolved design issues]]

Kevin Reid: /* All instances lowercase */ adjust Maker's FQN entry, signature

2008-03-17T15:15:44Z

All instances lowercase: adjust Maker's FQN entry, signature

←Older revision		Revision as of 15:15, 17 March 2008
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==

Kevin Reid: record issue and E-on-CL's current approach

2008-03-17T15:13:52Z

record issue and E-on-CL's current approach

←Older revision		Revision as of 15:13, 17 March 2008
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()~~. FQN stands for "Fully Qualified Name"~~.)	+	object.__getAllegedType().getFQName().)

	E Java mapping		E Java mapping
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 in their getFQName() responses, though.	+	This implies that "interface Foo {}" and Java class names must be automatically decapitalized for 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==