Default Dictionary

[Charles]

No, if I recall correctly the problem was thta Func<of> is not found in .NET 2.0, so this can cause problems during installation. And we don't yet have conditional compilation.

Why don't you put these in a library on bitbucket or github where they can be developed and mature. After 0.9, we'll either add conditional compilation or drop .NET 2 support and by then these classes will be mature and then we can add them to the Cobra libraries.

Sound like a plan?

[jaegs]

OK. Sounds good.

Here is the BiDictionary, and HeapQueue. Of course, I still need to test it out. These classes don't use Func<> so they should be compatible with older versions of .NET

[Charles]

I'll check them out later this week. I don't see any problem with using Func<> btw. Over time .NET 4 will increase in popularity while the earlier versions decrease.

[jaegs]

I completed testing of BiDictionary. See if you have any comments.

[Charles]

This looks pretty good. Some feedback and observations:

-- It would be cool if the class doc string gave some applications for a BiDictionary and/or some URLs that discuss it.

-- The doc string for the indexer (pro [key...]) should probably start out with something like "When assigning a value to a key, ..." since the docs there don't apply to the getter; only the setter.

-- In .NET collections, a method called .inverse would change the object. You may wish to rename this to something like .inverseView to make it obvious from the method name that any modifications to what is returned will modify the original as well.

-- It's interesting that there can be no .inverse method that changes the object in place due to the separate generic types TKey and TValue. This speaks to limitations of generics rather than a problem with this class or Cobra (whose generics ride on top of .NET).

-- Looking at .add: Contracts on public methods should use public members (.forward, .reverse) rather than protected or private (_forward, _reverse). Or if those things are not available, then the contract should be expressed in some other way, possibly with the addition of public methods (.containsKey, .containsValue).

# .
        def add(key as TKey, val as TValue)
            require
                not _forward.containsKey(key)
                not _reverse.containsKey(val)
            body
                _forward[key] = val
                _reverse[val] = key
# --->
        def add(key as TKey, val as TValue)
            require
                not .containsKey(key)
                not .containsValue(val)
            body
                _forward[key] = val
                _reverse[val] = key

-- It's interesting that this typecast is needed:

# .
        def contains(kvp as KeyValuePair<of TKey, TValue>) as bool
            return (_forward to IDictionary<of TKey, TValue>).contains(kvp)

Without it, the error is:

BiDictionary.cobra(131): error: Type "System.Collections.Generic.Dictionary<TKey,TValue>" does not contain a definition for "Contains" and no extension method "Contains" of type "System.Collections.Generic.Dictionary<TKey,TValue>" could be found (are you missing a using directive or an assembly reference?) (C#)

... which actually comes from C#. Do I need to look into this or am I just missing something here?

-- I just wanted to note that the two extension methods here are for IDictionary<> and therefore also for BiDictionary<>:
http://cobra-language.com/trac/cobra/br ... nary.cobra

Note that .clone expects the type to have an initializer that takes an object of the same type and make a copy. This is fairly standard .NET collection thing which you will find with List, Dictionary and HashSet.

This requires BiDictionary to be tweaked.

-- I prefer to "chain the initializers" so that code duplication is avoided and subclasses have one clear base initializer to call (or at least as few as reasonable). Usually that initializer is the one that takes the most parameters. Calling a fellow initializer is done with ".init(args)".

I learned this approach from Objective-C/NeXTstep. See https://www.google.com/search?q=chain+initializers

-- The unit tests could hit upon all the public properties and methods instead of just some.

[jaegs]

Thanks for the suggestions. I'll start working on them.

Do I need to look into this or am I just missing something here?

Yes, I'm not totally sure why I needed to do cast other then to make the code compile. Probably worthwhile looking at it further.