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 <[email protected]> _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
