[
https://issues.apache.org/jira/browse/TINKERPOP3-798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marko A. Rodriguez updated TINKERPOP3-798:
------------------------------------------
Description:
I don't like the terms {{mapKeys()}} and {{mapValues()}}. I think we should use
"select" as the term for all projections out of a tuple. For instance, we do:
{code}
select('a') // get the object referenced by 'a' out of the incoming map
select('a','b') // get the objects referenced by 'a' and 'b' out of the
incoming map
{code}
{{select()}} can even be used in situations that people don't typically think
to use it.
{code}
gremlin> g.V().has('name','Die Hard').groupCount().by('name')
==>[Die Hard:1]
gremlin> g.V().has('name','Die Hard').groupCount().by('name').select('Die Hard')
==>1
gremlin> g.V().hasLabel('movie').groupCount().by('name').select('Die Hard','Toy
Story','Jurassic Park')
==>[Die Hard:1, Toy Story:1, Jurassic Park:1]
{code}
However, this assumes the keys are strings as {{select()}} only takes string
arguments.
I think for all "project scenarios" the term should be "select." Thus, instead
of {{mapKeys()}} and {{mapValues()}}, we have:
{code}
select(keys) : Map -> Set<String>
select(values) : Map -> Collection<Object>
{code}
Moreover, I don't think these should be flatMap steps like {{mapXXX()}} as you
are projecting for EACH map (similar to how {{select('a','b')}} is not a flat
map of a/b entires but maps of a/b entries).
This type of select is different than the others as you are not projecting out
a value for an entry (row + key -> value), but a Collection value for column
(map + key/value -> collection). Regardless, it is still a projection of the
incoming map (or path!).
was:
I don't like the terms {{mapKeys()}} and {{mapValues()}}. I think we should use
"select" as the term for all projections out of a tuple. For instance, we do:
{code}
select('a') // get the object referenced by 'a' out of the incoming map
select('a','b') // get the objects referenced by 'a' and 'b' out of the
incoming map
{code}
{{select()}} can even be used in situations that people don't typically think
to use it.
gremlin> g.V().has('name','Die Hard').groupCount().by('name')
==>[Die Hard:1]
gremlin> g.V().has('name','Die Hard').groupCount().by('name').select('Die Hard')
==>1
gremlin> g.V().hasLabel('movie').groupCount().by('name').select('Die Hard','Toy
Story','Jurassic Park')
==>[Die Hard:1, Toy Story:1, Jurassic Park:1]
{code}
However, this assumes the keys are strings as {{select()}} only takes string
arguments.
I think for all "project scenarios" the term should be "select." Thus, instead
of {{mapKeys()}} and {{mapValues()}}, we have:
{code}
select(keys) : Map -> Set<String>
select(values) : Map -> Collection<Object>
{code}
Moreover, I don't think these should be flatMap steps like {{mapXXX()}} as you
are projecting for EACH map (similar to how {{select('a','b')}} is not a flat
map of a/b entires but maps of a/b entries).
This type of select is different than the others as you are not projecting out
a value for an entry (row + key -> value), but a Collection value for column
(map + key/value -> collection). Regardless, it is still a projection of the
incoming map (or path!).
> [Proposal] Rename mapKeys()/mapValues() to select(keys) and select(values).
> ---------------------------------------------------------------------------
>
> Key: TINKERPOP3-798
> URL: https://issues.apache.org/jira/browse/TINKERPOP3-798
> Project: TinkerPop 3
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.0.0-incubating
> Reporter: Marko A. Rodriguez
> Assignee: Marko A. Rodriguez
>
> I don't like the terms {{mapKeys()}} and {{mapValues()}}. I think we should
> use "select" as the term for all projections out of a tuple. For instance, we
> do:
> {code}
> select('a') // get the object referenced by 'a' out of the incoming map
> select('a','b') // get the objects referenced by 'a' and 'b' out of the
> incoming map
> {code}
> {{select()}} can even be used in situations that people don't typically think
> to use it.
> {code}
> gremlin> g.V().has('name','Die Hard').groupCount().by('name')
> ==>[Die Hard:1]
> gremlin> g.V().has('name','Die Hard').groupCount().by('name').select('Die
> Hard')
> ==>1
> gremlin> g.V().hasLabel('movie').groupCount().by('name').select('Die
> Hard','Toy Story','Jurassic Park')
> ==>[Die Hard:1, Toy Story:1, Jurassic Park:1]
> {code}
> However, this assumes the keys are strings as {{select()}} only takes string
> arguments.
> I think for all "project scenarios" the term should be "select." Thus,
> instead of {{mapKeys()}} and {{mapValues()}}, we have:
> {code}
> select(keys) : Map -> Set<String>
> select(values) : Map -> Collection<Object>
> {code}
> Moreover, I don't think these should be flatMap steps like {{mapXXX()}} as
> you are projecting for EACH map (similar to how {{select('a','b')}} is not a
> flat map of a/b entires but maps of a/b entries).
> This type of select is different than the others as you are not projecting
> out a value for an entry (row + key -> value), but a Collection value for
> column (map + key/value -> collection). Regardless, it is still a projection
> of the incoming map (or path!).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
