[e-lang] Prettiness of Java statics classes: dropping the "make"
Kevin Reid
kpreid at mac.com
Sun May 11 09:53:21 CDT 2008
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:
>>
>> ? def m := <import:java.lang.strictMath>
>> # value: <strictMath>
>>
>> ? <import:java.lang.makeStrictMath>
>> # value: <strictMath>
>>
>> (Note that the import fqn is not "java.lang.StrictMath", as that
>> should be a guard.)
>>
>> What do you think of this idea?
>
> 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?)
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?
--
Kevin Reid <http://homepage.mac.com/kpreid/>
More information about the e-lang
mailing list