Skip to content
This repository was archived by the owner on Nov 20, 2018. It is now read-only.

[Discussion] Introducing StringValues to replace string[] #382

Closed
Tratcher opened this issue Aug 29, 2015 · 4 comments
Closed

[Discussion] Introducing StringValues to replace string[] #382

Tratcher opened this issue Aug 29, 2015 · 4 comments
Milestone

Comments

@Tratcher
Copy link
Member

A new struct Microsoft.Framework.Primitives.StringValues has been introduced to streamline handling of values that may be empty, single strings, or multiple strings. The value is implicitly convertable to and from string and string[], and also provides helpers like Concat and IsNullOrEmpty.

https://github.com/aspnet/HttpAbstractions/blob/dev/src/Microsoft.Framework.Primitives/StringValues.cs

The type is now used in request and response headers, query values, and form values. As such there have been some API changes in IHeaderDictionary and IReadableStringCollection (used in Form and Query). The indexer is now the primary API for these collections since the presence and plurality are taken care of by StringValues.

Examples:

string combineValue = httpContext.Request.Headers["header1];
if (string.IsNullOrEmpty(combineValue)) // ...
var values = httpContext.Request.Headers["header1"];
if (StringValues.IsNullOrEmpty(values)) // ...
httpContext.Response.Headers["CustomHeader1"] = "singleValue";
httpContext.Response.Headers["CustomHeader2"] =  new[] { "firstValue", "secondValue" };

Also note that some APIs from IHeaderDictionary have been moved to extension methods in the Microsoft.AspNet.Http.Extensions package. See https://github.com/aspnet/HttpAbstractions/blob/dev/src/Microsoft.AspNet.Http.Extensions/HeaderDictionaryExtensions.cs

@Tratcher Tratcher self-assigned this Aug 29, 2015
@Tratcher Tratcher added this to the 1.0.0-beta8 milestone Aug 29, 2015
@Tratcher Tratcher removed their assignment Aug 29, 2015
@atifaziz
Copy link

atifaziz commented Sep 2, 2015

This abstraction is certainly better than having bare string[] everywhere. However, I do have concerns that extreme optimizations like using a struct to avoid any sort of allocation (which is only beneficial when you have a single string) is driving some of the type's implementation and design and could lead to a lot of confusion. That is unless the struct is implemented with full value semantics. For example, one would expect all of the following to compare equal when they don't:

new StringValues("foo").Equals(new StringValues("foo")) // => true
new StringValues("foo").Equals(new StringValues(new[] { "foo" })) // => false
new StringValues(new[] { "foo" }).Equals(new StringValues(new[] { "foo" })) // => false

What's more, if StringValues is initialized with an string array then that array can be modified after, yielding to more confusion.

@Tratcher
Copy link
Member Author

Tratcher commented Sep 2, 2015

@atifaziz See #384

@muratg muratg modified the milestones: Discussions, 1.0.0-beta8 Sep 4, 2015
@jaime-olivares
Copy link

FYI, the two links in the original comments are broken

@muratg
Copy link

muratg commented May 12, 2017

We are closing this issue because no further action is planned for this issue. If you still have any issues or questions, please log a new issue with any additional details that you have.

@muratg muratg closed this as completed May 12, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants