The only documentation of the "order" member of an option entry in AceConfig tells us this: relative position of item (default = 100, 0=first, -1=last)

From the "-1=last" bit, I hoped that the behavior would mimic Lua's string indexing, where -1 is the last character, -2 is the next-to-last, and so on.

No such luck. An option with order=-1 is the last option, but only so long as it is the only option with a negative ordering. Tossing in another option entry with order=-2 placed that option first, followed by the -1 entry, then the 0 entry, then the positive-numbered entries -- i.e., a "natural number line" ordering, where -1 no longer had special meaning. Adding a third entry with order=-10 resulted in -2 first, then 0 and the positive entries, then -10 and -1 last.

The end of compareOptions() in AceConfigDialog-3.0.lua looks like this:

if OrderA < 0 then
if OrderB > 0 then
return false
end
else
if OrderB < 0 then
return true
end
end
return OrderA < OrderB

So comparing a pair of negative orders doesn't return a meaningful result. Was this by design?

Changing those lines to

if OrderA < 0 then OrderA = OrderA + math.huge end
if OrderB < 0 then OrderB = OrderB + math.huge end
return OrderA < OrderB

makes negative orders behave like Lua coders might expect. The "-1=last" case is still preserved, too. Thoughts?

I rather like -1=last by design. The only thing I'm proposing is to correctly handle more than one negative option, in a way that feels natural to Lua programmers.

The intent of the spec was always to have -1 mean "last", and -2 mean "2nd last"

If AceConfigDialog does not do this, it's doing something wrong. And judging from your testing where negative numbers randomly end up ANYWHERE, it's simply broken with respect to negative numbers.

I'd say your fix is the right one (without having tested what offsetting things from math.huge actually does :) )

If AceConfigDialog does not do this, it's doing something wrong. And judging from your testing where negative numbers randomly end up ANYWHERE, it's simply broken with respect to negative numbers.

Well, currently comparing any two negative numbers returns "true". Which is... yeah, broken. :-)

I'd say your fix is the right one (without having tested what offsetting things from math.huge actually does :) )

I was careful to only add math.huge to negative numbers, so we don't have to worry about overflow.

Well, a minor change to just sort all the entries from smallest (most negative) to biggest (most positive) would solve the issue, and not break any existing addon.

Well, a minor change to just sort all the entries from smallest (most negative) to biggest (most positive) would solve the issue, and not break any existing addon.

Sorting in numerical order would break things. For a Lua-like ordering we want

0...1...2...3...4...5... all the 100's ...-5...-4...-3...-2...-1

(Remember that 100 is the default order value, so there may be a bunch of those.) Any normal sort is going to screw that up.

Right now you can have

0...1...2...3...4...5... all the 100's ...other positives...-1

but that's all. Changing the negatives into large positives would then allow a normal sort to do everything exactly right.

Changing the negatives into large positives would then allow a normal sort to do everything exactly right.

Well, but technically no matter how large those positives are, it's possible that user also defined elements with equally large 'order' values. In that case, this scheme would still break the expectation.

I always understood the semantics of 'order' to mean that all positives should come before all negatives, and within those halves, things were sorted numerically ascending. So 0 comes first, then other positives in order, then the negatives from smallest (most negative) to largest (least negative, i.e. -1).

Edit: I realize that second paragraph is redundant to your original post, I'm just agreeing with you there. Nonetheless, adding math.huge to negatives is I think not perfectly reliable, because something with order -1 should still come after something with order (math.huge - 1), the former being negative and the latter positive.

Fair enough. Whichever way the AceConfig authors want to go would be preferable to the semi-random brokenness that's currently present. All that needs be done is for them to make a decision and then check in some code.

I personally seriously doubt that coders would themselves being using order numbers anywhere close to math.huge -- it is <voice mode="patrick stewart SNL sketch">frickin' HUGE</voice> after all -- but details like this are the kinds of things that I can "bikeshed discussion" about endlessly.

We would never code a hack with math.huge in there, we would rather produce proper logic to sort it accordingly to the design idea, its not that hard :)

Somebody with commit privs want to actually check in a change then?

I thought the two-line solution was simple enough, but if you're worried that a library user might conceivably manually assign an ordering value of several gazillion, then by all means fix it some other way. :-)

It's been a year. We still satisfied with more than one negative number resulting in unpredictable behavior, or would somebody like to check in a change? :-\

Rollback Post to RevisionRollBack

To post a comment, please login or register a new account.

relative position of item (default = 100, 0=first, -1=last)From the "-1=last" bit, I hoped that the behavior would mimic Lua's string indexing, where -1 is the last character, -2 is the next-to-last, and so on.

No such luck. An option with order=-1 is the last option, but only so long as it is the only option with a negative ordering. Tossing in another option entry with order=-2 placed that option

first, followed by the -1 entry, then the 0 entry, then the positive-numbered entries -- i.e., a "natural number line" ordering, where -1 no longer had special meaning. Adding a third entry with order=-10 resulted in -2 first, then 0 and the positive entries, then -10 and -1 last.The end of compareOptions() in AceConfigDialog-3.0.lua looks like this:

So comparing a pair of negative orders doesn't return a meaningful result. Was this by design?

Changing those lines to

makes negative orders behave like Lua coders might expect. The "-1=last" case is still preserved, too. Thoughts?

I rather like -1=last by design. The only thing I'm proposing is to correctly handle more than one negative option, in a way that feels natural to Lua programmers.

If AceConfigDialog does not do this, it's doing something wrong. And judging from your testing where negative numbers randomly end up ANYWHERE, it's simply broken with respect to negative numbers.

I'd say your fix is the right one (without having tested what offsetting things from math.huge actually does :) )

Ace2 was always like this. It seemed like a good idea to have Ace3 do the same when I put together the v3 spec:

Well, currently comparing any two negative numbers returns "true". Which is... yeah, broken. :-)

I was careful to only add math.huge to negative numbers, so we don't have to worry about overflow.

Sorting in numerical order would break things. For a Lua-like ordering we want

0...1...2...3...4...5... all the 100's ...-5...-4...-3...-2...-1

(Remember that 100 is the default order value, so there may be a bunch of those.) Any normal sort is going to screw that up.

Right now you can have

0...1...2...3...4...5... all the 100's ...other positives...-1

but that's all. Changing the negatives into large positives would then allow a normal sort to do everything exactly right.

Well, but technically no matter how large those positives are, it's possible that user also defined elements with equally large 'order' values. In that case, this scheme would still break the expectation.

I always understood the semantics of 'order' to mean that all positives should come before all negatives, and within those halves, things were sorted numerically ascending. So 0 comes first, then other positives in order, then the negatives from smallest (most negative) to largest (least negative, i.e. -1).

Edit: I realize that second paragraph is redundant to your original post, I'm just agreeing with you there. Nonetheless, adding math.huge to negatives is I think not perfectly reliable, because something with order -1 should still come after something with order (math.huge - 1), the former being negative and the latter positive.

I personally seriously doubt that coders would themselves being using order numbers anywhere close to math.huge -- it is <voice mode="patrick stewart SNL sketch">

frickin' HUGE</voice> after all -- but details like this are the kinds of things that I can "bikeshed discussion" about endlessly.We wouldn't?

I mean.. we wouldn't!

*cough*

cd ..\ace3

svn revert

Somebody with commit privs want to actually check in a change then?

I thought the two-line solution was simple enough, but if you're worried that a library user might conceivably manually assign an ordering value of several gazillion, then by all means fix it some other way. :-)