addV(Object…) was deprecated because it didn’t support Parameters (that is,
dynamic traversal based parametrization).
We could support it in Object.., but then stuff looks weird:
You really don’t save that much typing and I think its best to be explicit so
traversals are more readable.
To @pieter. In terms of Map arguments. We don’t have any steps/sources that
take Map arguments. I would prefer not to introduce a new data structure
especially when its so fuggly to create in Java.
> On Sep 28, 2016, at 1:03 PM, Pieter Martin <pieter.mar...@gmail.com> wrote:
> Well, I have to say I really like Map. In almost all of our code by the time
> are ready to create a vertex we have the properties already in a map. Data for
> the most part are not captured by humans typing gremlin but by machines and
> they store key value pairs in a Map.
> Excerpts from Marko Rodriguez's message of September 28, 2016 7:18 :
>> Right now we have:
>> The second property() call creates a c=d vertex property with e=f
>> We could do this:
>> That is, addV() has a Object… arg. However, seems to be the same length of
>> characters. Though, without meta-properties:
>> I don’t really like Map as that is not a type we use anywhere else… Marko.
>>> On Sep 28, 2016, at 10:41 AM, Stephen Mallette <spmalle...@gmail.com> wrote:
>>> Matthias re-opened that issue now looking to see g.addV(Map) given my
>>> reasoning for closing.
>>> On Tue, Sep 20, 2016 at 12:49 PM, Stephen Mallette <spmalle...@gmail.com>
>>>> Anyone interested in seeing a Graph.addVertex(Map) overload?
>>>> I don't imagine there would be any change to addV() in this case. I'm
>>>> thinking that we wouldn't likely use this method internally and so it would
>>>> more be something for user convenience, in which case, it seems to
>>>> encourage more use of the Graph API which we're typically trying to do less