BDFL thoughts on JEP 3

[marsninja]

Hi @chandralegend

Interesting JEP. My primary concerns is related to performance on large graphs and language concept clashes. At the moment if you reference instead of person_node = node::person(name=="chandra"); , person_node = --> node::person(name=="chandra"); you would get the desired behavior at the scope of whats connected to the node find_people. You can also imagine the developer creating a chain of centralized nodes, lets call it peoplesets thats you can travel through searching for the given person.

In a way, we have to balance 2 ways of thinking about it. First way is to think about if you had a class person in python with field name, this would be synonymous of arbitrarily getting all people objects in the entire memory that has the intended name (not possible or desirable in python language). On the other hand we can think of it as having a database for which you are filtering it on a particular field, as in Djangos ORM (both possible and desirable). Interesting to think about, Thoughts? @chandralegend @ypkang

[marsninja]

For reference this is the example in JEP 3

walker find_people {
    has name;
    person_node = node::person(name=="chandra"); 
    std.out(person_node.name); // chandra
    // this will return the reference to the node with name "chandra". doesnt matter where it is in the graph.'
    // whether it is connected to the current node or not. This can be done because we have a complete graph. with generic bidirectional edge between every node.
}

[eldonm]

@chandralegend has a valid ask. I've run into inconveniences without a way to globally fetch references to nodes regardless of current context. This includes by property as well as by type. I'd suggest more of a way to query "a database for which you are filtering it on a particular field" as an approach to address the issue rather than a "generic bidriectional edge between every node" . On that note, I also think it is slightly misleading to allow bidirectional traversals on generic edges in spite of them being established as directed. Why have bidirectional edges, then (<-->) e.g a ++> b b ++> c can allow take <-- from b to get to a.

[marsninja]

I generally agree on the convenience of referencing nodes, etc. more freely than having to use the take command in every case. I've got some ideas to propose, let me think about it for a bit.

On the bi direactional edge piece @eldonm , if you have a-->b-->c and a walker on b can have a take <-- and get to a, that a bug, throw together a quick walker that demos the issue and shoot it over and we'll fix it. Only in the case that you have a<-->b should a take <-- from be get you to a with teh current design. Removing bidirectional edges alltogether might be interesting, I havent seen them used by anyone though I originally thought they would be useful. Another potential arguement is users can simply use 2 edges, and having the <--> adds to potential confusion when encountering bugs. Feel free to submit a JEP on that, see (https://github.com/Jaseci-Labs/jaseci2/blob/main/docs/docs/internals/jep/accepted/JEP_1.md)