[e-lang] FQN confusion

[Chris Hibbert]

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

We had these kinds of terminology distinction problems moving from 
Smalltalk to C++ and Java.  Each has a different set of labels for a 
different set of distinctions and, for the most part, you just have to 
live with it.

Java has Exceptions that roughly correspond to Guards, but there's no 
naming distinction to distinguish Exceptions from Classes.  Java 
programmers use constructors, factory methods, and factory classes where 
E programmers use Makers, and there aren't any universal terminology or 
naming conventions for those.  FooMaker.make(), Foo.make(), new Foo(), 
etc.  (and these are just the way that I write them, not any standard 
Java convention.  I don't think standard Java programming practice uses 
Factory methods or Factory classes enough to want a convention.)

 > Question: What should be the FQNs of guards defined in E, and how
 > does one write E code to implement this?

I would guess that Guards are a novel enough concept that a convention 
for naming them would be valuable.  Have any of the E programmers 
written enough non-ephemeral Guards to have a consistent practice?  I'd 
guess that NumberGuard, IntegerGuard, NonNegativeGuard, etc. would be 
the useful way to go for Guards that actually get reused.  But when I 
was writing code in E, Guards were optional, and I didn't use many.

Chris
-- 
All sensory cells [in all animals] have in common the presence of
... cilia [with a constant] structure.  It provides a strong
argument for common ancestry.  The common ancestor ... was a
spirochete bacterium.
   --Lynn Margulis (http://edge.org/q2005/q05_7.html#margulis)

Chris Hibbert
hibbert at mydruthers.com
Blog:   http://pancrit.org