-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message
Chris Ebenezer uitte de volgende tekst op 03/19/2006 06:49 PM:
> I have some code like this:
>
[quoted text clipped - 60 lines]
> Can't be compiled - no matter what combination of qualification of the
> exception name that I try.
You either have to give the fully qualified name, or only the last part.
StateMachine.StateChangeException is neither of both. The compiler
will look for a class called StateChangeException, inside StateMachine.
There seems to be no such class.
H.

Signature
Hendrik Maryns
==================
www.lieverleven.be
http://aouw.org
Chris Ebenezer - 20 Mar 2006 11:15 GMT
> > class BarStateMachine extends StateMachine<Bar> {
> > public abstract class BarState extends State {
[quoted text clipped - 23 lines]
> will look for a class called StateChangeException, inside StateMachine.
> There seems to be no such class.
Sorry - that was midway through an experiment to try and get the thing
to compile. [Incidentally StateMachine.StateChangeException works in the
top level class].
I think though that what I've run into is this bug in the 1.5 JDK:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5086027

Signature
chris
> I have some code like this:
>
[quoted text clipped - 18 lines]
> }
> }
Chris,
My guess is that you are over using the idea of inner classes
and generics, maybe confusing the two. This collection of stuff looks
like a great set of stuff for a package.
For example, did you really intend these inner classes all to contain
references to the outer StateMachine? That is the result of not using
static on the class definitions.
Why are State and StateChangeException nested in StateMachine, you
show nothing that uses StateMachine, but I could envision where
it MIGHT be useful. What is the design goal here?
Abstract Generic? That sounds overly general to me?
Why is FooState generic? It implements the abstract method listed?
> unreported exception somepackage.StateMachine.StateChangeException; must
> be caught or declared to be thrown
>
> For the line where 'enter()' is being called in FooState.
But it doesn't say it has never heard of StateChangeException, it just
says it is not properly thrown.
> However, there appears to be no way of then extending a specific non
> generic version of this class and overloading 'State' without having
> this error reappear at other levels.
Overloading is not something you do when subclass State, as in FooState.
What method where you trying to overload?
-Paul
Chris Ebenezer - 25 Mar 2006 15:15 GMT
> My guess is that you are over using the idea of inner classes
> and generics, maybe confusing the two. This collection of stuff looks
> like a great set of stuff for a package.
To an extent it uses the generic class as a containing namespace yes.
The goal was to create a generic state machine that could be used to
create state machines where the type of the object used to shift state
could be varied, and at the same time avoid exposing genericness beyond
declaration of the state machine itself. For simplicity sake it's nicer
to have the StateMachine methods take and return instances of Foo,
rather than State<Foo>.
> For example, did you really intend these inner classes all to contain
> references to the outer StateMachine? That is the result of not using
> static on the class definitions.
Yes, some of the enclosed states access members variables of StateMachine.
> Abstract Generic? That sounds overly general to me?
>
> Why is FooState generic? It implements the abstract method listed?
Yes. The code is elidded and FooState in this case implements some
abstract methods that have an impact on state machine strategy.
> > unreported exception somepackage.StateMachine.StateChangeException; must
> > be caught or declared to be thrown
> > For the line where 'enter()' is being called in FooState.
>
> But it doesn't say it has never heard of StateChangeException, it just
> says it is not properly thrown.
Sure, but there appears to be no way of referring to this exception from
the extending class. As it happens, the exception being declared as an
inner class as a generic class makes the exception itself generic - and
the compile errors gotten are compile order dependent - this is a javac
bug (see previous post).

Signature
chris
P.Hill - 26 Mar 2006 22:47 GMT
> Sure, but there appears to be no way of referring to this exception from
> the extending class.
Then simple, define it outside of the complex generic abstract outer,
particularly since it doesn't become subclassed or is generic, it is the
same class for every use of the complex abstract nested generic state
machine.
> As it happens, the exception being declared as an
> inner class as a generic class makes the exception itself generic - and
> the compile errors gotten are compile order dependent - this is a javac
> bug (see previous post).
Sounds like the solution is: if it hurts don't do it.
-Paul