Skip to content
This repository has been archived by the owner on Aug 2, 2023. It is now read-only.

Initial open-sourcing commit of the MultiValueDictionary #370

Merged
merged 1 commit into from
Oct 28, 2015
Merged

Initial open-sourcing commit of the MultiValueDictionary #370

merged 1 commit into from
Oct 28, 2015

Conversation

ianhays
Copy link
Contributor

@ianhays ianhays commented Oct 27, 2015

The MultiValueDictionary is an experimental collection that was first released the summer of 2014 as a Nuget package. This commit releases the source code of the MultiValueDictionary tied into .NET Core with the intention of it being considered as an addition to System.Collections.Generic in CoreFX.

  • All code is open sourced from the original package with only changes made to get it functioning. As such, some things will need to be changed to better match the style of CoreFX (e.g. the tests).
  • I based the csproj, project.json, folder structure, and strings.resx heavily on that of System.Collections.Generic in CoreFX so that they may be easily merged in the future. This is why Strings.resx has some strings that aren't used by the MVD
  • Addition of performance tests required an update of BuildTools from 70 to 107.
  • The MVD released earlier had tie-in functions to ILookup like ConvertToLookup. I removed those with the intention of adding them as extension functions in ILookup instead of being in MultiValueDictionary. The reason for this is that System.Collections.Generic shouldn't reference System.Linq but System.Linq can reference System.Collections.Generic.
  • The design decisions around the MVD were made at point where .NET was very different than it is today. Some things might be worth reconsidering now that .NET Core exists.

The MultiValueDictionary is an experimental collection that was first released the summer of 2014 as a Nuget package. This commit releases the source code of the MultiValueDictionary tied into .NET Core with the intention of it being considered as an addition to System.Collections.Generic in CoreFX.

- All code is open sourced from the original package with only changes made to get it functioning. As such, some things will need to be changed to better match the style of CoreFX (e.g. the tests).
- I based the csproj, project.json, folder structure, and strings.resx heavily on that of System.Collections.Generic in CoreFX so that they may be easily merged in the future. This is why Strings.resx has some strings that aren't used by the MVD
- Addition of performance tests required an update of BuildTools from 70 to 107.
- The MVD released earlier had tie-in functions to ILookup like ConvertToLookup. I removed those with the intention of adding them as extension functions in ILookup instead of being in MultiValueDictionary. The reason for this is that System.Collections.Generic shouldn't reference System.Linq but System.Linq can reference System.Collections.Generic.
- The design decisions around the MVD were made at point where .NET was very different than it is today. Some things might be worth reconsidering now that .NET Core exists.
/// The function to construct a new <see cref="ICollection{TValue}"/>
/// </summary>
/// <returns></returns>
private Func<ICollection<TValue>> NewCollectionFactory = () => new List<TValue>();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be static?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The purpose of the NewCollectionFactory is to allow an instance of a MultiValueDictionary to be created that has a custom specified inner collection. I set it here to new List() as the default, but I don't think it should be static. It would make sense that you may want a MultiValueDictionary of Lists as well as a MultiValueDictionary of HashSets in the same program. The static Factories starting on line 357 are an example of when this would be used.

As an aside, if I remember correctly we also discussed removing the public NewCollectionFactory constructors in favor of a bool "AllowRepeatedValues" that would act as a simple function to choose between HashSet and List as the internal structure. It was decided on giving the user more control through the current pattern though.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. Thanks for the explanation. I think it's fine for this initial checkin. But we should discuss at the API review if we think this feature (ability to change the type of the collection) is really needed /used. This feature has a non-trivial cost per instance of the dictionary and I am almost sure most of the instances use the default collection type.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. It's a pretty specific feature for such a general collection and I it may just add unnecessary confusion to what should be a simple decision of "do I want to allow repeated TValues for a given TKey".

@KrzysztofCwalina
Copy link
Member

BTW, please feel free to merge in, just open an issue to discuss the two design points at the API review.

@ianhays
Copy link
Contributor Author

ianhays commented Oct 28, 2015

Thanks @KrzysztofCwalina will do

ianhays pushed a commit that referenced this pull request Oct 28, 2015
Initial open-sourcing commit of the MultiValueDictionary
@ianhays ianhays merged commit dc78f4e into dotnet:master Oct 28, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants