You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by Michael Pollmeier <mi...@michaelpollmeier.com> on 2016/01/10 23:51:49 UTC
Re: Reason for different types on `by` steps
No answer on this one yet - what's a better place to ask? Should I
create a jira ticket instead?
On 12/21/2015 06:59 PM, Michael Pollmeier wrote:
> I don't understand the types on the `by` steps that take a function
> projection.
>
> 1) Shouldn't it be `Function<E, V>` for the function parameter in both
> cases?
> 2) What is the reason for constraining the function passed to the second
> one to `Element`?
>
> without comparator:
> <V> GraphTraversal<S, E> by(Function<V, Object>)
>
> with comparator:
> <V> GraphTraversal<S, E> by(Function<Element, V>, Comparator<V>)
>
> (from GraphTraversal.java)
>
> Cheers
> Michael
>
Re: Reason for different types on `by` steps
Posted by Marko Rodriguez <ok...@gmail.com>.
Hi,
We can't go back to groupBy(), orderBy(), etc. First, by() is the style we have adopted and for group() you have two by()s. A "key" and a "value". There are various steps that make use of multiple by()s -- group(), path(), tree(), select(), ...
g.V().group().by("age").by(sum())
by("age") is the key traversal.
by(sum()) is the value-reduce traversal.
Next, yes, looking at the GroupTest (Java) examples, its pretty brutal with the <X,Y>group(). If you can figure out how to keep group() and by() and make it work without <X,Y> that would be cool.
Looking at order(), groupCount(), aggregate(), etc. The by()-modulation doesn't cause crazy <X,Y> declarations. Seems group() is are only burp.
Thank Michael,
Marko.
http://markorodriguez.com
On Jan 13, 2016, at 3:58 PM, Michael Pollmeier <mi...@michaelpollmeier.com> wrote:
> Ok now I understand why you did that.
>
> The problem is that you can't use the type parameters `E` from your GraphTraversal because you split up `group` and `by` into separate steps.
> E.g. for `g.V()` the type parameter `E` is `Vertex`, which makes sense.
> But for `g.V().group()` the type parameter `E` becomes `Map<Vertex, ???>`. So then the by step doesn't know that it operates on a Vertex any more and you have to pass `Vertex` to the `by` function.
> I.e. the developer has to specify all types rather than letting the compiler figure it out - e.g. in GroupTest.java:302 you had to write out the types all the way:
> `g.V().<String, Long>group().<Vertex>by(v -> v.<String>value("name"))`
>
> If you would have kept the groupBy step, the above would then become much shorter:
> `g.V().groupBy(v -> v.<String>value("name"))`
>
> Basically, the split of `group` and `by` makes the java API painful. Groovy doesn't care about the types so you probably didn't notice. If we care about the java API (I certainly do), then I would suggest to go back to `groupBy`, `orderBy` etc. or come up with an alternative solution.
>
> Does this make sense?
>
>
> On 01/12/2016 04:51 AM, Marko Rodriguez wrote:
>> Hi,
>>
>> I'm not sure why I did this. I suspect it could just be <U,V>. If you type it like that, do you run into an compilation issues? If you get it working as such and it makes sense without having to change any of the casts in the test suites, please provide a PR.
>>
>> Thanks,
>> Marko.
>>
>> http://markorodriguez.com
>>
>> On Jan 10, 2016, at 3:51 PM, Michael Pollmeier <mi...@michaelpollmeier.com> wrote:
>>
>>> No answer on this one yet - what's a better place to ask? Should I create a jira ticket instead?
>>>
>>> On 12/21/2015 06:59 PM, Michael Pollmeier wrote:
>>>> I don't understand the types on the `by` steps that take a function
>>>> projection.
>>>>
>>>> 1) Shouldn't it be `Function<E, V>` for the function parameter in both
>>>> cases?
>>>> 2) What is the reason for constraining the function passed to the second
>>>> one to `Element`?
>>>>
>>>> without comparator:
>>>> <V> GraphTraversal<S, E> by(Function<V, Object>)
>>>>
>>>> with comparator:
>>>> <V> GraphTraversal<S, E> by(Function<Element, V>, Comparator<V>)
>>>>
>>>> (from GraphTraversal.java)
>>>>
>>>> Cheers
>>>> Michael
>>>>
>>
>>
Re: Reason for different types on `by` steps
Posted by Michael Pollmeier <mi...@michaelpollmeier.com>.
Ok now I understand why you did that.
The problem is that you can't use the type parameters `E` from your
GraphTraversal because you split up `group` and `by` into separate steps.
E.g. for `g.V()` the type parameter `E` is `Vertex`, which makes sense.
But for `g.V().group()` the type parameter `E` becomes `Map<Vertex,
???>`. So then the by step doesn't know that it operates on a Vertex any
more and you have to pass `Vertex` to the `by` function.
I.e. the developer has to specify all types rather than letting the
compiler figure it out - e.g. in GroupTest.java:302 you had to write out
the types all the way:
`g.V().<String, Long>group().<Vertex>by(v -> v.<String>value("name"))`
If you would have kept the groupBy step, the above would then become
much shorter:
`g.V().groupBy(v -> v.<String>value("name"))`
Basically, the split of `group` and `by` makes the java API painful.
Groovy doesn't care about the types so you probably didn't notice. If we
care about the java API (I certainly do), then I would suggest to go
back to `groupBy`, `orderBy` etc. or come up with an alternative solution.
Does this make sense?
On 01/12/2016 04:51 AM, Marko Rodriguez wrote:
> Hi,
>
> I'm not sure why I did this. I suspect it could just be <U,V>. If you type it like that, do you run into an compilation issues? If you get it working as such and it makes sense without having to change any of the casts in the test suites, please provide a PR.
>
> Thanks,
> Marko.
>
> http://markorodriguez.com
>
> On Jan 10, 2016, at 3:51 PM, Michael Pollmeier <mi...@michaelpollmeier.com> wrote:
>
>> No answer on this one yet - what's a better place to ask? Should I create a jira ticket instead?
>>
>> On 12/21/2015 06:59 PM, Michael Pollmeier wrote:
>>> I don't understand the types on the `by` steps that take a function
>>> projection.
>>>
>>> 1) Shouldn't it be `Function<E, V>` for the function parameter in both
>>> cases?
>>> 2) What is the reason for constraining the function passed to the second
>>> one to `Element`?
>>>
>>> without comparator:
>>> <V> GraphTraversal<S, E> by(Function<V, Object>)
>>>
>>> with comparator:
>>> <V> GraphTraversal<S, E> by(Function<Element, V>, Comparator<V>)
>>>
>>> (from GraphTraversal.java)
>>>
>>> Cheers
>>> Michael
>>>
>
>
Re: Reason for different types on `by` steps
Posted by Marko Rodriguez <ok...@gmail.com>.
Hi,
I'm not sure why I did this. I suspect it could just be <U,V>. If you type it like that, do you run into an compilation issues? If you get it working as such and it makes sense without having to change any of the casts in the test suites, please provide a PR.
Thanks,
Marko.
http://markorodriguez.com
On Jan 10, 2016, at 3:51 PM, Michael Pollmeier <mi...@michaelpollmeier.com> wrote:
> No answer on this one yet - what's a better place to ask? Should I create a jira ticket instead?
>
> On 12/21/2015 06:59 PM, Michael Pollmeier wrote:
>> I don't understand the types on the `by` steps that take a function
>> projection.
>>
>> 1) Shouldn't it be `Function<E, V>` for the function parameter in both
>> cases?
>> 2) What is the reason for constraining the function passed to the second
>> one to `Element`?
>>
>> without comparator:
>> <V> GraphTraversal<S, E> by(Function<V, Object>)
>>
>> with comparator:
>> <V> GraphTraversal<S, E> by(Function<Element, V>, Comparator<V>)
>>
>> (from GraphTraversal.java)
>>
>> Cheers
>> Michael
>>