Objects are not the most general thing to have at the base here.
A traditional object’s methods are a collection of functions that switch on the first argument’s type (we write the first argument before the function name with a dot in between:
myobject.a_function
We have a collection of versions of a_function that are distinguished by the type of that first argument (i.e. the class they’re defined in).
A more general version is functions that switch on multiple arguments — generally called Multimethods.
More general still, though, is just FP. Multimethods were invented in Common Lisp, and were just implemented in the language.
So, really, we want types on the data. For compound types, this is basically a relation (all the values of that type). And functions that can be applied to those types.
In my Frest project, you can attach triggers to tables, and this is much like having methods on classes.
Yeah, unfortunately my use of the word "object" will forever cause confusion when discussing this with other techies! I chose that name for *non-techies*, because the other three options (entity, thing, item) wouldn't convey the correct meaning to them.
Specifically: "entity" sounds like some poltergeist, "thing" sounds like, well, private parts or some vague fuzzy splodge, and "item" is something you're counting into a bag!
I'm afraid "object" is the only one that works for non-technical folk to convey tangible, semi-physical and self-animated (although it does mean that people/avatars are also "objects", to which they may ... object! *bdum-tshsh!*)
What this means is that objects are *also Inverted* compared to the Simula/Kay concept: they don't have methods at all, they simply observe each other's state!
As I say above, 'Now that we can only see data, data has to be our interface! Objects are “internally-animated” now, and interact through mutual observation, driving their mutual state dependencies.'
On the plus side, it brings FREST and the Object Net quite a bit closer together, and we can discuss mutual state dependency and pure (non-TC) functions... :-D
Objects are not the most general thing to have at the base here.
A traditional object’s methods are a collection of functions that switch on the first argument’s type (we write the first argument before the function name with a dot in between:
myobject.a_function
We have a collection of versions of a_function that are distinguished by the type of that first argument (i.e. the class they’re defined in).
A more general version is functions that switch on multiple arguments — generally called Multimethods.
More general still, though, is just FP. Multimethods were invented in Common Lisp, and were just implemented in the language.
So, really, we want types on the data. For compound types, this is basically a relation (all the values of that type). And functions that can be applied to those types.
In my Frest project, you can attach triggers to tables, and this is much like having methods on classes.
Yeah, unfortunately my use of the word "object" will forever cause confusion when discussing this with other techies! I chose that name for *non-techies*, because the other three options (entity, thing, item) wouldn't convey the correct meaning to them.
Specifically: "entity" sounds like some poltergeist, "thing" sounds like, well, private parts or some vague fuzzy splodge, and "item" is something you're counting into a bag!
I'm afraid "object" is the only one that works for non-technical folk to convey tangible, semi-physical and self-animated (although it does mean that people/avatars are also "objects", to which they may ... object! *bdum-tshsh!*)
What this means is that objects are *also Inverted* compared to the Simula/Kay concept: they don't have methods at all, they simply observe each other's state!
As I say above, 'Now that we can only see data, data has to be our interface! Objects are “internally-animated” now, and interact through mutual observation, driving their mutual state dependencies.'
On the plus side, it brings FREST and the Object Net quite a bit closer together, and we can discuss mutual state dependency and pure (non-TC) functions... :-D