default out should be Stream<X>, not Optional<Stream<X>>

[eparejatobes]

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

[eparejatobes]

also, now that we're at it: out -> outE

[laughedelic]

👍

[eparejatobes]

I started with this and now outManyOptional is even more confusing than before. I will write a first version where there's no outManyOptional; just use out in that case.

[eparejatobes]

@pablopareja @laughedelic a summary of how things are here

• There's a suffix for all in/out methods now: xxxE for edges, xxxV for vertices
• Optional is only used in the (in/out)OneOptional methods, which return Optional<X>
• The default case is Stream<X>, which means that (in/out)ManyOptional does not make any sense now; I removed it.
• What about (in/out)Many? this is arguable; it could be used to signal that you're going to return a non-empty Stream. I don't know.

thoughts?

[laughedelic]

I agree with (in/out)Many and I would also replace (in/out)OneOptional with just (in/out)Optional. Are there other things, like exactly one or at least one?

[eparejatobes]

yes, there's (in/out)One

[laughedelic]

ok, so I think it would be good to have

• (in/out)One
• (in/out)Optional
• (in/out)Many

[eparejatobes]

+1 from me

[eparejatobes]

@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

[pablopareja]

I agree with @laughedelic, I would keep

• (in/out)One
• (in/out)Optional
• (in/out)Many

and then I would add a new naming for the ones returning an empty/non-empty Stream which would be

• (in/out)Any

[eparejatobes]

@pablopareja fine. I don't get the last part about inAny though

[eparejatobes]

but that's just what a Stream is, right?

[pablopareja]

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 Stream (otherwise it doesn't make much sense to ever include this information)

[eparejatobes]

In general the return type is a Stream; if you know more about it you can then say that it is

• a Stream with exactly one element -> One
• a Stream with at most one element -> Optional
• a Stream with at least one element -> Many

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?

[pablopareja]

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...
I see it as a more understandable method naming but that's just my view...

[eparejatobes]

Another, more verbose, option is to use as suffixes

• One
• AtMostOne
• AtLeastOne
• (empty) which means the generic case where you don't know anything

This would fit better with a somewhat more intuitive naming scheme for arities:

• From(qualifier)To(qualifier)

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?

[pablopareja]

Sounds good to me but, why don't adding Any when there's nothing to say about it? 😃

fromAnyToOne ?

🐙

[laughedelic]

I'm fine with Any, but I would drop the from prefix

[eparejatobes]

public enum arity {

  oneToOne,
  oneToAtMostOne,
  oneToAtLeastOne,
  oneToAny, 

  atMostOneToOne,
  atMostOneToAtMostOne,
  atMostOneToAtLeastOne,
  AtMostOneToAny, 

  atLeastOneToOne,
  atLeastOneToAtMostOne,
  atLeastOneToAtLeastOne,
  atLeastOneToAny,

  anyToOne,
  anyToAtMostOne,
  anyToAtLeastOne,
  // whatever
  anyToAny;
}

[laughedelic]

👍

[pablopareja]

👍

[eparejatobes]

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.

[eparejatobes]

@laughedelic @pablopareja please review

[laughedelic]

I didn't understand you last comment (#40 (comment)). Otherwise it seems to be ok.

[eparejatobes]

@laughedelic see https://github.com/bio4j/angulillos/blob/feature/stream/only/api/src/main/java/com/bio4j/angulillos/TypedVertex.java#L181 for example

[laughedelic]

So what do you suggest? to leave it inOptionalV or to change to the inAtMostOneV?

[eparejatobes]

Yes! :)

What you can see in https://github.com/bio4j/angulillos/tree/360f814a87a5792dfb0551d130861941e97bbd80

[pablopareja]

I'm a bit lost too...
So this:

public enum arity {

  oneToOne,
  oneToAtMostOne,
  oneToAtLeastOne,
  oneToAny, 

  atMostOneToOne,
  atMostOneToAtMostOne,
  atMostOneToAtLeastOne,
  AtMostOneToAny, 

  atLeastOneToOne,
  atLeastOneToAtMostOne,
  atLeastOneToAtLeastOne,
  atLeastOneToAny,

  anyToOne,
  anyToAtMostOne,
  anyToAtLeastOne,
  // whatever
  anyToAny;
}

is not valid anymore?

[eparejatobes]

yes, just look at the code. Arities are defined in TypedEdge.

[pablopareja]

👍

[eparejatobes]

I'm merging this, and finishing planning what we want to be in 0.5