Re: [Emc-developers] on the integer question by Rene

[Robert S. <rm...@un...>]

Am Montag, dem 08.06.2026 um 12:35 +0200 schrieb Bertho Stultiens:
> This is along post. Please read it in its entirety.
[...]

you are right, the question of the underlying datatype is orthogonal to
getter/setter.

Having dealt with the mess in the noparam branch and seen all different
"hacks" how pins and parameters are created and what it would entail to
unify them (for the purpose of making parameters linkable which would
be a very very nice feature) and the challenges it poses to debug that
stuff, I'm very much in favor of cleaning up the interface and
requiring access to HAL pins go through explicit accessor methods.

Multiple implementations of access to hal shared memory are to be
avoided if possible, I would make some exceptions for C++ template code
if it is warranted (e.g. by making python bindings easier via pybind).

I would probably keep some sort of "type", even if the underlying bits
will eventually be double or whatever, just as a hint for the user and
GUIs. Also the difference between parameter and pin should be kept as
some sort of "metadata", with the distinction being "pins" contain
runtime process-data that is supposed to change whereas "parameters"
contain configuration data that is usually not supposed to change while
a program is executing.

The naming-thing is a UI problem IMO, so if you want pins and
parameters in one treeview, halshow et al should be changed to offer
such additional views.


Another approach that would be possible in principle with accessors
would be to do conversion between types in the setter/getter functions.
The disadvantage would be that this could lead to surprising behaviour
and you can't explicitely decide if you want to truncate, saturate,
round or whatever to convert a value.

-- 
Robert Schöftner <rm...@un...>