Leo Sutic wrote:
Ok, now with the actual problem at hand. The typesafe interface
would be handy, but I have to wonder *how* to practically use it.
The issue is that I want the same feel for both C++
as well as Java if that is how you are working with it.
I want to stay away from strings being the signal type, and if
possible, the class type
being the signal type.
if (a instanceof A) <--------> if (dynamic_cast<A> (a) != NULL)
Java C++
There are ways to solve this, with a switch/case construct. But I
want to get rid of the construct.
:/
Ideally, one would introduce a layer in front of the Sink, and one after
the Source, and by magic be able to write code like this:
class MyStage extends AbstractStageWrapper {
public void handleConnectionOpen (ConnectionOpenEvent event) {
...
}
public void handleConnectionClosed (ConnectionClosedEvent event) {
...
}
}
I see. In Java, this is pretty expensive. I can see how it would be
helpful, but you now would have to approach it like Swing does. There
are specific events a Swing Handler of a certain type can handle. An
extension of an EventHandler would be able to farm out those types of
events and encapsulate the switch/case logic in that EventHandler.
That would be the way to minimize the cost of creating a Method object,
and invoking it--done several hundred times a second, and now you are
thrashing your Garbage Collection.
In many cases, the switch/case would not only be sufficient, but preferred.
In other cases, the separate EventHandler that calls methods on the
Stage object would be better. For example:
class MyStage implements Stage, ConnectionHandler {
public void handleConnectionOpen( Connection conn ) { ... }
public void handleConnectionClosed( Connection conn ) { ... }
public void handleEvent( QueueElement event ) { ... }
}
class ConnectionDistributionHandler
{
private final ConnectionHandler m_target;
public ConnectionDistributionHandler( ConnectionHandler target )
{
m_target = target;
}
public void handleEvents( QueueElement[] events )
{
int len = events.length;
for (int i = 0; i < len; i++)
{
switch ( events[i].getType() )
{
case CONNECTION_OPEN:
m_target.handleConnectionOpen( (Connection)
events[i].getAttachment() );
break;
case CONNECTION_CLOSED:
m_target.handleConnectionClosed( (Connection)
events[i].getAttachment() );
break;
default:
m_target.handleEvent( events[i] );
}
}
}
}
Using reflection is pretty expensive for this type of thing.
Which, as I think about reflection, one actually can. Does anyone
know the performance penalty for dynamic invocation of methods,
as related to the expected time to run a typical SEDA event handler?
I just want to get rid of that cursed switch/nested if!
You would have to abstract it out to specific subsystems....
In C++ I think I could do it with some macros.
Summary: As far as the Queue interfaces go, go for it. I don't
think you can get them any better without trying to use them.
They have no apparent faults.
Just trying to wrap my head around the SEDA stuff and how to best
express the architecture in Java/C++. I want as direct a mapping
between the language and the concepts as possible, and I do not
think the current implementation of SEDA is that.
I think now is time to actually create the implementations of the
interfaces.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
