Hello Ken,
>>>
>>> Context... What would be the
>>>> BEST to describe an attribute in a collection, in the context of
>>>> grizzly's Context, SelectorHandler, Controller? does it really a
>>>> String type? Actually, the way Grizzly using the *term* attribute
>>>> is not even appropriate. Why? attribute is something that
>>>> describes a specific distinguishable feature of the particular
>>>> object (or instance). The way grizzly uses here is, to store SOME
>>>> objects and their references, in case it needs at various scopes.
>>>> This forces users to "create" their own strings?keys (to
>>>> accommodate in) to retrieve the references.
>>>
>>> Right. Might not be perfect, but a lot of API use that approach:
>>>
>>> http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/SSLSession.html
>>> http://java.sun.com/javaee/5/docs/api/javax/servlet/ServletContext.html
> And all of them suffer a string hash lookup on every attribute
> access. That is a String hash computation
> and comparison, and these are expensive operations to perform
> (possibly multiple times) every time we
> read bytes from a channel.
Hashcode computation happens just once for String, though comparison
could be expensive.
> The design tradeoff here is that there should only be a small number
> of unique attributes in the system, so that the
> AttributedObject arraylists are not too large (say 10-30 attributes,
> not hundreds). Many other designs are possible,
> depending on exactly how a Map<Integer,Object> is implemented, with
> the assumption that the keys are small contiguously
> allocated non-negative integers. For example, segmented maps could be
> used, but then the lookup cost is higher.
> Saving space costs time in this case.
I like your implementation! Agree, we can have several
"AttributeObjectBase"-like implementation, one you have in Corba with
ArrayLists, another with Maps for situation, where we can have more
attributes.
Not sure we need to store type in Attribute? Which role does it play?
But in common I like idea very much!
Thanks.
WBR,
Alexey.
>
> Ken.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net For
> additional commands, e-mail: dev-help_at_grizzly.dev.java.net