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

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

Hum, thanks for the hint also Mark. I normally use java.util 
collections,  but i'll give fastutils a look, since they might be better 
for some of my problems.

Jimmy, a context can be imported/exported as an array of integers, this 
being a bit raw perhaps... and leaving the programmer with the job of 
storing that array. I just created SimpleContext as a way of abstracting 
that implementation detail, but since you like performance, perhaps you 
could leave that raw. I still prefer the abstracted version... besides, 
the internal representation might change and the abstracted version 
would still work.

So, yes, go ahead with my API even if you decide to change it later.

Just as a little silly footnote I found my API is also useful in cases 
where you have:

push();
// do something
pop();
push();
// do something
pop();
push();
// do something
pop();
push();
// do something
pop();

Can be abreviated to:

setCtxFromNav(ctx);
// do something
setNavFromCtx(ctx);
// do something
setNavFromCtx(ctx);
// do something
setNavFromCtx(ctx);
// do something
setNavFromCtx(ctx);

This is both faster and more readable.

It's also useful for things like:

xpto = getComplexToFindTransmissionPath(VTDNav n, String s); // might 
even use caching!
push();
nav.setNavFromCtx(xpto);
// Do something
pop();

and also for exception handling:

{
setCtxFromNav(xpto);
// do something complex and error-prone,
// so I won't use the stack, but a few locally declared contexts instead
// oops! crash! go to handler!
finally {
    setNavFromCtx(xpto)
    // we are now clean
}

So, it made using VTD much more enjoyable to me, even in rather trivial 
situations.

Mark Swanson wrote:
> Jimmy Zhang wrote:
>>
>>> Just a FYI: I have cases where the key is an Integer, and cases where
>>> it's a string.
>>
>> By Integer is it a java class? or just a primitive data type? Maybe I 
>> can
>> modify Rodrigo's class and put it into CVS so you guys can use 
>> immediately...
>> however, I can't guarantee that it will be included in the next 
>> release...
>> Would that work?
>
> Oh, I always use native ints and fastutil wherever possible.
>
> Just a thought: I use autojar on my code to build a tiny fastutil jar 
> that just has the code I need. You could do the same thing to get 
> excellent native collections instead of writing your own. I see you 
> already wrote your own, but in case you need more.. Fastutil uses the 
> LGPL.
>
> Cheers.
>