[
https://issues.apache.org/jira/browse/ECS-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609824#action_12609824
]
Mauro Manfrin commented on ECS-1:
---------------------------------
I tried an approach like that described by you (checking for existence),
before.
The issue is efficiency. That way is slower because it has to check for
existence every 'add' operation. Then, if the objects already exists, it has to
generate e second key (how?).
So I tried another approach: generating a key on every add operation, using a
counter. That is possible, but my final solution is much more efficient: it
doesn't make use of counters and it construct Hashtables only if really useful
(in a normal construction of a page you'll rarely want to give a key to a tag).
So my approach is quicker and uses less memory (useful on crowded web servers).
I can't understand when you say that "it's no longer possible to enumerate via
keys".
ConcreteElement doesn't have methods to Enumerate via keys! (an why enumerating
via a key beeing the hasCode of elements?)
The only enumerate method in ConcreteElement (elements()) is on the full list
on all childs! And that works good.
So I can't see binary compatibility issues. I'll try to convince you.
The only break in binary compatibility could be that:
if you add an Element to the registry using a key, it is expected that you
access that element via the key or the element itself, but if you add the
element without giving it a key, it is expected that you access that element
via the element itself (not via his hascode).
In substance, only code like:
concrete.addElementToRegistry(element);
concrete.removeElementFromRegistry(element.hashCode())
no longer works...but I think that this is a bad code.
It is based on the never stated assumption that ConcreteElement implementation
is based on hascodes!!!
Let me know...
Mauro
> addElement(Element element) methods can fail
> --------------------------------------------
>
> Key: ECS-1
> URL: https://issues.apache.org/jira/browse/ECS-1
> Project: ECS
> Issue Type: Bug
> Environment: in Ibm Virtual Machines, but probabily also in Sun
> Virtual Machines
> Reporter: Mauro Manfrin
> Assignee: Robert Burrell Donkin
> Priority: Critical
> Attachments: ecs-maintrunk-patches.zip
>
>
> The class ConcreteElement exposes a method
> addElement(Element element)
> that calls
> addElementToRegistry(Integer.toString(element.hashCode()),element);
> so it gives a key valued element.hashCode() to that element.
> That's the point: element.hashCode() can't be a unique key because sometimes
> we can have two elements with the same hasocode.
> javadoc states:
> "It is not required that if two objects are unequal according to the
> equals(java.lang.Object) method, then calling the hashCode method on each of
> the two objects must produce distinct integer results. However, the
> programmer should be aware that producing distinct integer results for
> unequal objects may improve the performance of hashtables."
> So sometimes, two different objects can have the same hashCode!
> So, sometimes two calls to addElement(element) can result in only the second
> object stored in the ConcreteElement.
> So sometimes, on out instalaltion some table rows misses, or some row cells
> misses or...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
