String.Split and and some more robust behavior [Kit George]

re: String.Split and and some more robust behavior [Kit George]

AndrewSeven — Tue, 15 Feb 2005 02:10:00 GMT

Nice,

I'm glad to see splitting on strings.

I was wondering how the overloads would change to keep the usage unambiguous.

I had a look at the doc and I'm curious why String.Split (String[], Boolean) is there as obsolete. Changes from ealier V2.0 I guess.

re: String.Split and and some more robust behavior [Kit George]

Kit George [Msft] — Tue, 15 Feb 2005 02:13:00 GMT

The calls are typed differently so there should be no ambiguity issues. And yup, the bool was how we decided to do this in an earlier iteration of V2.0, but due to design guideline changes (which indicate that people far prefer named values when the boolean values of 'true' and 'false' are impossible to interpret. It makes the code easier to read), which indicated we should use an enum instead.

re: String.Split and and some more robust behavior [Kit George]

Steve Tibbett — Tue, 15 Feb 2005 16:30:00 GMT

Is there a simple way of parsing out csv with Whidbey? String.Split doesn't work since some strings may be quoted..

Or is there a way of handling that now?

re: String.Split and and some more robust behavior [Kit George]

Kit George [Msft] — Wed, 16 Feb 2005 05:41:00 GMT

Steve, the short answer is no, but we do have a feature request for that for Orcas.

re: String.Split and and some more robust behavior [Kit George]

Jared Tullis — Fri, 18 Feb 2005 00:43:00 GMT

Is that feature request in the feedback center so we devs can vote on it? I wholeheartedly second it. I also agree with the readability afforded with the enum vs. bool, this way you can in the future include StringSplitOptions.ParseAsQuoted :)

Why I love the .NET Framework.

notgartner.com: Mitch Denny's Blog — Sat, 19 Feb 2005 08:30:00 GMT

re: String.Split and and some more robust behavior [Kit George]

jaybaz [MS] — Sun, 20 Feb 2005 10:54:00 GMT

Kit,

Why not make it "String.SplitOptions" - make the enum a type nested in String? For the price of only a single character, you avoid poluting the System namespace.

re: String.Split and and some more robust behavior [Kit George]

Kit George [msft] — Sun, 20 Feb 2005 11:46:00 GMT

Jared: you're right on the money with regards to being able to expand the option in the future, for exactly the kind of behavior you describe. But the primary reason is readability.

JayBaz: We tend to avoid nested types when it comes down to actually using them. It tends to be more confusing than it is beneficial. We do however, completely agree with trying to prevent adding an ongoing number of things to the System namespace, and we'll be locking down on that moving forward.