[ https://issues.apache.org/jira/browse/TINKERPOP-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15695551#comment-15695551 ]
ASF GitHub Bot commented on TINKERPOP-1483: ------------------------------------------- Github user robertdale commented on the issue: https://github.com/apache/tinkerpop/pull/446 This is interesting. I was unaware of some or didn't understand some implementation details. Taking a step back and looking at this again, I wonder if the original intent is more correct. Sorry @JPMoresmau :smiley: We have to ask what is the purpose of `Hidden`? And what is the purpose of `T.*.getAccessor()`? Looks like `Has` step internally use `T.*.getAccessor()` for equality tests. Is this more of an internal method or should it be exposed? Ultimately, the question is with what or how do we expect to access `T` tokens in a value map? Given: `map = g.V().valueMap(true).next()` Access by: `map.get(T.id)` **or** `map.get(T.id.getAccessor())`? If the answer is `T.id` then the interface must be <Object,Object> If the answer is `T.id.getAccessor()` then the interface must be <String,Object> In either case, there is no conflict between system-level `T` tokens (e.g. `T.id`), as these are either Enum or `Hidden`, and user-level strings (e.g. `id`). > PropertyMapStep returns Map<String,E> but puts non String keys in it! > --------------------------------------------------------------------- > > Key: TINKERPOP-1483 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1483 > Project: TinkerPop > Issue Type: Bug > Components: process > Affects Versions: 3.2.2 > Reporter: JP Moresmau > > PropertyMapStep.map has return type Map<String,E>, but if includeTokens is > true: > {code} > if (element instanceof VertexProperty) { > map.put(T.id, element.id()); > map.put(T.key, ((VertexProperty) element).key()); > map.put(T.value, ((VertexProperty) element).value()); > } else { > map.put(T.id, element.id()); > map.put(T.label, element.label()); > } > {code} > T.id, T.key and T.value are NOT strings, so code looping through the keys in > Java fails. toString() are missing... But do we rely on having these keys in > other operations? -- This message was sent by Atlassian JIRA (v6.3.4#6332)