[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: [zzdev] Re: [zzdev] Re: [zzdev] ZObs in the new GZigZag
- To: Tero Mäyränen <deetsay@xxxxxx>
- Subject: Re: [zzdev] Re: [zzdev] Re: [zzdev] ZObs in the new GZigZag
- From: Tuomas Lukka <lukka@xxxxxxxxxx>
- Date: Thu, 10 Jan 2002 14:44:34 +0200
- Cc: zzdev@xxxxxxxxxx
- In-reply-to: <Pine.GSO.4.33.0201101302440.13601-100000@xxxxxxxxxxxxxxx>; from deetsay@xxxxxx on Thu, Jan 10, 2002 at 02:05:31PM +0200
- Mail-followup-to: Tuomas Lukka <lukka@xxxxxxxxxxxxxxxx>, Tero Mäyränen <deetsay@xxxxxx>, zzdev@xxxxxxxxxx
- References: <20020110124511.A20867@xxxxxxxxxxxxxxxx> <Pine.GSO.4.33.0201101302440.13601-100000@xxxxxxxxxxxxxxx>
> 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?