You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/12/19 18:52:45 UTC
[VOTE] QueueElement Interface
I forsee 4 interfaces for QueueElement:
The QueueElement and Signal interfaces are from the SEDA architecture. Beyond that,
I see a Message interface and a Command interface.
Here are the base interfaces I see:
interface QueueElement {}
interface Signal extends QueueElement {}
interface Message extends QueueElement
{
Object getAttachment();
void attach( Object attachment );
}
interface Command extends Signal, Executable
{
boolean isRepeatable();
long getRepeatInterval();
}
This is all fine and dandy, but I want to get a feel for the getType() that is
currently part of QueueElement. I added that for the purpose of making tests
quicker and easier. However, there is no easy way to directly correlate a
QueueElement type id to the class from which it came. The issue directly correlates
to how QueueElement types from different vendors would work in the same system.
One method would have us act as a repository for vendor to id masks. I am
against that aproach. Another would be to mathematically guarantee that all
QueueElements are different deriving the id from the class or class name.
This is better, but it also raises the question of why have it in the first
place?
Please place the vote here:
VOTE
----
Keep getType() method in QueueElement, or kill it?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] QueueElement Interface
Posted by Berin Loritsch <bl...@apache.org>.
Berin Loritsch wrote:
> Leo Sutic wrote:
>
>>
>>> From: Berin Loritsch [mailto:bloritsch@apache.org]
>>>
>>> VOTE
>>> ----
>>> Keep getType() method in QueueElement, or kill it?
>>>
>>
>> If I could vote, I would vote "kill". With the strong abilities in
>> Java for reflection, there is no need for it. As for other ports to
>> other languages, Java classes will not appear as queue elements, so
>> why bother?
>>
>> Plus, it messes with my beautiful ReflectionEventHandler.
>
>
>
> The idea to incorporate it is to make the ReflectionEventHandler easier
>
> to implement in C++ where RTTI is not binary compatible accross compilers
> and typically resource intensive.
Your wish is my command. I have removed it. The more I look at it,
the less I like it, and the more hackish it seems.
If there is any actual need for it, we can explore readding it.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] QueueElement Interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> The idea to incorporate it is to make the ReflectionEventHandler easier
> to implement in C++ where RTTI is not binary compatible accross compilers
> and typically resource intensive.
For the C++ version I will explore other ways - probably the solution will
be
a "GetType" method. But I see no need to have exactly the same interfaces
across
different languages. Putting queue elements generated in Java in a C++ queue
requires a whole JNI mess, and whatever differences there are between the
Java and C++ version can be solved in there.
The binary incompatibility of RTTI is a problem, though, but there are ways
to
solve that, too, in an elegant way. I hope.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] QueueElement Interface
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
>
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>
>>VOTE
>>----
>>Keep getType() method in QueueElement, or kill it?
>>
>
> If I could vote, I would vote "kill". With the strong abilities in Java
> for reflection, there is no need for it. As for other ports to other
> languages, Java classes will not appear as queue elements, so why bother?
>
> Plus, it messes with my beautiful ReflectionEventHandler.
The idea to incorporate it is to make the ReflectionEventHandler easier
to implement in C++ where RTTI is not binary compatible accross compilers
and typically resource intensive.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] QueueElement Interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> VOTE
> ----
> Keep getType() method in QueueElement, or kill it?
If I could vote, I would vote "kill". With the strong abilities in Java
for reflection, there is no need for it. As for other ports to other
languages, Java classes will not appear as queue elements, so why bother?
Plus, it messes with my beautiful ReflectionEventHandler.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>