[M3devel] Information about record/object field name.

[mika at async.caltech.edu]

Of course field-order independent serialization won't actually work in
Modula-3 unless you know what you are doing.  (You will need to know
more than just the field name, in particular.)

Consider the following:

TYPE 
  T = OBJECT
    f : F;
  END;

  U = T OBJECT
    f : F;
  END;

VAR u : U;

with these declarations, the object "u" has two fields of the same type F called f.

A reference to u of type U, e.g.,

VAR p : U := u;

will see the second field

and 

VAR q : T := u;

will see the first field.  You can also switch fields by using NARROW.

In any case there will be two fields of the same name.  This is not
some accident of the language or a mistake or even bad coding practice.
It was deliberately done this way for the sake of modularity.

     Mika

"Rodney M. Bates" writes:
>This question raises several others in my mind.
>
>Since you mention a serializer, do I correctly presume you want
>the field names of a record/object type that exists in the same
>program doing the reading?
>
>Are you familiar with the existing compiler-generated type information,
>in RTTypeMap.i3 and RTTipeMap.i3, and accessible at runtime using RT0.i3
>and other things in m3-libs/m3core/src/runtime/common/*, and produced by
>the compiler in, e.g., m3-sys/m3front/src/misc/TipeDesc.i3?
>
>Unfortunately, neither of these kinds of runtime type information has
>field names, only a lists of field types in order.  For a serializer,
>runtime type information would be a far more convenient source, since
>it would not require having either source files or separate derived files (.M3WEB).
>Adding the field names here would probably not be a big coding change,
>but a change in runtime data structure would no doubt be a big bootstrapping
>and upgrading operation, for all concerned.
>
>Field names are also available in the generated debug information.  But
>even though this might be a more convenient location to get it from,
>decoding it this way would be a nightmare.  It's a specialized derivative
>of stabs, with lots of Modula-3-specific stuff mangled and encoded inside
>the string fields of stabs records.  gdb has gobs of code to read in
>general stabs and m3gdb has gobs more to further decode it, all in c.
>Moreover, there are quite a few differences in what is produced by
>various compilers, depending on the version of the M3 front end, the
>version of the gcc-derived code generator or the other code generators,
>and the target.
>
>The idea of field-order independent serializing at first seemed pointless
>to me.  I think the intent must be to allow a serialized object to be
>deserialized into a different program as a different type, with different
>field orders.  Is this the intent?  what are the rules about how different
>a type can be and still be used in this way?  Is it cross-language too?
>
>The existing Modula-3 serializer (m3-libs/libm3/src/pickle/ver2/Pickle2.i3 etc.)
>requires that there be type in the deserializing program that is an exact
>(structural) match to the type in the serializing program, according to the
>language's rules of type equality.  Pickle enforces this by looking for equality
>of a 64-bit "signature" that is a hash on a type structure, with the
>assumption collisions will not occur.
>
>Perhaps you have read enough of the runtime, compiler, and serializer
>to know all this already.
>
>Tell us more about the json serializer.
>
>On 01/28/2013 11:30 AM, Alexey Veselovsky wrote:
>> Hello.
>>
>> It is possible to retrieve field names for given Record or Object type?
>>
>> I need it for json serializer.
>>
>> Also this information useful for creating field-order independent serializer.
>>
>> Thanks, Alexey.