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 
> we
> 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.
> Cheers
> Pieter
> Excerpts from Marko Rodriguez's message of September 28, 2016 7:18 :
>> Hi,
>> Right now we have:
>>      addV().property(a,b).property(c,d,e,f)
>> The second property() call creates a c=d vertex property with e=f 
>> meta-property.
>> We could do this:
>>      addV(a,b,c,d).property(c).property(e,f)
>> That is, addV() has a Object[]… arg. However, seems to be the same length of 
>> characters. Though, without meta-properties:
>>      addV().property(‘a’,b’).property(‘c’,’d’)
>> …becomes:
>>      addV(‘a’,’b’,’c’,’d’)
>> I don’t really like Map as that is not a type we use anywhere else… Marko.
>> http://markorodriguez.com
>>> 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>
>>> wrote:
>>>> Anyone interested in seeing a Graph.addVertex(Map) overload?
>>>> https://issues.apache.org/jira/browse/TINKERPOP-1174
>>>> 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
>>>> of.

Reply via email to