If you’re going to make a patch node that should work regardless of the concrete data types on its pins, making your patch node generic is the way to go. Otherwise, you’d have to provide users with a repetitive set of nodes which differ only in pin types but act in the same way:
To follow the guide you have to know patch node creation basics. Also, make sure you’re familiar with the generic nodes concept and understand how the resolution process works.
The process of creating a generic patch itself is almost the same as creating a regular patch. The difference is that in case of a generic patch node, instead of placing terminals of specific types, you use:
Your patch may contain generic terminals only or mix regular and generic terminals.
The most straightforward way of implementing a generic patch is to build it out of other generic nodes. That is, make it a common XOD patch node.
Let’s implement a generic node which always passes an input value to its output, but once a pulse is triggered it outputs another input’s value for one second.
If you can find all the nodes required to compose your patch node, no extra steps are necessary. You and users of your library can start using the node right away.
If it is impossible to express a generic patch node as a pure composition, you have to mark it abstract. To make a patch abstract, place a
xod/patch-nodes/abstract marker node on it.
That forces XOD to search for a matching specialization patch when it processes the program. If a necessary specialization is not found, an error will show up, and the program will fail to transpile. Which is a good thing since it shows a xoder what’s missing so that he can provide an implementation for himself. See generics resolution process for details.
For a generic patch, you may provide several specialization patches. XOD searches for a matching specialization every time it encounters a generic node. It replaces the generic node with a specialized one if found.
The specialization patch is a regular patch, which either:
basenamedefines the base generic patch name and
t𝑛define particular types for which the specialization was created. For example
if-else(number)is a specialization for a generic patch
if-elsefor cases when a
numberis bound to its inputs.
<basename>, when it’s a specialization for a custom type defined within the same library. For example
xod-dev/w5500/open-tcpis a specialization for a generic patch
xod/net/open-tcpfor cases when a
xod-dev/w5500/w5500-inetis bound to one of the inputs.
Note, you can create specialization patches for generic patches created in other libraries, and XOD will pick them up correctly. That way, you can improve others’ work by making missing or optimized implementations.
To let XOD resolve generic nodes properly, you have to follow some rules while creating generic patch nodes and their specializations:
input-t2should appear as well.
If you’re creating a generic patch node, you have a few options: