ZObs in the new GZigZag

[Tero Mäyränen <deetsay@xxxxxx>]

Thoughts about ZObs..

A ZOb-instance is a cell which has a negward connection on d.zob-class.
The headcell on d.zob-class may have some information connected to it
about the type of the ZOb, for example: what type was this type inherited
from, and default values for some members.  But mainly the headcell is a
clasm-function, which takes the parameters "ZOb-instance" and "member",
and returns the value of the member from the instance.

That's a pretty general definition, because it doesn't say anything about
the structure of the actual data in the object.  So perhaps this could
work as a generalization of "data objects" across the system in
different "applitudes", without the objects being forced to some
predefined "d.zob-*" dimensions..

One popular ZOb-member might be "set" which would be a clasm function for
setting the value of a member in an instance.

It's different from the old idea of ZObs, where they were a "way to map
java-objects into the structure" or the other way around..  In this thing,
generally, when you want a ZOb-member's value in Java, you'll need the ID
of the instance and the ID of the member you want, before you call a
java-function that eval()'s the clasm function in the headcell of the
instance on d.zob-class and returns the member's value.. :-)

So, as a special case and as the first implementation of a new ZOb,
I think I'll write a "Java-mapped ZOb".. In the structure it will
look just like a ZOb in the old system (keywords and values on the
user-dims), and I can think of at least two ways to do it in Java:

* There could be an abstract Zob-class, which takes the ZOb instance as a
parameter of its constructor and uses "The Reflection API" to read the
names of its public members and fills them up with values from the ZOb.
This would only match the strings in the member-cells to the names of the
public members, instead of using the member-cells' IDs...  or:

* There could just be a function that reads all the members of a
ZOb-instance, and their values, into a HashMap.  The key in the HashMap
could be the cell's ID (= the ID of the masterclone of the member)..  Or
it could be just a string, if we wanted to make it easier for the poor
programmer who just wants to get "x" without finding the ID of the
masterclone of the "x"-cell in the ZOb.

Normally, we'd think that it's really ugly to use "streq" to see if cells
match, but in this case, we're talking about an ugly special case of a ZOb
anyway, that can be easily changed later, when we have no java-code
anymore.. :-)  Because in any case there should also always be the "new
ZOb" -style clasm-function for getting the parameters (members)...  As
defined in the beginning.

I think this ZOb-system should be somehow extended into another clang on
top of clasm, where it would be easy to write code that gets members and
calls methods.  And it should be even easier for methods to get members
and call methods of the same instance that they were called from ("this").

I'm not sure if all this object-oriented thinking is really necessary in
Zigzag but ...

Comments, before I blow everything up? :-)

--
tero