Prettiness of Java statics classes: dropping the "make"

[Kevin Reid-2]

Java libraries often have classes which are used solely for their  
static fields and methods, not instantiated.

However, the current E notation for using one is rather bad:

   ? def m := <import:java.lang.makeStrictMath>
   # value: <makeStrictMath>

in that it has a "make" which makes no sense.

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?

--
Kevin Reid                            <http://homepage.mac.com/kpreid/>


_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[David-Sarah Hopwood]

Kevin Reid wrote:

> Java libraries often have classes which are used solely for their  
> static fields and methods, not instantiated.
>
> However, the current E notation for using one is rather bad:
>
>    ? def m := <import:java.lang.makeStrictMath>
>    # value: <makeStrictMath>
>
> in that it has a "make" which makes no sense.
>
> 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?

--
David-Sarah Hopwood
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Kevin Reid-2]

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/>


_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Mark Miller-2]

On Sun, May 11, 2008 at 7:53 AM, Kevin Reid <kpreid@...> 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
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Kevin Reid-2]

On May 11, 2008, at 11:52, Mark Miller wrote:

> On Sun, May 11, 2008 at 7:53 AM, Kevin Reid <kpreid@...> 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 don't see why this is necessary. The worst result is poor naming,  
which we can't defend against anyway, and so shouldn't pretend to.

> I would also prefer to constrain such classes to be final.

It seems to me that a non-final statics-only class corresponds  
roughly to single E objects with delegation:

   def foo { ... }

   def bar extends <import:foo> { ... }

I don't mean to say that there are sensible uses for this, but only  
that the restriction does not seem to be justified.

--
Kevin Reid                            <http://homepage.mac.com/kpreid/>


_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Mark Miller-2]

On Sun, May 11, 2008 at 9:56 AM, Kevin Reid <kpreid@...> wrote:
> On May 11, 2008, at 11:52, Mark Miller wrote:
>  > 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 don't see why this is necessary. The worst result is poor naming,
>  which we can't defend against anyway, and so shouldn't pretend to.

Since safej files are within our TCB, defense per se isn't relevant.
Avoid poor naming and other forms of tempting accident is.

>  > I would also prefer to constrain such classes to be final.
>
>  It seems to me that a non-final statics-only class corresponds
>  roughly to single E objects with delegation:
>
>    def foo { ... }
>
>    def bar extends <import:foo> { ... }
>
>  I don't mean to say that there are sensible uses for this, but only
>  that the restriction does not seem to be justified.

Makes sense.


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

 Cheers,
 --MarkM
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

[Raoul Duke]

hi,

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

I believe the unenforced standard is upper-case for annotations e.g.
@Deprecated, @Override, at least for the core Java ones. There are
tutorials out there which use lower-case, but I think in error. The
similar javadoc notes are lower case e.g. @deprecated which is
sometimes confusing.

sincerely.
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang