![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
jasper graphs are like property graphs, with the perspective allowing one to rotate properties into vs. edges, e.g. to choose which property type is the preferred type that specifies outgoing edges, and to rotate properties into labels, e.g. to choose which property type is the preferred type that specifies node labels.
mb should generalize this: perspectives select which properties are used to define any number of special meanings.
__get and __set are among these, i suppose? or do they come with the perspective?
how do we reconcile node binding and our immutable preference/required syntax for references?
if nodes can be bound, i guess edges can too, since they can be reified into nodes (or they could even just be nodes; e.g. the same node can appear as a node and as an edge, i guess, there is not necc. a level distinction.. hmm..)
--- note: going to try out the term 'net' instead of 'graph'. ---
much as in OOP (or in ad-hoc polymorphism in general), the same symbol in the source code file can map to a different function, depending on the class of the object (or depending on what's in the prototype, in prototype languages). unify these, i guess.. after all, modules/namespaces are themselves just nets... the symbols in the source code refer to labels in the interface net that resolve to methods. Is an interface, then, a net pattern?
---
Perspectives allow one value to implement one interface in multiple ways, depending upon which perspective you are looking at. At different locations in the program, you can look at one value from different perspectives, meaning that you change the mapping from interface to implementation for that value.
The difference between this and simple coercion is that if you look at a projection perspective, the rest of the data is still in there. E.g. if under perspective A, x has fields field1, field2, and you look at it from perspective B, under which only field2 exists but it is called field1, then you mutate field2 and then look at it from perspective A again, you will find field1 unchanged and field2 mutated.
One issue is that, since we prefer immutability, usually functions will be returning new values rather than mutating the values that they were given. So, if you have some complex object in variable x (type C), and you have an interface that allows you to pretend it's just an integer, and it's currently pretending to be like '3', and you say 'y = x + 1', then y should not be 'just' 4; it should be an object of the same complex type as x pretending to be 4.
This means that either you have to be very careful not to use literals in functions very much (e.g. if addition were implemented as 'a + b: start with 0, then apply the successor function a times, then apply it b times, then return the result, then we'd be out of luck), or you have to find some way to know that if a function is operating on the value in x, then its concept of an Int type must be transparently lifted to realize a C pretending to be an Int, and therefore when that function thinks its calling an Int constructor it's really calling a C constructor. Moreover if C is remembering unrelated stuff (x is female, for example), then the constructor must copy that stuff in from x as appropriate. E.g. if x is female and x == 3 then if y x + 1 then y == 4 and y is female.
This seems a bit unclean and potentially problematic.
binds: nets can have binds WITHIN them; this does not make the net a reference, as mutating it does not mutate any other net. binds are per-perspective -- except that there is a way to make a net like a namespace, in which case the reference mechanics for its descendents are like variables. this is a form of boundary.
can we work in the ontological mappings here?
e.g. how does this situation/ontology map to wu xing? how does it map to tarot? how does it map to western 4-elements? in a binary system (active/passive), is the active principal visible or hidden?
