Question

My question is about naming, design, and implementation choices. I can see myself going in two different directions with how to solve an issue and I’m interested to see where others who may have come across similar concerns would handle the issue. It’s part aesthetics, part function.

A little background on the code… I created a type called ISlice<T> that provides a reference into a section of a source of items which can be a collection (e.g. array, list) or a string. The core support comes from a few implementation classes that support fast indexing using the Begin and End markers for the slice to get the item from the original source. The purpose is to provide slicing capabilities similar to what the Go language provides while using Python style indexing (i.e. both positive and negative indexes are supported).

To make creating slices (instances of ISlice<T>) easier and more “fluent”, I created a set of extension methods. For example:

static public ISlice<T> Slice<T>(this IList<T> source, int begin, int end)
{
  return new ListSlice<T>(source, begin, end);
}

static public ISlice<char> Slice(this string source, int begin, int end)
{
  return new StringSlice(source, begin, end);
}

There are others, such as providing optional begin/end parameters, but the above will suffice for where I’m going with this.

These routines work well and make it easy to slice up a collection or a string. What I also need is way to take a slice and create a copy of it as an array, a list, or a string. That’s where things get “interesting”. Originally, I thought I’d need to create ToArray, ToList extension methods, but then remembered that the LINQ variants perform optimizations if your collection implements ICollection<T>. In my case, ISlice<T>, does inherits from it, though much to my chagrin as I dislike throwing NotSupportedExceptions from methods like Add. Regardless, I get those for free. Great.

What about converting back into a string as there’s no built-in support for converting an IEnumerable<char> easily back into a string? Closest thing I found is one of the string.Concat overloads, but it would not handle chars as efficiently as it could. Just as important from a design stand point is that it doesn’t jump out as a “conversion” routine.

The first thought was to create a ToString extension method, but that doesn’t work as ToString is an instance method which means it trumps extension methods and would never be called. I could override ToString, but the behavior would be inconsistent as ListSlice<T> would need to special case its ToString for times where T is a char. I don’t like that as the ToString will give something useful when the type parameter is a char, but the class name in other cases. Also, if there are other slice types created in the future I’d have to create a common base class to ensure the same behavior or each class would have to implement this same check. An extension method on the interface would handle that much more elegantly.

The extension method leads me to a naming convention issue. The obvious is to use ToString, but as stated earlier it’s not allowed. I could name it something different, but what? ToNewString? NewString? CreateString? Something in the To-family of methods would let it fall in with the ToArray/ToList routines, but ToNewString sticks out as being ‘odd’ when seen in the intellisense and code editor. NewString/CreateString are not as discoverable as you’d have to know to look for them. It doesn’t fit the “conversion method” pattern that the To-family methods provide.

Go with overriding ToString and accept the inconsistent behavior hardcoded into the ListSlice<T> implementation and other implementations? Go with the more flexible, but potentially more poorly named extension method route? Is there a third option I haven’t considered?

My gut tells me to go with the ToString despite my reservations, though, it also occurred to me… Would you even consider ToString giving you a useful output on a collection/enumerable type? Would that violate the principle of least surprise?

Update

Most implementations of slicing operations provide a copy, albeit a subset, of the data from whatever source was used for the slice. This is perfectly acceptable in most use cases and leaves for a clean API as you can simply return the same data type back. If you slice a list, you return a list containing only the items in the range specified in the slice. If you slice a string, you return a string. And so on.

The slicing operations I’m describing above are solving an issue when working with constraints which make this behavior undesirable. For example, if you work with large data sets, the slice operations would lead to unnecessary additional memory allocations not to mention the performance impact of copying the data. This is especially true if the slices will have further processing done on them before getting to your final results. So, the goal of the slice implementation is to have references into larger data sets to avoid making unnecessary copies of the information until it becomes beneficial to do so.

The catch is that at the end of the processing the desire to turn the slice-based processed data back into a more API and .NET friendly type like lists, arrays, and strings. It makes the data easier to pass into other APIs. It also allows you to discard the slices, thus, also the large data set the slices referenced.

Answer 1

Would you even consider ToString giving you a useful output on a collection/enumerable type? Would that violate the principle of least surprise?

No, and yes. That would be completely unexpected behavior, since it would behave differently than every other collection type.

As for this:

What about converting back into a string as there’s no built-in support for converting an IEnumerable>char< easily back into a string?

Personally, I would just use the string constructor taking an array:

string result = new string(mySlice.ToArray());

This is explicit, understood, and expected – I expect to create a new string by passing an object to a constructor.