Re: [Vtd-xml-users] Random Access Proposal (take 2)

[Rodrigo C. <rn...@gm...>]

Jimmy,

getNavigator would be used in some of my code to avoid passing yet 
another parameter to methods, I just don't use it right now because my 
bookmark class does not keep the navigator reference. If it did I would 
use it right away.

Also the method is so simple no one would be confused. Why hide this 
rather obvious feature?

This works just like the Pattern class in Java: you create it using a 
string, and later if you really want to get the string back you also 
can, since it's probably there in the class anyway.  Only that is 
useless, and this feature is useful.

getNavigator: returns the navigator to witch the bookmark is bound, 
otherwise returns null.

I can test the implementation, sure. Just give me a few days :-)

Also, I'll include the rather trivial getNavigator in the test, ok?

Jimmy Zhang wrote:
> Yes, BookMark will go into the next release as an experimental
> feature ... with more user feedback/discussion, we can officially
> introduce it later
>
> regarding getNavigator().. if  non-critical, I prefer to keep it
> out for now... if we keep it in, then later decide to drop it,
> it will break people's code... so it is easier to add a method than
> taking it out... plus one less method makes the documentation shorter
> and a bit less confusing ...
>
> regarding equals() and hashCode(), the methods are there, we
> can alway change the implementation...
>
> In the meantime, could you give the implementation a bit testing?
>
>
> ----- Original Message ----- From: "Rodrigo Cunha" <rn...@gm...>
> To: "Jimmy Zhang" <cra...@co...>
> Cc: "Mark Swanson" <ma...@Sc...>; 
> <vtd...@li...>
> Sent: Wednesday, March 28, 2007 3:16 AM
> Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)
>
>
>> Hi!
>>
>> The getNavigator() method might spare some parameter passing, since 
>> if I'm gona pass a bookmark around to another object I'll need to 
>> pass the navigator also, somehow. It's not critical, but since it can 
>> be done trivially, why not? Also, being able to ask the bookmark "hey 
>> you, to witch navigator do you belong?" seems the phylosophically 
>> correct thing to do.
>>
>> equals() and hashCode() are religious issues, just keep them your way 
>> :-)
>>
>> A hashCode function should ideally spread the input amongst all the 
>> hashcodes space, since collections using hashcodes might, or might 
>> not, use all bits in the hashcode. But just don't bother with that.
>>
>> Jimmy Zhang wrote:
>>> Rodrigo, I just checked in a quick update into CVS
>>>
>>> Regarding some of prior comments, my questions are
>>>
>>> 1. When would a user call getNavigator() any way? I kinda had
>>> a tough time coming up the scenario...
>>>
>>> 2. Regarding equals(), I think that the current bookMark implementation
>>> should be fine in that the only time two bookMark instances are equal
>>> is when they contains node position of the same VTDNav instance, and
>>> the node indices are equal...
>>>
>>> 3.  I am still not sure about hashCode, what is the purpose of the 
>>> spread?
>>> For the current implementation, there will never be colision for the 
>>> bookmarks
>>> corresponding to the same document (the node index is ideal)...
>>>
>>> Let me know your thoughts..
>>> Regards,
>>> jimmy
>>>
>>
>>
>
>
>