Justin Couch schrieb:
> On Thu, 11 Jan 2001, Dipl. Ing. Paul Szawlowski wrote:
>
> > I just encountered a problem which I think should get resolved.
> > I wanted to implement a class which implements the InputDevice interface
> > and inherits from Behavior.
>
> Ummm... without knowing the exact details of what you are are doing, this
> sounds like something that will get very nasty very quickly. What you have
> are two separate threaded entities working together within a single class.
> Something that is a design issue that is marked as 'Don't do@ in any
> mutlihtrreaded classes ever taught. If you need these talking togehter then
> you should do this via a thirdparty class using a standard producer-consumer
> model. This will avoid deadlocks that will occur in your application that
> putting the two threads into the one class will do.
That's what I actually do now - splitting the Behavior and InputDevice. But I
thought because there is a close relationship between the InputDevice (which is
defined as Interface) and the Behavior, which updates the scene according to the
input, I implement the InputDevice in my Behavior class (still couple the
functionality via the Sensor class).
But your argument about multithreading sounds good to me, that 2 seperate classes
is a better solution.
> > For that I need unfortunatly a method initialize with no parameters
> > which shall return void in one case and boolean in the other.
>
> Talk to the langauge designers. That's a Java language issue and not one you
> will get a positive answer for. Having the same method signature but different
> return value types is not a capability of any strongly typed language that
> I am aware of.
>
That was actually my problem that prevented me from implementing the InputDevice
interface with a class which inherits from Behavior. Behavior defines an
initialize method returning void and InputDevice defines an initialize method
returning boolean.
PS: I'm not quite happy with the Sensor class. It provides only support for the
Transform3D class. But I can imagine also to steer e.g. color with an input
device. In this case I have a lot of matrix copying which I don't need in this
case. It would be fine if the Java3D develper team would provide also other
information carried via the Sensor class than Tranform3Ds.
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
