On 1/15/2026 4:05 AM, Halil Pasic wrote:
On Thu, 15 Jan 2026 08:28:51 +0100
Markus Armbruster <[email protected]> wrote:
I understand that you're mirroring how @poll-grow and @poll-shrink work,
but let's ignore that for a minute.
Compare four possible interfaces:
1. Optional @poll-weight defaults to 2. Values <= 0 are rejected.
2. Optional @poll-weight defaults to 2. Value 0 is replaced by the
default value 2. Values < 0 are rejected.
3. Optional @poll-weight defaults to 0. Values < 0 are rejected. Value
0 makes the system pick a value, namely 2.
4. Optional @poll-weight defaults to 0. Values < 0 are rejected. Value
0 makes the system pick a value. It currently picks 2.
The difference between 3. and 4. is that 3. makes "system picks 2" part
of the contract, while 4. doesn't.
1. is the simplest. Is 2.'s additional complexity worthwhile? 3.'s?
4.'s?
Isn't there more options? Like
5. Optional @poll-weight defaults to system-default. Value 0 is replaced
by the system pick the system default value. Currently the system default
value is 2. Values < 0 are rejected.
That would mean:
* current value inspectable
* system default not part of the interface contract
* interface offers a "please go back to value not user specified:
operation
BTW I like your approach with explicitly listing and evaluating the
options a lot!
Regards,
Halil
Thank you both for laying out options 1-5 so clearly; the detailed
breakdown was very helpful.
After considering the trade-offs, I agree that "Option 1" is the
simplest and most robust interface. It ensures the value exposed to
users always reflects the actual effect.
Option 5 is a clever way to reset values, but I'm leaning toward Option
1 to keep the interface as predictable as possible.
Avoiding special meanings for '0' makes the logic easier for users to
reason about.
I will update the next revision to follow "Option 1".
Thanks again for the feedback!
