These are chat archives for bio4j/angulillos

20th
Mar 2016
Alexey Alekhin
@laughedelic
Mar 20 2016 17:06
@eparejatobes hi.
so what's wrong with #54?
Eduardo Pareja Tobes
@eparejatobes
Mar 20 2016 17:17
well
Eduardo Pareja Tobes
@eparejatobes
Mar 20 2016 17:25
In general it's better to keep things at the graph level
it gives you a way of having one place where you can override behavior when needed
Alexey Alekhin
@laughedelic
Mar 20 2016 17:31
but those methods are not essential, it's just convenience, what they do is: check that your argument edge has a certain arity, call .outE (which relies on the implementation in the graph) and just add .findFirst().get or whatever.
so in the changed code, if you want to change how .outE works, you just do in the graph as before. only implementation in the graph communicate with the raw untyped-graph.
Eduardo Pareja Tobes
@eparejatobes
Mar 20 2016 17:40
Not really. If your untyped graph has something like "give me first vertex out of"
it's cleaner to do that on the graph class
vertices and edges shouldn't carry any behavior
everything should be done on the graph
Alexey Alekhin
@laughedelic
Mar 20 2016 17:45
but in any untyped graph API this will be on the vertex
I don't see these methods as behaviour. as I wrote, they are just some shortcuts, that come from the way you defined your edges types.
Eduardo Pareja Tobes
@eparejatobes
Mar 20 2016 17:51
it won't be on the vertex
just check the code of any graph db
it will be in the end directed to a transaction
Alexey Alekhin
@laughedelic
Mar 20 2016 17:51
tell me how it is Titan? or in Tinkerpop API?
Eduardo Pareja Tobes
@eparejatobes
Mar 20 2016 17:51
i.e. a graph
Alexey Alekhin
@laughedelic
Mar 20 2016 17:53
I see TitanVertex.query() and what it inherits from tinkerpop: gremlin.structure.Vertex.edges()
when you imlpement it in angulillos-titan, you do it by using these methods on the (raw) source vertex.
Alexey Alekhin
@laughedelic
Mar 20 2016 18:00
here these methods are in the end directed to the graph's .outE as well
but Titan doesn't expose an API for doing this from the graph (as there is no point in such API, because if you already have the source vertex, what's the point)
Eduardo Pareja Tobes
@eparejatobes
Mar 20 2016 18:05
what do you mean?
all outV/in/whatever
is implemented by delegating to the tx = graph
for example
Alexey Alekhin
@laughedelic
Mar 20 2016 18:12
I'm saying that
  • on the level of implementation, it's the same in #54 (everything is done through the graph)
  • and on the level of API, (as far as I see) you cannot do that in Titan from the graph

I don't see the point in this huge code duplication :neutral_face:

If we are talking about the current situation, we have only one half-baked implementation using Titan and it doesn't have any special API for retrieving edges according to their arity.

And if you are talking about extensibility for other implementations, then these methods should be in the untyped graph.

Eduardo Pareja Tobes
@eparejatobes
Mar 20 2016 18:17
I don't see any code duplication
you can refine untyped graph later on and add them if needed
if you add them to the untyped graph you create more objects in this case
and again, the whole point is to have all behavior centralized
in the corresponding graph
Alexey Alekhin
@laughedelic
Mar 20 2016 18:20
are you going to override these methods in a particular typed graph?
Eduardo Pareja Tobes
@eparejatobes
Mar 20 2016 18:20
it's perfectly possible
Alexey Alekhin
@laughedelic
Mar 20 2016 18:21
I think that implementations of TypedGraph shouldn't depend on a particular UntypedGraph backend
Eduardo Pareja Tobes
@eparejatobes
Mar 20 2016 18:21
they could. There's no other way of doing ad-hoc polymorphism than through subclassing
Alexey Alekhin
@laughedelic
Mar 20 2016 18:22
typed graph as well as typed vertex/edge, etc are just a way to declare the graph schema and use the API taking dvantage of this schema