Node locations are not saved about shift-java HOT 7 CLOSED

Please also consider making locations public.

In my usecase I don't want to use the parser more than once. I had problems with separate source codes with matching BindingIdentifiers resulting in the same Java Object and this was not an expected result. So I wouldn't mind if I did not have to pass the whole parser object forward, only the location information.

from shift-java.

Haha yeah, I expected this to be horribly broken right now. I will be adding location tests soon. Go ahead and send a PR to make the locations table public, but I'm not sure yet how I feel about that.

from shift-java.

@steindani, if we don't end up making it public (or in the meantime), you can always just subclass ParserWithLocation; something like:

public class ParserExposingLocationTable extends ParserWithLocation {
    public HashTable<Node, SourceSpan> getLocationTable() {
         return locations;
    }
}

from shift-java.

Thanks!

– Right now I'm fine with passing the parser, but this might need a better solution. It's not a burning problem. (Maybe a getter, since this way the variable couldn't be set from the outside, but the current "structure" could be acquired?)

– Is it the expected behaviour from the parser to result in the same Java Object for the same BindingIdentifier after using the same parser on two different sources? Is there some kind of caching?

– I did not have time yet to test it out, but the locations might have a one-off error. I've noticed it with the FunctionDeclarations, the start location is always marking the previous (empty) line. The end location seems to be fine.

from shift-java.

Oh, right. Thanks, @bakkot!

from shift-java.

They shouldn't be giving you the same object, but we've overridden equality on nodes. So if you're comparing using .equals, two nodes with identical properties will compare appear as equal.

The locations table is actually using equality instead of identity, which is a bug; I've fixed it in #106.

from shift-java.

Yeah, I've made the same mistake, instead of using IdentityHashMap I've
used HashMap in my code while converting the AST. Thanks for pointing
out!
On Mar 25, 2016 00:16, "Kevin Gibbons" [email protected] wrote:

They shouldn't be giving you the same object, but we've overridden
equality on nodes. So if you're comparing using .equals, two nodes with
identical properties will compare appear as equal.

The locations table is actually using equality instead of identity, which
is a bug; I've fixed it in #106
#106.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#104 (comment)

from shift-java.