Re: Prettiness of Java statics classes: dropping the "make"
"Mark Miller" <[email protected]>
| Newsgroups | gmane.comp.lang.e.general |
|---|---|
| Message-ID | <[email protected]> |
On Sun, May 11, 2008 at 7:53 AM, Kevin Reid <[email protected]> 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