Re: cvs commit: xml-fop/src/java/org/apache/fop/traits LayoutProps.java SpaceVal.java

["J.Pietschmann" <j3...@yahoo.de>]

gmazza@apache.org wrote:
> gmazza      2004/11/24 13:07:31
>   2.) Appended EN_ to enumeration constants to make them better S&R'able throughout app.

Yuk. Having a large number of identifiers in the same scope with
an identical prefix isn't very good for autocompletion both in
Emacs and Eclipse. I also don't quite get the point about the
better S&R'ability.

J.Pietschmann

Re: cvs commit: xml-fop/src/java/org/apache/fop/traits LayoutProps.java SpaceVal.java

[Glen Mazza <gr...@yahoo.com>]

--- Finn Bock <bc...@worldonline.dk> wrote:
> 
> > We've been doing the same with PR_ (properties)
> and
> > FO_ (FO's) for quite some time.  
> 
> To avoid a name conflict somewhere.
> 

Yes, I was wondering why you didn't originally do that
for the enumeration constants as well.  I like their
self-documenting value in particular though.

> How about having 3 interfaces: 'Properties',
> 'Elements' and 'Enums' 
> which contains the constants without any prefix. And
> then decide that 
> these interfaces are never implemented, but the
> constants are always 
> accessed using the interface name:
>      Enums.TRUE
> 
> That would keep the searchability and perhaps even
> help us when (if) we 
> move to typesafe enums.
> 

-0.  I prefer the simplicity of the current method,
and like the way the code looks as-is.  But I can
easily see how others may view this solution as more
professional.

Glen

Re: cvs commit: xml-fop/src/java/org/apache/fop/traits LayoutProps.java SpaceVal.java

[Finn Bock <bc...@worldonline.dk>]

[Glen]

>>>  2.) Appended EN_ to enumeration constants to

[J.Pietschmann]

>>Yuk. Having a large number of identifiers in the
>>same scope with
>>an identical prefix isn't very good for
>>autocompletion both in
>>Emacs and Eclipse. 

[Glen]

> We've been doing the same with PR_ (properties) and
> FO_ (FO's) for quite some time.  

To avoid a name conflict somewhere.

> After hitting the
> EN_, you're at the same place you would be without the
> prefix.  Furthermore, you can now hunt away for your
> enumeration constants without them being intermixed
> with the PR_'s and FO_'s.
> 
> It was also a commenting issue:  TRUE and FALSE, for
> example, without a prefix, just weren't self
> documenting enough to emphasize that we're working
> with enumeration constants here.  (Remember, we
> removed the old interfaces--per your desire as well as
> mine--such as WritingMode.LR_TB or whatever that
> previously provided that emphasis.)

How about having 3 interfaces: 'Properties', 'Elements' and 'Enums' 
which contains the constants without any prefix. And then decide that 
these interfaces are never implemented, but the constants are always 
accessed using the interface name:
     Enums.TRUE

That would keep the searchability and perhaps even help us when (if) we 
move to typesafe enums.

regards,
finn

Re: cvs commit: xml-fop/src/java/org/apache/fop/traits LayoutProps.java SpaceVal.java

[Glen Mazza <gr...@yahoo.com>]

--- "J.Pietschmann" <j3...@yahoo.de> wrote:

> gmazza@apache.org wrote:
> > gmazza      2004/11/24 13:07:31
> >   2.) Appended EN_ to enumeration constants to
> make them better S&R'able throughout app.
> 
> Yuk. Having a large number of identifiers in the
> same scope with
> an identical prefix isn't very good for
> autocompletion both in
> Emacs and Eclipse. 

We've been doing the same with PR_ (properties) and
FO_ (FO's) for quite some time.  After hitting the
EN_, you're at the same place you would be without the
prefix.  Furthermore, you can now hunt away for your
enumeration constants without them being intermixed
with the PR_'s and FO_'s.

It was also a commenting issue:  TRUE and FALSE, for
example, without a prefix, just weren't self
documenting enough to emphasize that we're working
with enumeration constants here.  (Remember, we
removed the old interfaces--per your desire as well as
mine--such as WritingMode.LR_TB or whatever that
previously provided that emphasis.)


> I also don't quite get the point
> about the
> better S&R'ability.
> 

Because it gives us a very convenient handle ("EN_")
to identify all the places where enumeration constants
are currently being used.  So if we wanted to switch
from "EN_", to "ENUM_", it would just be a quick S&R. 
Sans handle, that would be a very cumbersome
file-by-file manual process--which I just did
yesterday, in order to get the EN_'s in place to begin
with.

Glen