Snap icon indicating copy to clipboard operation
Snap copied to clipboard

Dictionaries don't behave like lists

Open brianharvey opened this issue 11 months ago • 3 comments

So, when y'all added dictionaries, you took pains (perhaps to make me happy?) to make them look like regular lists, merely extending the domain of ITEM. But when you try to mutate a dictionary, the results don't match what you'd expect from how lists behave. The worst case is deaeefb3c5711d0974604ef39eb84220fbdfe9ef which replaces instead of inserting. I thought maybe that's because the item to be inserted didn't include a key, but this doesn't work either: help-test script pic

That's the worst case because it loses information, but there are other examples in which it's just the order of items in the list that's lost: 3f0f8ef22102914a66ce212f9767f6a016726c2d

See more at https://forum.snap.berkeley.edu/t/replace-block-with-paired-values/16255

You'll say that this behavior doesn't matter for the use cases for dictionaries you have in mind, but I think if they look like lists, they should behave like lists.

brianharvey avatar Mar 09 '24 20:03 brianharvey

Sigh. We talked about this in extenso when we first designed dicts a long time ago, and you were cool about it then.

jmoenig avatar Mar 09 '24 21:03 jmoenig

I think I must not have understood that INSERT would actually do REPLACE.

brianharvey avatar Mar 09 '24 21:03 brianharvey

Both do the same - only - in the case of non-numerical indices

jmoenig avatar Mar 09 '24 21:03 jmoenig