[jira] [Commented] (TINKERPOP3-902) Remove g.E() in favor of g.V().outE()

["Dylan Millikin (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TINKERPOP3-902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14966365#comment-14966365 ] 

Dylan Millikin commented on TINKERPOP3-902:
-------------------------------------------

Yeah we do this (and combinations with Lists). I think it might be a common scenario with application layers that provide ORM/OGM type functionality. 
With that said, changing the implementation to {{g.V().outE().has(id,within(1,2,3))}} should in most cases be a decently easy refactoring. The only sticking point I can find is that some OOP to string (e.g.: gremlin) manipulation libraries might do something along the lines of {{NON-JAVA .E(...String) => GREMLIN E(...String)}}. The equivalent with {{has()}} and {{within()}} is a significantly more complex switch.

Just thought I'd point that out. Is the maintenance overhead important enough that it warrants the deprecation?

> Remove g.E() in favor of g.V().outE()
> -------------------------------------
>
>                 Key: TINKERPOP3-902
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP3-902
>             Project: TinkerPop 3
>          Issue Type: Improvement
>          Components: process
>    Affects Versions: 3.0.2-incubating
>            Reporter: Marko A. Rodriguez
>            Assignee: Marko A. Rodriguez
>              Labels: breaking
>             Fix For: 3.1.0-incubating
>
>
> I think we should get rid of {{g.E()}} as this is simply {{g.V().outE()}}. The only benefit is being able to access an edge by id... do people do this?
> {code}
> g.E() => g.V().outE()
> g.E(1,2,3) => g.V().outE().has(id,within(1,2,3))
> {code}
> The argument for keeping {{g.E()}} is the second case above.... Anywho, just an idea.
> NOTE: Deprecation is easy here.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)