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]>
