eclipse-aascw / aas-core-codegen / 34776303801

85%

push

github

Compose the Go XML de-serialization (#688)

This is the Go counterpart of #686, but the C# design does not carry
over: the shape that works there fails to compile in Go, so the read
side is composed out of generated dispatchers instead of composed
readers.

Measured on the AAS meta-model fixture, the read region of
``xmlization.go`` goes 11,738 -> 5,584 lines (-52%), and the file as
a whole 22,846 -> 16,692. The ``read<X>WithLookahead`` band -- 50
functions, 3,057 lines -- goes to **zero**; 20 ``read<X>Dispatched``
functions stand in its place.

The whole design turns on one asymmetry in the wire format. An instance
element is self-describing: its local name *is* its type. A scalar
element is not: its name is its *position*, ``v`` in a list and ``v1``,
``v2``, ... in a tuple. So: every instance is read by dispatch on its
own name, every scalar by a name its container supplies, and nothing
else in the read path knows the difference.

``readElementDispatched`` is the only place which frames an XML element
around a value. ``readListOf`` and every ``readTupleN`` delegate the
framing to it, which is what deletes ``readListOfScalars``,
``readScalarWithName``, ``asScalarTupleItemReader`` and
``asInstanceTupleItemReader`` outright: one list helper, one item shape,
no adapters. It also returns the token *past* the end element, so the
"``read<X>WithLookahead`` stops at the end element, so we look ahead"
comment and its hand-written ``readNext`` vanish from every call site:

    readListOf(decoder, current, readReferenceDispatched)
    readListOf(decoder, current, readSubmodelElementDispatched)
    readListOf(decoder, current, readLongAtV)

    readTuple6(
        decoder, current,
        readLongAtV1,
        readSomeItemDispatched,
        readAbstractItemDispatched,
        readSomeItemDispatched,
        readLongAtV5,
        readResultAtV6,
    )

Per class, ``read<X>AsSequence`` has for every property case one
assignment of the same ``(value, current, val... (continued)

171 of 173 new or added lines in 1 file covered. (98.84%)

33935 of 39796 relevant lines covered (85.27%)

2.56 hits per line