Forums

Default Dictionary

General discussion about Cobra. Releases and general news will also be posted here.
Feel free to ask questions or just say "Hello".

Re: Default Dictionary

Postby Charles » Thu Aug 30, 2012 10:18 pm

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?
Charles
 
Posts: 2515
Location: Los Angeles, CA

Re: Default Dictionary

Postby jaegs » Tue Sep 04, 2012 4:27 pm

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
jaegs
 
Posts: 58

Re: Default Dictionary

Postby Charles » Tue Sep 04, 2012 5:43 pm

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.
Charles
 
Posts: 2515
Location: Los Angeles, CA

Re: Default Dictionary

Postby jaegs » Sun Sep 09, 2012 6:47 pm

I completed testing of BiDictionary. See if you have any comments.
jaegs
 
Posts: 58

Re: Default Dictionary

Postby Charles » Wed Sep 12, 2012 1:09 am

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.
Charles
 
Posts: 2515
Location: Los Angeles, CA

Re: Default Dictionary

Postby jaegs » Wed Sep 12, 2012 11:50 am

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.
jaegs
 
Posts: 58

Previous

Return to Discussion

Who is online

Users browsing this forum: No registered users and 110 guests

cron