DA.GetDataList() Why not offer IEnumerable<T> as argument?

Hi Guys,

I am curious to know why DA.GetDataList() does ton provide an IEnumerable<T> so the user is not only limited to a List<T>? Note that converting an array using ToList() will not work as it will create a new memory alloc for the data and DA.GetDataList() will not operate on the original collection producing a good old null.

My wild guess is, that the method requires an indexer.

But on a side note, do you experience significant performance losses due to the conversions from array to list and back? Or is it just bothering you to write 2 more lines of code?

Well I guess it depends on the particular situation. Also IEnumerable<T> has ElementAt(index) In my opinion having that interface as argument is always more flexible for the programmer. It is implemented by List<T> and [] anyways

Is there something wrong with that or is it just binary purism?

Here’s my bet.
GH needs to clone the data in each parameter to separate the instances or break the references with the previous state, that is, if the current component modifies the data, the previous component will not see the data changed (which would happen if it was the same reference, the same memory). This allows to work with the data sequence instead of the last state of the data. And to clone a class, it has to be able to be constructed, interfaces or abstract classes cannot.

On the other hand, System.Linq methods are not appropriate for a system like this because it is based on promises of operations instead of instantaneous operations. When you do, for example:
IEnumerable revFirstFive = myEnum.Take(0, 5).Reverse();
you are not saying give me the first five elements and reverse the order, what you are really saying is, when the collection is iterated, as in a loop, when it is called, when the data is to be read, give me the first five elements and reverse the order. You postpone the operations for when they are necessary, if you don’t read the collection they will never be carried out (I’m not 100% sure of this, but it have sense to me bc several times I fix weird bugs of things doesn’t happen just calling .ToArray() or .ToList(), then they do). Then in a system where you have to synchronize several lists, and even worst, lists of lists (datatree), this opens the door to a lot of not very obvious failures. When you call ElementAt() or Count() methods, all those operations (take and reverse in our example) are performed to give you the expected answer, but they are not fields of the object as it happens in List< T> or T array, because they are extension methods. In fact, if I am right, if you call ElementAt(i) in a loop, what you are doing is starting the internal iterator from 0 until i at each step of the loop, so it is not good practice.

I think this is enough to justify the sacrifice, it just doesn’t compensate for adding this complexity to the system for the little you earn. Why complicate it by figuring out what’s coming if you can restrict a collection that is good for almost every situation.

1 Like

This is a very good point

This seems fishy though, in my understaning. Behind the scenes when you access an element from a collection by indexing [] what is happening is that those brackets are a dereferencing operator, they get the value of the memory address in the specified location. So I think this is juts a universal behavior in programming, why would it be implemented any different for IEnumerable<T>?

But anyways, thanks for your input and for taking the time to write an elaborate answer, to a fairly abstract and open ended question.