Differences

This shows you the differences between two versions of the page.

--- tutorials:custom_storing_node [2025/07/16 14:21] – [Using custom edges] gaetan
+++ tutorials:custom_storing_node [2025/11/25 11:58] (current) – gaetan
@@ Line 200: / Line 200: @@
 One the left: before the "grow" method, on the right after. On the right picture, we can see that B and A have both the SUCCESSOR edge **AND** the custom EDGE_O. In this case the additional EDGE_0 might not bring much knowledge, however, in more complex project, A and B might not be directly related. Thus, adding the edge EDGE_0 adds both the knowledge of the ''parentNode'' "attribute" and it can be used to speed up future XL queries.
+  * If B do replace A. And the relationship between B and A must exists even though A is not part of the **visible** part of the graph.
+<code java>
+public void grow()[
+    a:A ==> B [-e->a];
+]
+</code>
+will produce the graph:
+{{ :tutorials:tuto_store_node_9.png?100 |}}
+You can see that the Node A is still part of the main graph. It is XL query-able and reachable from B by following the edge EDGE_O. However, as the Node A is not connected to the Root by neither BRANCH, nor SUCCESSOR edge, it will not be displayed (not part of the 3d view, and raytracer).
+**Note:** In the example we used EDGE_O, there are actually 13 usable unique bit-wise edge type defined in Library: EDGE_0 to EDGE_12. But it is also possible to use any Integer as "unique" edge bit. It is still important to know that the edge bit is used for bit wise operations. Thus if the edge bit you use contains the bit SUCCESSOR, the edge will be a successor.
+==== Example code ====
+<code java>
+module A;
+static int e = Library.EDGE_0;
+module B {
+	public A* getA(){
+		yield (* @128; this -e-> A*);
+	}
+}
+protected void init ()
+[
+	Axiom ==> A F ;
+]
+public void grow()[
+	a:A ==>  B [-e->a], a.setExtentIndex(7);
+]
+public void printParent()[
+	b:B ::> println(b.getA());
+]
+</code>