Re: [zzdev] ZObs in the new GZigZag

[Tuomas Lukka <lukka@xxxxxxxxxx>]

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

Fun ;)

> 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.. :-)

Of course, we DO want to optimize that quite a bit...

> 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:

Why keywords? I'd strongly prefer cloned cells; the idea of chartreuse (0.8.0)
is to do things *right*, so using clones would be more appropriate.

> * 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:

I don't like that. I'd prefer the Java code to actually know the cell IDs
of the parameter cells. We really want to get rid of all string stuff.

> * 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.

The problem is that there may be more than one "x". The poor programmer
should just get used to thinking using cell ids. Of course, we'll need
to provide mechanisms to easily get them.

> Normally, we'd think that it's really ugly to use "streq" to see if cells
> match, 

*Always*.

> 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.. :-)  

I disagree. We need to have a proper system for 0.8.0, which *will*
still include a lot of Java code. I think you are possibly thinking
a bit too far ahead and because of that being satisfied with too little
today.

	Tuomas