[e-lang] Prettiness of Java statics classes: dropping the "make"

[Mark Miller]

On Sun, May 11, 2008 at 7:53 AM, Kevin Reid <kpreid at mac.com> wrote:
> On May 11, 2008, at 9:14, David-Sarah Hopwood wrote:
>  > Kevin Reid wrote:
>  >> Java libraries often have classes which are used solely for their
>  >> static fields and methods, not instantiated.
>  >> ...
>
> >> As these are basically classes being used as singleton objects, I
>  >> propose that there be a safej option which makes these classes'
>  >> import fqns more fitting:
>  >>[...]
>  >> What do you think of this idea?

I think this idea is workable. I hadn't previously considered placing
such a switch in the safej file. The important constraint on employing
this switch is that the class be non-instantiatiable, so a safej file
turning on this switch much not also enable any constructors or
instance members. I would also prefer to constrain such classes to be
final.



>  > What happens if the class begins with a lowercase letter?
>
>  Note that uncapitalized class names already introduce such a problem
>  for the guard convention: <import:foo.Bar> should to the E programmer
>  be a guard.
>
>  Currently, <import:foo.Bar> imports the object which exposes the
>  static members ('StaticMaker'); this is deprecated in favor of
>  foo.makeBar, and the plan is to transition to foo.Bar importing the
>  type/guard of the class.
>
>  (MarkM, could you confirm that my claims fit your understanding of
>  the plan as well?)

Yes.


>  We could define <import:foo.bar>, <import:foo.makeBar>, and
>  <import:foo.Bar> to look for either Bar or bar.
>
>  Are there Java libraries that use uncapitalized class names? Do we
>  want to bother supporting them?

Prior to Java 1.5, not that I am aware of. The Java 1.5 annotations,
IIUC, are actually classes, and typically have uncapitalized names.
There may also be a problem with Java 1.5 enums; I'm not sure.

E-on-Java currently depends only on Java 1.3, so we haven't yet had to
worry about all of Java 1.5's new "features". Unfortunately, Joe-E
depends on Java 1.5, and I'd like to see the E-on-Java implementation
eventually migrate mostly onto Joe-E, so these "features" may become
an issue.

-- 
Text by me above is hereby placed in the public domain

 Cheers,
 --MarkM