Elements that can be either thin or thick

[wlin6927]

Right now most elements are defined as either ThinElement or ThickElement (some are just BaseElement), how to handle elements that can be either thick or thin (e.g., Kicker)? Is just defining them as BaseElement the way to go or should we come up with another way?

[ax3l]

Good question!

We could define them as thick and allow the special case of thickness 0 or another way...?

@cemitch99 what do you think?

[cemitch99]

@ax3l @EZoni This was discussed briefly during our weekly meeting. While the Thick/Thin distinction is important for tracking, this distinction doesn't reflect the way elements are defined in the existing standard (for which most elements can be thick or thin, depending on the value of length). One could either add a conditional based on the value of the length parameter, or eliminate the distinction in pals-python (by removing the two categories or classifying everything as thick) and leave it up to the tracking code to decide.

[EZoni]

My personal opinion is that the Python implementation should implement what is defined in the standard. If the standard doesn't define a distinction between thin and thick elements, then its Python implementation shouldn't define it either.

Note that the thin element class was introduced in #42 for the marker element introduced in pals-project/pals#98.

[EZoni]

@ax3l @cemitch99

Coming back to this issue, if PALS doesn't specify the distinction between thin and thick, shall we remove that distinction in pals-python as well, i.e., shall we open a PR to prototype the second solution proposed by @cemitch99 in #47 (comment)?

[...] or eliminate the distinction in pals-python (by removing the two categories or classifying everything as thick) and leave it up to the tracking code to decide.

[ax3l]

I did not look closely the first time, but yes indeed: Thin and thick base classes are just implementation details.

PALS-Python uses the thin element only a helper function to implement marker (and to add: empty/placeholder element), to not duplicate the logic..
An implementation detail like a base class or helper function does not need to be defined in PALS standard.

All physical PALS-Python elements are thick by definition, just as PALS standard.

[ax3l]

Or, you know what, since people get confused: just remove the ThinElement, derive Marker from BaseElement and define:

    # Segment length in meters (m)
    # always 0 for marker, not modifiable
    length: Literal[0.0] = 0.0

All other elements can derive from ThickElement.

I just used this helper since we might want to share more logic/interfaces or have more zero-length book-keeping elements. We can always reintroduce it when needed.

[ax3l]

Fixed via #53