You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Jeff Turner <je...@socialchange.net.au> on 2001/08/12 13:06:07 UTC
Type-safe Enum not so type-safe.
A question, mainly for Pete,
Enum and ValuedEnum both have public constructors:
public Enum( final String name );
public Enum( final String name, final Map map );
public ValuedEnum( final String name, final int value );
public ValuedEnum( final String name, final int value, final Map map );
Because they're public, any class can add more Enum items at any time,
so the Enum is not type-safe at all. Possibly a security hazard if
anyone was relying on subclasses' type-safety.
Since the only time they should ever be called is within a subclass,
would it be better to make them protected? This technically breaks
backwards-compatibility, but only where the class is being incorrectly
used.
thanks,
--Jeff
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Type-safe Enum not so type-safe.
Posted by Jeff Turner <je...@socialchange.net.au>.
On Sun, Aug 12, 2001 at 03:17:15PM -0700, Berin Loritsch wrote:
>
> --- Jeff Turner <je...@socialchange.net.au> wrote:
[snip]
> >
> > Still, it's a backwards-incompatible change. Should
> > we create a CVS branch "avalon-5_0" for things like this?
>
> -1.
>
> In cases like this, where the API change is not
> backwards compatible, but necessary due to security
> or other important issues, we change it in CVS,
> promote the version of Framework to 4.1, and we make a
> release.
Sounds good.
> There are two key things to keep in mind:
>
> 1) The reason of the change needs to be WELL documented
> 2) We also look at other things we want to include in
> the release.
>
> I would make the change in CVS, but wait until at least
> September 12 before we make another release. We need
> to plan these things--especially since we made a big
> announcement for the 4.0 release.
Okay, I have
- Updated phoenix, putting Traversal into a separate class as
suggested.
- Changed the Enum constructor signatures from public to protected.
- Explained this change in the javadocs, with reference to the new
examples which illustrate correct use.
- Added an entry in jakarta-avalon changes.xml.
- Made sure the various projects still build.
--Jeff
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Type-safe Enum not so type-safe.
Posted by Peter Donald <do...@apache.org>.
On Sun, 12 Aug 2001 23:14, Jeff Turner wrote:
> >
> > It used to be protected at one stage ... can't seem to recall why it was
> > made public. Is there any code in Avalon that it would break?
>
> Er.. yes, actually.
>
> Two cases in Phoenix:
>
> src/java/org/apache/avalon/framework/camelot/State.java
> src/java/org/apache/avalon/phoenix/components/phases/BlockDAG.java
>
> In both cases, moving the constructor calls from outside to inside is
> pretty easy, and the code looks just as good. I don't think these
> examples represent a new use-case for non-typesafe Enums.
Ahh yes - I remember now. I was a a crusade to remove cruft and I was going
to go back and make Enum/ValuedEnum protected again after I had finished
workin with that,
> Still, it's a backwards-incompatible change. Should we create a CVS
> branch "avalon-5_0" for things like this?
Well it would be *extremely* unlikely to break anything but up to you. You
can deprecate them giving a message saying "going to protected access next
release because of X, Y and Z" if you want. I am +/-0 either way ;)
> Diffs for the avalon and phoenix changes attached.
I would avoid inner classes like the plague if possible - too many shoddy
compilers/IDEs are not spec compliant in that area ;(
Instead I would make Traversal a new top-level class.
>
> --Jeff
>
> > Cheers,
> >
> > Pete
> >
> > *-----------------------------------------------------*
> >
> > | "Faced with the choice between changing one's mind, |
> > | and proving that there is no need to do so - almost |
> > | everyone gets busy on the proof." |
> > | - John Kenneth Galbraith |
> >
> > *-----------------------------------------------------*
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
----------------------------------------
Content-Type: text/plain; charset="us-ascii"; name="Attachment: 1"
Content-Transfer-Encoding: 7bit
Content-Description:
----------------------------------------
----------------------------------------
Content-Type: text/plain; charset="us-ascii"; name="Attachment: 2"
Content-Transfer-Encoding: 7bit
Content-Description:
----------------------------------------
----------------------------------------
Content-Type: text/plain; charset="us-ascii"; name="Attachment: 3"
Content-Transfer-Encoding: 7bit
Content-Description:
----------------------------------------
--
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Type-safe Enum not so type-safe.
Posted by Berin Loritsch <bl...@yahoo.com>.
--- Jeff Turner <je...@socialchange.net.au> wrote:
> > It used to be protected at one stage ... can't
> seem to recall why it was made
> > public. Is there any code in Avalon that it would
> break?
>
> Er.. yes, actually.
>
> Two cases in Phoenix:
>
>
src/java/org/apache/avalon/framework/camelot/State.java
>
src/java/org/apache/avalon/phoenix/components/phases/BlockDAG.java
>
> In both cases, moving the constructor calls from
> outside to inside is
> pretty easy, and the code looks just as good. I
> don't think these
> examples represent a new use-case for non-typesafe
> Enums.
>
> Still, it's a backwards-incompatible change. Should
> we create a CVS
> branch "avalon-5_0" for things like this?
-1.
In cases like this, where the API change is not
backwards compatible, but necessary due to security
or other important issues, we change it in CVS,
promote
the version of Framework to 4.1, and we make a
release.
There are two key things to keep in mind:
1) The reason of the change needs to be WELL
documented
2) We also look at other things we want to include in
the release.
I would make the change in CVS, but wait until at
least
September 12 before we make another release. We need
to plan these things--especially since we made a big
announcement for the 4.0 release.
__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Type-safe Enum not so type-safe.
Posted by Jeff Turner <je...@socialchange.net.au>.
On Sun, Aug 12, 2001 at 09:54:37PM +1000, Peter Donald wrote:
> On Sun, 12 Aug 2001 21:06, Jeff Turner wrote:
> > A question, mainly for Pete,
> >
> > Enum and ValuedEnum both have public constructors:
> >
> > public Enum( final String name );
> > public Enum( final String name, final Map map );
> > public ValuedEnum( final String name, final int value );
> > public ValuedEnum( final String name, final int value, final Map map );
> >
> > Because they're public, any class can add more Enum items at any time,
> > so the Enum is not type-safe at all. Possibly a security hazard if
> > anyone was relying on subclasses' type-safety.
> >
> > Since the only time they should ever be called is within a subclass,
> > would it be better to make them protected? This technically breaks
> > backwards-compatibility, but only where the class is being incorrectly
> > used.
>
> It used to be protected at one stage ... can't seem to recall why it was made
> public. Is there any code in Avalon that it would break?
Er.. yes, actually.
Two cases in Phoenix:
src/java/org/apache/avalon/framework/camelot/State.java
src/java/org/apache/avalon/phoenix/components/phases/BlockDAG.java
In both cases, moving the constructor calls from outside to inside is
pretty easy, and the code looks just as good. I don't think these
examples represent a new use-case for non-typesafe Enums.
Still, it's a backwards-incompatible change. Should we create a CVS
branch "avalon-5_0" for things like this?
Diffs for the avalon and phoenix changes attached.
--Jeff
> Cheers,
>
> Pete
>
> *-----------------------------------------------------*
> | "Faced with the choice between changing one's mind, |
> | and proving that there is no need to do so - almost |
> | everyone gets busy on the proof." |
> | - John Kenneth Galbraith |
> *-----------------------------------------------------*
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Type-safe Enum not so type-safe.
Posted by Peter Donald <do...@apache.org>.
On Sun, 12 Aug 2001 21:06, Jeff Turner wrote:
> A question, mainly for Pete,
>
> Enum and ValuedEnum both have public constructors:
>
> public Enum( final String name );
> public Enum( final String name, final Map map );
> public ValuedEnum( final String name, final int value );
> public ValuedEnum( final String name, final int value, final Map map );
>
> Because they're public, any class can add more Enum items at any time,
> so the Enum is not type-safe at all. Possibly a security hazard if
> anyone was relying on subclasses' type-safety.
>
> Since the only time they should ever be called is within a subclass,
> would it be better to make them protected? This technically breaks
> backwards-compatibility, but only where the class is being incorrectly
> used.
It used to be protected at one stage ... can't seem to recall why it was made
public. Is there any code in Avalon that it would break?
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org