There's one other thing I noticed during review. With the old GParamSpec + GObject based property API, the GObject machinery ensures that the GValue passed in to property setters complies with the GParamSpec value range. With our IDL API, nothing like that is enforced anymore. That means, an int32 property between 1-256 can now be set to 0 or -2^31 through the API. For a denominator to become 0 that could affect stability.
Please keep that in mind for ported properties and watch out if we shouldn't add extra guards, like:
denominator = CLAMP (input, 0, 256)
I think it might be better to re-add range enforcement. Right now, I would have to write this setter code:
and have the actual denominator (int val) function be generated automatically, which should
constrain val to param spec
do nothing at all if val equals the value returned by the getter
push undo if property has undo
call the _impl function
notify the property
Consider this a brianstorming idea I at least wanted to share. Maybe the actual implementation will be a bit different, but I think the general idea to have each setter always execute some steps at the beginning and some steps at the end of setting a property is likely to make our actual code simpler.
From our last BseSong merge:
I think it might be better to re-add range enforcement. Right now, I would have to write this setter code:
Note that we duplicate the defaults here, which is not ideal. So we could also check against the pspec, somewhat like
But I think ultimately what I really want to write is this code:
and have the actual denominator (int val) function be generated automatically, which should
Consider this a brianstorming idea I at least wanted to share. Maybe the actual implementation will be a bit different, but I think the general idea to have each setter always execute some steps at the beginning and some steps at the end of setting a property is likely to make our actual code simpler.