Correct, but FieldCollection is a light-weight wrapper around an array. The
List<T> is just a wrapper around an array (much like the non-generic, original
ArrayList) that grows an array when capacity is reached. The Dictionary<T> I
create for fast indexing (when primary keys are defined) is only another array
of lists, in which the key is hashed using IComparer<TKey>.GetHashCode(TKey) so
only another 4 bytes there plus whatever is necessary for the key and value
references (at least 4 bytes). Given that we don't have many tables even close
to the 32 max field count of MSI (and a recent change I submitted increased
that for unreal tables, but even that one has only about 33 or 34 fields) we
may not need the addition of hashing. Even the older HybridDictionary exists to
use lists until some threshold (we could measure, or just use the research
behind HybridDictionary which switches to a dictionary after 9 items). It,
unfortunately, is not generic but since we're dealing with reference types for
key and value that may not matter much (or we just write our own implementation
- should be easy since we're dealing with fixed field counts at runtime).
Generic collections are fine if they work as-is, but when you need / want to
extend them with additional features derivatives and containerization give you
that flexibility without breaking call-compatibility. In my case, I wanted a
read-only collection. A generic type was added in 4.5, but we're basing on 4.0
so I wrote my own using the interfaces I had to work with (by both hiding them
behind explicit implementations and throwing exceptions when trying to use
them). They implement all the same interfaces as their counterparts and pretty
much work the same way so I also don't see the harm. You'll note that the
ReadOnlyKeyedCollection<TKey, TValue> uses List<T> and Dictionary<TKey, TValue>
and looks a lot like - intentionally - KeyedCollection<TKey, TValue> which has
to be derived but cuts down on the amount of code you have to write for
callers. Instead of passing in both Row.GetPrimaryKey() and the Row, you just
pass the Row. Also, the class does the duplication check so you don't have to
(if you don't need to know). The built-in classes will simply throw.
So I think deriving / containing the base classes is a good way to reduce the
amount of code callers have to worry about and makes for a safer code base.
Heath Stewart
Software Design Engineer
Visual Studio, Microsoft
http://blogs.msdn.com/heaths
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://p.sf.net/sfu/Zoho
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
