Hi All,
As I continue to take a further look into the list functions described in
Proposal 3, I noticed that they don't take in a Scope. Yet, it could have
been added because there are some functions that make sense as
ReducingBarriers. There are some instances, however, where the global scope
makes no sense so I would propose that we implement these as stated in
Proposal 3. I just want to point out that this would likely be the first
time local scope was used as a default for a Step (that isn't unfold) and
would like to give an opportunity for someone to voice their concerns about
this.
Let's take a look at one of the examples from Proposal 3.
List Example 1 (LE1)
Given a list of people, return the list of ages if everyone’s age > 18
g.V().hasLabel('person').values('age').fold().where(all(gt(18)))
Let's assume the proposal should have included this usage for all() that
takes a predicate as a parameter. If we remove the fold() from the above
example so that the example becomes
g.V().hasLabel('person').values('age').where(all(gt(18)))
If all() were to behave like a global scope step here then it would be
pretty meaningless as the incoming traverser is not a list type. In fact
the three proposed Steps that return boolean (all, any, none) shouldn't be
used unless the incoming traverser is an iterable type. In addition, the
set operations (intersect, union, disjunct and difference) also require the
incoming traverser to be a list/array type for them to have any sort of
meaning. I think it's reasonable for the default behavior of all the
proposed list functions to be the local scope versions. The concat() string
function has already set a precedent of not taking Scope as a parameter as
it currently only supports the global scope. In this case, for list
functions, we would only support local scope. If the user needs global
scope functionality then they would just need to add a fold() to their
query.
Does anyone have objections to allowing this to become the default behavior
for these Steps?
Thanks,
Ken
