const oddities in Bug Reports

ID:706546
 
Apr 26 2012, 2:16 am (Edited on Apr 26 2012, 2:46 am)
BYOND Version:494
Operating System:Windows Vista Home Basic
Web Browser:Chrome 18.0.1025.162
Applies to:Dream Maker
Status: Deferred
This issue may be low priority or very difficult to fix, and has been put on the back burner for the time being.
Descriptive Problem Summary:

Numbered Steps to Reproduce Problem:
Using consts in multi-dimensional lists causes the const's variable name to be read instead of the value. For example, if you have a const named DUD for "Dudley", if read from a normal list, it will be read as "Dudley". But if that list is for example var/list/l=list(DUD=1), it will be read as 'DUD'.
Code Snippet (if applicable) to Reproduce Problem:
var
    const
        E_FIRE="Fire"
        E_ICE="Ice"

var/list/l1=list(E_FIRE,E_ICE)
var/list/l2=list(E_FIRE=1,E_ICE=1)
var/list/l3=list("1"=E_FIRE,"2"=E_ICE)

mob
    verb
        test_list()
            usr << "Testing l1."
            for(var/X in l1)
                usr << X // Will show the actual value of const.
            usr << "Testing l2."
            for(var/X in l2)
                usr << X // Will wrongly show the const itself, ie E_FIRE
            usr << "Testing l3."
            for(var/X in l3)
                usr << l3[X] // Will show the actual value of const.


This very simple example will show you the problem in any project with a text output.

Expected Results:
consts show their value instead of variable name in all types of lists.

Actual Results:
const variable name is shown in multi-dimensional lists instead.

Does the problem occur:
Every time? Or how often? Yes.
In other games? n/a
In other user accounts? n/a
On other computers? n/a

When does the problem NOT occur?
It seems that if you use the const as a value in the list instead of the index (see l3), it'll display fine. However it doesn't if used as the index of a list (see l2).

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)

Yes, I remember using consts in multi-dimensional lists before, and experiencing issues. I couldn't identify the source at the time, so I didn't report it, but having found it, I've decided to post this.

Workarounds:
#1 Apr 26 2012, 2:48 am (Edited on Apr 26 2012, 4:27 pm)
That's how associative lists are supposed to work.
#2 Apr 26 2012, 2:53 am
I swear I've seen a similar bug report to this, but I can't find it for the life of me. I'm pretty sure it was on the bug tracker (and not the old forums), and maybe posted by Android Data (but I can't find it in the search, so maybe not!).

Interestingly, I think it was for a very similar situation (some sort of elemental constants)

I'm pretty sure Lummox JR responded to it, so he'll probably remember where it stands (I would guess Deferred)
#3 Apr 26 2012, 3:05 am
It is actually a bug (a very long-standing one) that can't be fixed without digging deep into the core of the system; where Lummox is uncomfortable making changes. It's best to leave it alone I imagine, lest something else get broken trying to fix it.
#4 Apr 26 2012, 11:14 am
I'm not certain this actually is a bug. This behavior is quite old, and I can see reasons it might have been added intentionally.
#5 Apr 27 2012, 2:40 am
I suspect without a more explicit notion of enumerated values, this kind of const behaviour comes across a pretty unintuitive, as it gives const two functions, one of being a modifier regarding writability (total not a word) of the field, and the other being this kind of symbolic constant behaviour.

The latter offers itself up quite well as impromptu enumerations if you used integer values, and the former (although pre-requisite for static enumeration) isn't really only used for static enumeration.

So if you reckon it's intended behaviour, it may be best that this bug is closed, and a feature request is opened up to devise a somewhat more clear static enumeration type/mechanism, and simplify const's behaviour.
#6 Apr 27 2012, 4:50 am
Sorry if it's not a bug, the behavior seemed inconsistent so I didn't think it was intentional. If it's that way for a reason/would be too difficult to fix, it's fine - there are ways to work around it (albeit a slight inconvenience). Just wanted to make people aware of it.
#7 Apr 28 2012, 5:00 am
This will work:

var/list/l2 = list("[E_FIRE]" = 1, "[E_ICE]" = 1)

The big problem here is that there's not any compile-time checking of the values you're typing. You could do this:

var/list/l2 = list(EFIRE = 1, EICE = 1)

And it'd compile, even though the constants are named E_FIRE and E_ICE. The behavior is undesirable but it's unlikely it'd be accidental. I don't think it's a bug but having undesirable things that were done intentionally is even worse than a bug.
#8 Apr 28 2012, 6:39 am
@Forum_account: That's documented and intentional behavior.

From the reference entry for List association:

var/list/lst = list("player" = "James Byond", "score" = 2000)


When the index values happen to be text strings that satisfy all the requirements for variable names, this may also be written in a convenient short-hand:

var/list/lst = list(player = "James Byond", score = 2000)


In other words, this is exactly the same syntax as for named arguments.

Which would also explain the OP in the first place, since it probably doesn't have local or global consts taking precedence for names.
#9 Apr 28 2012, 8:38 am
In response to Audeuro (#8)
I must have read that reference entry a hundred times, and I've never noticed that.

I guess you learn something new every day.
#10 Apr 29 2012, 5:03 pm
In response to Audeuro (#8)
Audeuro wrote:
@Forum_account: That's documented and intentional behavior.

That makes it even worse. If the IDE showed the constant name in a different font color it'd be more clear what was happening.

This syntax will also work:

var/list/l2 = list(global.E_FIRE = 1, global.E_ICE = 2)
#11 Jul 2 2012, 4:32 pm
I kind of have to agree that this behavior is undesirable where consts are concerned, but I'm not sure there's a good solution or that one can be found without breaking existing code. I'm also not sure how this compiles in and if it would need to be resolved at the compiler end of things or not. Originally I was inclined to mark this as a non-bug but I think the const argument is persuasive, so I think the best choice is to leave it marked as a bug, but defer it.
#12 Jul 2 2012, 4:32 pm
Lummox JR changed status to 'Deferred'