The differences in dictionary behavior between frameworks because of this SHOULD be documented. In the old Framewaok Docs the behavior of numeric type keys because of datatype should be explicitly mentioned and explained, and in the docs for the new framework, the difference from the old framework behavior should be mentioned
You should file a bug report about this.
The problem is not wether a bug report is filed or not, the problem is that a change in behaviour should never happen without adequate documentation. How is it even possible that this was not documented? Has the one making the change not realized the consequences? Has he realized the consequences but not documented them? Has he documented them but it has not been communicated?
Kudos to Kem for finding this, but Xojo needs to tighten up procedures to prevent it from happening again.
It might help to clarify why I think this is an issue that should be fixed in the framework if I describe the circumstances that bit me.
I have a class with a property, id as integer. In most cases, id is zero or more, but in one special case, it is set to -1.
I create a Dictionary using id as a key, then when looking for that special case, use code that looks like this:
v = d.Value( -1 )When compiling for either 32-bit or 64-bit, that works fine since the static is cast to the native type, i.e., the same as if I had assigned it to an integer variable first.
Later I decided I needed more room so I changed the declaration to id as Int64. Now the same code breaks, but only for the special value of -1.
Given this, my preferred solution is for the classic Dictionary to work like the new Dictionary and treat negative integers the same regardless of integer type. An acceptable second solution would be to have it fail to match when the lookup value type is different than the key type, regardless of the difference. Int64 has to be looked up by Int64, Int32 by Int32, etc. At least that way a failure will be noticed immediately.
I wouldn’t call this a change because Auto and Xojo.Core.Dictionary are completely new types. The behavior in existing code was unchanged.
Not to put words in his mouth, but I read “change” as “difference”, i.e., the classic and new frameworks handle this differently, so switching from one to the other will “change” behavior.
The old dictionary handles it a “surprising” way where an int32 key with a value of -1 <> int64 key with a value of -1
(that was Kem’s initial post on this thread)
The new dictionary treats those as “equivalent”
The old dictionary had a few other quirks like the one I pointed out with string keys that the new one does not
IMHO this make the new dictionary behave like people expect where -1 = -1 and “123” = “123” when comparing keys
FWIW the IDE uses a number of dictionaries and in the code around many uses there is a code to convert string keys to the same encoding (UTF8) or to convert integer keys to the same type(usually int64)
a custom subclass of dictionary that makes sure keys are all “integers” (or int64’s or whatever) should suffice
Exactly. And the issue is that these changes have not been communicated. We don’t need a bug report for this as Joe suggested as this is not a bug - it is intended behaviour. But we need Xojo to properly document the changes. And if they don’t document the changes, then why not? Where did that fail?
It simply cannot be that you change the underlying behaviour but don’t communicate that to the users. What other surprises might be in the new framework that aren’t documented?
I think Joe meant a bug report against the documentation. That said, it IS a new language feature. Much of the new framework is different from the classic. You shouldn’t expect them to be identical.
Certainly not to reproduce old weird behavior
That -1 <> -1 because the type is different is surprising in the old framework
That “123” <> “123” because the encoding is different is surprising - that one has been reported at least a couple times in feedback & here on the forums
That the new framework doesn’t have those oddities is a good thing
There’s fewer surprises
Yep. Filing a bug report is the way to ensure its seen by the right people.
may that have to do with the IndexOf Method for Variant Arrays being broken? <https://xojo.com/issue/43433>
I just created such a Dictionary subclass and checked its speed adding 1000 keys. These are the total times for three runs:
860 microsecs adding to classic Dictionary
1,735 microsecs adding to normalized
2,297 microsecs adding to new framework
862 microsecs adding to classic Dictionary
1,800 microsecs adding to normalized
2,396 microsecs adding to new framework
771 microsecs adding to classic Dictionary
1,699 microsecs adding to normalized
2,308 microsecs adding to new frameworkUsing a subclass takes almost twice as long.
Fast and wrong is still wrong 
The subclass would at least behave in accordance with the expectations you had when you started the thread
At this point I’d have my doubts the classic dictionary would be altered hence Joe’s encouragement to file a report against the documentation
Yeah, that’s the signal I got too.