[ https://issues.apache.org/jira/browse/TINKERPOP-1924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16408493#comment-16408493 ]
Daniel Weber commented on TINKERPOP-1924: ----------------------------------------- Also, project(...) would not take values of type T (as T.id) as well. That could be another case where to possibly relax the signature. > Make meta-properties accessible via values(...)-step > ---------------------------------------------------- > > Key: TINKERPOP-1924 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1924 > Project: TinkerPop > Issue Type: Improvement > Components: structure > Affects Versions: 3.3.1 > Reporter: Daniel Weber > Priority: Minor > > I'm currently running into a situation where I'd like to access > meta-properties through the values(...)-method. Unfortunately, the signature > of values() only takes strings, so this is not possible: > {code:java} > g.V().values(T.id) > {code} > Of course, there's the trivial workaround: > {code:java} > g.V().id() > {code} > However, I'd like to get values for multiple properties, so the workaround > becomes ugly: > {code:java} > g.V().union(__.id(), __.values('key')) > {code} > That there would be no overload of values(...) supporting T-accessors is a > bit odd. has(...) has an extra overload for T-accessors, property(...) allows > arbitrary objects to be passed in as key. The valueMap-method allows > including T-accessors in the returned map. > Would it be possible to relax the signature of values(...) to take an > arbitrary list of objects instead of property keys of type string? If the > discussion here turns out in favor of such a relaxation, I could try to > implement the change. -- This message was sent by Atlassian JIRA (v7.6.3#76005)