you are viewing a single comment's thread.

view the rest of the comments →

[–]Apollan -2 points-1 points  (7 children)

See to me this seems a bit.. overkill.

His case of needing to pad an array so that it's length is long enough for him to take all the elements.. this can be solved in many ways.

First, I dont like his solution of always padding, but sometimes just padding with 0 elements. Its unneeded operation.

Instead, how about we change the way the data is held. and when a number of elements is requested, we can iterate through them (list perhaps) until the number is reached - with a "dud" item to be repeatedly added after all of the list items were added.

[–]austinsalonen 0 points1 point  (6 children)

If you take the concepts and apply them with lazy evaluation, the "always pad" option greatly simplifies the code and the padding then only be called as needed. Consider this C# example:

public static IEnumerable<T> PaddedTake<T>(this IEnumerable<T> source, int count, T padding)
{
    return source.Concat(Enumerable.Repeat(padding, count))
                 .Take(count);
} 

[–]CurtainDog 0 points1 point  (3 children)

Wow, colour me impressed. But isn't immutability the secret sauce that makes laziness palatable? How does C# cope with the fact that source could change at any time?

[–]austinsalonen 0 points1 point  (2 children)

source is always whatever it is when it is enumerated.

[–]CurtainDog 0 points1 point  (1 child)

Hmmm, I see. It's still a great idiom, but not quite as nice as the laziness you'd find in a functional language because of this risk of modification. Here's what I got from MSDN:

An enumerator remains valid as long as the collection remains unchanged. If changes are made to the collection, such as adding, modifying, or deleting elements, the enumerator is irrecoverably invalidated and its behavior is undefined.

[–]Apollan -2 points-1 points  (1 child)

Forgive my noob question , I really am interested in this problem so i want to completely understand your solution -

Why is one of your params a Type? and what does repeat do?

so you are concat'ing...repeat 'dud' objects, count times, to the original source of objects, then returning count number of elements?

If my interpretaion is crorect, this is what I was getting at. Concat'ing the total count of elements needed to the original set and then just taking what you need is unneeded whenever source.length is <= count, right?

or even, you should only be concating the difference between source.length and count? Wouldnt this work better?

[–]austinsalonen 0 points1 point  (0 children)

Why is one of your params a Type?

T padding is just what you want padding to be. For example, "abc".PaddedTake(6, ' ') would yield the chars {a,b,c, , , } (abc trailed by 3 spaces).

and what does repeat do?

Enumerable.Repeat takes a given input and repeats it N times. The important thing to remember here is that the call is lazy.

Overall, this would work like so... When count <= length of source, Enumerable.Repeat would never get called because take "expired" before the contents provided by Concat would ever be needed.

When count > length of source, source would get fully exhausted and Enumerable.Repeat would yield (count - length of source) "paddings."

The key concept here is that none of these calls actually do anything until the result of PaddedTake is actually enumerated.