-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
default out should be Stream<X>, not Optional<Stream<X>> #40
Conversation
also, now that we're at it: |
👍 |
I started with this and now |
@pablopareja @laughedelic a summary of how things are here
thoughts? |
I agree with |
yes, there's |
ok, so I think it would be good to have
|
+1 from me |
@laughedelic @pablopareja please review. I'm happy with the current state. The names for arities are far from perfect, but I cannot think of anything better right now. Suggestions more than welcome |
I agree with @laughedelic, I would keep
and then I would add a new naming for the ones returning an empty/non-empty
|
@pablopareja fine. I don't get the last part about inAny though |
but that's just what a Stream is, right? |
yes but since the arity of the results is expressed in the function name for the rest of the cases I think it is quite straightforward to do the same in the case of the |
In general the return type is a Stream; if you know more about it you can then say that it is
you always have in/out with no qualifiers, which returns a Stream. What's the point of having something with a different name doing exactly the same? |
I don't know, at least for me it's much more intuitive to have the qualifier Any in the case where you can get any quantity of elements without having to think about the implication that the returning type is a Stream and thus any amount of elements could be returned... |
Another, more verbose, option is to use as suffixes
This would fit better with a somewhat more intuitive naming scheme for arities:
where we could leave any of them empty if there's nothing to say about it. This would yield public enum arity {
fromOneToOne,
fromOneToAtMostOne,
fromOneToAtLeastOne,
fromOne,
fromAtMostOneToOne,
fromAtMostOneToAtMostOne,
fromAtMostOneToAtLeastOne,
fromAtMostOne,
fromAtLeastOneToOne,
fromAtLeastOneToAtMostOne,
fromAtLeastOneToAtLeastOne,
fromAtLeastOne,
toOne,
toAtMostOne,
toAtLeastOne,
// whatever
any;
} WDYT? |
Sounds good to me but, why don't adding
🐙 |
I'm fine with |
public enum arity {
oneToOne,
oneToAtMostOne,
oneToAtLeastOne,
oneToAny,
atMostOneToOne,
atMostOneToAtMostOne,
atMostOneToAtLeastOne,
AtMostOneToAny,
atLeastOneToOne,
atLeastOneToAtMostOne,
atLeastOneToAtLeastOne,
atLeastOneToAny,
anyToOne,
anyToAtMostOne,
anyToAtLeastOne,
// whatever
anyToAny;
} |
👍 |
1 similar comment
👍 |
I think we should keep the in/out suffixes the same though; inAtMostOneV(rel) sounds weird, like give me only those vertices which have at most one rel in. |
@laughedelic @pablopareja please review |
I didn't understand you last comment (#40 (comment)). Otherwise it seems to be ok. |
So what do you suggest? to leave it |
Yes! :) What you can see in https://github.com/bio4j/angulillos/tree/360f814a87a5792dfb0551d130861941e97bbd80 |
I'm a bit lost too... public enum arity {
oneToOne,
oneToAtMostOne,
oneToAtLeastOne,
oneToAny,
atMostOneToOne,
atMostOneToAtMostOne,
atMostOneToAtLeastOne,
AtMostOneToAny,
atLeastOneToOne,
atLeastOneToAtMostOne,
atLeastOneToAtLeastOne,
atLeastOneToAny,
anyToOne,
anyToAtMostOne,
anyToAtLeastOne,
// whatever
anyToAny;
} is not valid anymore? |
yes, just look at the code. Arities are defined in |
👍 |
I'm merging this, and finishing planning what we want to be in 0.5 |
Several breaking changes here, but mostly about names. 1. We dropped `Optional<Stream<X>>` in favor of just `Stream<X>`. An empty stream signals the equivalent of none before. See #40 2. We are using `E` as a _suffix_ for methods related with edges like `outE`, `inE`. 3. The names for arities have changed. See #41 and #40. They are defined in `TypedEdge.java`. Apart from that, documentation should display better on github.com. The build plugin was also updated.
What the title says. Everyone's going to use
Stream
taking empy into account, and a NEStream type in Java is not a viable alternative. This involves an API change, so I 'd like to do this ASAP.cc @laughedelic