Type inference bug with hashTable and for (??)

[hopscc]

Using the latest src

Code: Select all

      dict = Hashtable()
      dict['a'] = 'z'
      dict['b'] = 'y'
      dict['c'] = 'w'
      assert dict['a'] == 'z'
      print dict.getType
      for de in dict
         print de.key, de.value  #line 11


gives

hashTbl.cobra(11): error: Cannot find a definition for "key" in "de" whose type is "Object?".

on compilation.

I'm thinking theres a type inference bug here since changing the 'for' stmt to

Code: Select all


      for de as DictionaryEntry in dict


compiles and runs works fine, as does explicit casting in the 'for' body

Code: Select all

      dict = Hashtable()
      dict['a'] = 'z'
      dict['b'] = 'y'
      dict['c'] = 'w'
      assert dict['a'] == 'z'
      print dict.getType
      for de in dict
         #print de.key, de.value  #line 11
         de1 as DictionaryEntry = de to DictionaryEntry
         print de1.key, de1.value


[Charles]

Hashtable is pre-generics. The question is whether there is enough type information in Hashtable and its associated classes to infer correctly. Investigating:

In the MSDN docs, I see one GetEnumerator() method for Hashtable:

public virtual IDictionaryEnumerator GetEnumerator()

Unlike the CharEnumerator for Strings, the IDictionaryEnumerator does not provide a strongly typed Current property. Instead it has a different property called Entry. No consistency = poor design.

Anyway, we could enhance Cobra to check for a strongly typed Current (in other words, one that does not return System.Object) and then check for an Entry property. The relevant compiler code is "get innerType" in Boxes.cobra which currently has a hack for String instead of following the GetEnumerator --> Current trail to find that "char" is the "inner type" of a String.

So the hack could be replaced by looking at GetEnumerator's return type and then checking for the strongly typed Current and then the Entry property.

Or maybe this is like .NET indexers, where the name is irrelevant and an attribute dictates what the strongly typed "current" property is. I suppose some reflecting using .NET Reflector or some such could determine that.

I would accept a patch for this. I won't pursue it myself as I almost never use non-generic collections and I have other things on my plate.

[hopscc]

OK I'll open a ticket against it.

I only found this when making a test case for the non generic multi-arg 'for' assignment for dicts so this probably means that
supporting multiarg key,value from Enumerators generating DictionaryEntries (in 'for') is going to be somewhat further off than it already was looking

[hopscc]

Patch available on ticket.
Also fixes multiarg assignment from hashTable iterator in for-stmt so tests updated accordingly.

[Charles]

Applied.