Re: [zzdev] Re: [zzdev] Re: [zzdev] ZObs in the new GZigZag

[Tuomas Lukka <lukka@xxxxxxxxxx>]

> OK!  Here's the killer idea from Rauli: Let's write a clasm-function that
> prints out a java-class (to the console) of a ZOb in the structure.  That
> class would use IDs (filled already in there by the clasm-outputter) to
> get values for members.  ZOb members in the structure probably have no
> types, so in the Java class they could all be Cells... or maybe Callables.
> (Callables have asInt, asString, etc.)

Actually, it might be reasonable to associate a type with ZOb members 
in the structure, both for documentation and this. I'd like to know
that some parameter is a font, and another an int.

I like this. It could even be so that this is how the parent class
is generated, and the actual code is then put in as a derived class,
because of the general principle:

	MODIFYING GENERATED CODE IS WRONG.

Or do you mean that we should also write the Java code into the structure?
That's also a possibility...

> Unfortunately ZObs where more than one member have the same name would
> still be incompatible with that java-output-function, supposing it will
> write a matching java-class-member for each ZOb-member (sounds
> practical?)..  But that's "Java's problem" and not ours, right? :-)

How about a "d.javaname" dimension and giving the name of the instance
of the parameter in a Java-acceptable string?

	TUomas