Consider adding `by(Key[T])`

[metasim]

Is there a technical reason the current implementations only support using String? Or is it just a todo?

[metasim]

Noting there's a whole bunch of the elementPropertyKey like parameters that are String rather than Key[T].

[mpollmeier]

by can be used in conjunction with lot's of different steps in gremlin-groovy. For gremlin-scala it's a bad idea though because it's important for the type inference to know which step it's being used with. That's why I provide orderBy and want to deprecate order.by. Same for group.by, better use groupBy.

So basically I want to get rid of all by variants. Maybe now we're at a point where we can make that keen move... thoughts?

[mpollmeier]

based on #143 there might actually be a need for by. So maybe we should just add by(Key) as you suggested.

[metasim]

If orderBy(A) translates into the TP equivalent order().by(A), is there a semantic (or performance) difference between order().by(A).by(B) vs. order().by(A).order().by(B) when writing orderBy(A).orderBy(B) in GS?

Personally, I'd argue for sticking with mirroring TP Gremlin as closely as possible, rather than introducing new functions.

[mpollmeier]

In the case of order.by that completely makes sense. the by step was only annoying in a different context: group.by. I apologise, little by step! :)