One clarification inline. On Thu, May 7, 2015 at 5:23 AM, Marko Rodriguez <[email protected]> wrote:
> Hello Matt, > > > - 639 <https://issues.apache.org/jira/browse/TINKERPOP3-639> (select > and > > selectList). There is already PR#57 > > I'm still not sure this is the path that we want to go down. I just see > rippling requirements of xxxList or xxxMap falling from such a choice. > What about the discussion on tail/head or last/first or allowing negative indices in range/limit? Spin that into its own JIRA ticket? > > > - 619 <https://issues.apache.org/jira/browse/TINKERPOP3-619> (select > > should not throw). There was some progress on choosing the desired > > behavior, but it sounds like a final decision is pending. > > This is doable. I suspect a no-result for when nothing binds --- like how > filter() works (i.e. while(true) { if(hasSomething) return something;}) > > > - 652 <https://issues.apache.org/jira/browse/TINKERPOP3-652> (select > > from Map explicitly). Is it a good idea to require Scope.local to do > > select from Map? Or is selectKeys more appealing? > > This is a good one. I just don't like the select(local,"a","b") in this > context as it makes MatchStep look ugly. However, it is probably the way to > go and only MatchStep usage would be effected. SelectGlobalStep, > SelectOneGlobalStep, SelectLocalStep, and SelectOneLocalStep. eek. Lots of > "stuff" but yea, the Scope concept should propagate to here. > > What would be crazy is g.V.out.select(local,"name","age")…….. gnarly. I > always wanted Element to implement Map, but there were reason (I forget) > why it wouldn't work. If it did, then has() would work on Maps. > > hashMapStep.has("a").has("a",eq(32)) > > Instead, for such situations, we have where(). > > hasMapStep.where("a",eq(32)) > > We don't have where("a"). Be easy to add. > > > Not trying to rush anyone, but I have cycles to spend on this over the > next > > couple of weeks. > > HTH, > Marko. > > http://markorodriguez.com
