Return to Answer

###There is no 0 and 1 answer

X likes to execute an IEnumerable as soon as possible, hence why X is doing it inside of the method.

Whereas

Y is thinking that if you wait until the object is actually needed, using differed execution, you’re eliminating wasted objects in the memory.

They are both wrong. The answer isn't digital, this is, there is no 0 or 1 answer. It depends. Sometimes you must execute a collection and return a non-IEnumerable.

###Materialize when working with databases

Such a case would be querying a database. In this scenario you'd open a database connection (or create a context if it's some ORM) and dispose it at the end. If you don't execute it with ToList or ToArray etc. you won't be able to do it later. The runtime would wrap your enumerator with an anonymous type containing the context but when the execution leaves the method, the context gets disposed and it'll throw an excepiton the moment you try to get the data. In this situation you should return a non-IEnumerable type.

The reason the return type shouldn't be an IEnumerable in this case is that IEnumerable tells me that the return type is lazy so if I wanted to use it multiple times I'd call ToList myslef (again) to get the result which would unnecessrily enumerate the collection again.

So, the bottom line is: if you don't have to materialize the result (because you won't be able to get it later when the service/provider is disposed etc), don't do it but be consistent with the API (return types).

When the result value it's materialized I expect you to communicate this fact clearly by using ICollection, IList or anything else but IEnumerable.

###Materialize for easier debugging when calling resources

As far as your code is concerned you call a web-service there

RestHelper.PostJsonAsync(..)

So you should ask yourself: Is it ok to be done multiple times if someone else uses Any and then starts enumerating it again or is better to prevent such situations (for whatever reason)?

I would use IList here for one more reason: it's quite difficult to debug lazy code that is calling web-services, databases or other resources. When something goes wrong here you'll be having a lot of fun.

###Consider materialized parameters

The same priciples apply to parameters. In your example you execute skus multiple times: with Any and with the foreach loop.

Here, I'd requested an ICollection or an IList to tell the caller: Look out! I'll be using your collection more then once (so you might consider materializing it for better performance before givit it to me).

There is no 0 and 1 answer

X likes to execute an IEnumerable as soon as possible, hence why X is doing it inside of the method.

Whereas

Y is thinking that if you wait until the object is actually needed, using differed execution, you’re eliminating wasted objects in the memory.

They are both wrong. The answer isn't digital, this is, there is no 0 or 1 answer. It depends. Sometimes you must execute a collection and return a non-IEnumerable.

Materialize when working with databases

Such a case would be querying a database. In this scenario you'd open a database connection (or create a context if it's some ORM) and dispose it at the end. If you don't execute it with ToList or ToArray etc. you won't be able to do it later. The runtime would wrap your enumerator with an anonymous type containing the context but when the execution leaves the method, the context gets disposed and it'll throw an excepiton the moment you try to get the data. In this situation you should return a non-IEnumerable type.

The reason the return type shouldn't be an IEnumerable in this case is that IEnumerable tells me that the return type is lazy so if I wanted to use it multiple times I'd call ToList myslef (again) to get the result which would unnecessrily enumerate the collection again.

So, the bottom line is: if you don't have to materialize the result (because you won't be able to get it later when the service/provider is disposed etc), don't do it but be consistent with the API (return types).

When the result value it's materialized I expect you to communicate this fact clearly by using ICollection, IList or anything else but IEnumerable.

Materialize for easier debugging when calling resources

As far as your code is concerned you call a web-service there

RestHelper.PostJsonAsync(..)

So you should ask yourself: Is it ok to be done multiple times if someone else uses Any and then starts enumerating it again or is better to prevent such situations (for whatever reason)?

I would use IList here for one more reason: it's quite difficult to debug lazy code that is calling web-services, databases or other resources. When something goes wrong here you'll be having a lot of fun.

Consider materialized parameters

The same priciples apply to parameters. In your example you execute skus multiple times: with Any and with the foreach loop.

Here, I'd requested an ICollection or an IList to tell the caller: Look out! I'll be using your collection more then once (so you might consider materializing it for better performance before givit it to me).

###There is no 0 and 1 answer

X likes to execute an IEnumerable as soon as possible, hence why X is doing it inside of the method.

Whereas

Y is thinking that if you wait until the object is actually needed, using differed execution, you’re eliminating wasted objects in the memory.

They are both wrong. The answer isn't digital, this is, there is no 0 or 1 answer. It depends. Sometimes you must execute a collection and return a non-IEnumerable.

###Materialize when working with dabases

Such a case would be querying a database. In this scenario you'd open a database connection (or create a context if it's some ORM) and dispose it at the end. If you don't execute it with ToList or ToArray etc. you won't be able to do it later. The runtime would wrap your enumerator with an anonymous type containing the context but when the execution leaves the method, the context gets disposed and it'll throw an excepiton the moment you try to get the data. In this situation you should return a non-IEnumerable type.

The reason the return type shouldn't be an IEnumerable in this case is that IEnumerable tells me that the return type is lazy so if I wanted to use it multiple times I'd call ToList myslef (again) to get the result which would unnecessrily enumerate the collection again.

So, the bottom line is: if you don't have to materialize the result (because you won't be able to get it later when the service/provider is disposed etc), don't do it but be consistent with the API (return types).

When the result value it's materialized I expect you to communicate this fact clearly by using ICollection, IList or anything else but IEnumerable.

###Materialize for easier debugging when calling resources

As far as your code is concerned you call a web-service there

RestHelper.PostJsonAsync(..)

So you should ask yourself: Is it ok to be done multiple times if someone else uses Any and then starts enumerating it again or is better to prevent such situations (for whatever reason)?

I would use IList here for one more reason: it's quite difficult to debug lazy code that is calling web-services, databases or other resources. When something goes wrong here you'll be having a lot of fun.

###Consider materialized parameters

The same priciples apply to parameters. In your example you execute skus multiple times: with Any and with the foreach loop.

Here, I'd requested an ICollection or an IList to tell the caller: Look out! I'll be using your collection more then once (so you might consider materializing it for better performance before givit it to me).

###There is no 0 and 1 answer

X likes to execute an IEnumerable as soon as possible, hence why X is doing it inside of the method.

Whereas

Y is thinking that if you wait until the object is actually needed, using differed execution, you’re eliminating wasted objects in the memory.

They are both wrong. The answer isn't digital, this is, there is no 0 or 1 answer. It depends. Sometimes you must execute a collection and return a non-IEnumerable.

###Materialize when working with databases

Such a case would be querying a database. In this scenario you'd open a database connection (or create a context if it's some ORM) and dispose it at the end. If you don't execute it with ToList or ToArray etc. you won't be able to do it later. The runtime would wrap your enumerator with an anonymous type containing the context but when the execution leaves the method, the context gets disposed and it'll throw an excepiton the moment you try to get the data. In this situation you should return a non-IEnumerable type.

The reason the return type shouldn't be an IEnumerable in this case is that IEnumerable tells me that the return type is lazy so if I wanted to use it multiple times I'd call ToList myslef (again) to get the result which would unnecessrily enumerate the collection again.

So, the bottom line is: if you don't have to materialize the result (because you won't be able to get it later when the service/provider is disposed etc), don't do it but be consistent with the API (return types).

When the result value it's materialized I expect you to communicate this fact clearly by using ICollection, IList or anything else but IEnumerable.

###Materialize for easier debugging when calling resources

As far as your code is concerned you call a web-service there

RestHelper.PostJsonAsync(..)

So you should ask yourself: Is it ok to be done multiple times if someone else uses Any and then starts enumerating it again or is better to prevent such situations (for whatever reason)?

I would use IList here for one more reason: it's quite difficult to debug lazy code that is calling web-services, databases or other resources. When something goes wrong here you'll be having a lot of fun.

###Consider materialized parameters

The same priciples apply to parameters. In your example you execute skus multiple times: with Any and with the foreach loop.

Here, I'd requested an ICollection or an IList to tell the caller: Look out! I'll be using your collection more then once (so you might consider materializing it for better performance before givit it to me).

X likes to execute an IEnumerable as soon as possible, hence why X is doing it inside of the method.

Whereas

Y is thinking that if you wait until the object is actually needed, using differed execution, you’re eliminating wasted objects in the memory.

They are both wrong. The answer isn't digital, this is, there is no 0 or 1 answer. It depends. Sometimes you must execute a collection and return a non-IEnumerable.

Such a case would be querying a database. In this scenario you'd open a database connection (or create a context if it's some ORM) and dispose it at the end. If you don't execute it with ToList or ToArray etc. you won't be able to do it later. The runtime would wrap your enumerator with an anonymous type containing the context but when the execution leaves the method, the context gets disposed and it'll throw an excepiton the moment you try to get the data. In this situation you should return a non-IEnumerable type.

The reason the return type shouldn't be an IEnumerable in this case is that IEnumerable tells me that the return type is lazy so if I wanted to use it multiple times I'd call ToList myslef (again) to get the result which would unnecessrily enumerate the collection again.

So, the bottom line is: if you don't have to materialize the result (because you won't be able to get it later when the service/provider is disposed etc), don't do it but be consistent with the API (return types).

When the result value it's materialized I expect you to communicate this fact clearly by using ICollection, IList or anything else but IEnumerable.

The same priciples apply to parameters. In your example you execute skus multiple times: with Any and with the foreach loop.

Here, I'd requested an ICollection or an IList to tell the caller: Look out! I'll be using your collection more then once (so you might consider materializing it for better performance before givit it to me).

###There is no 0 and 1 answer

X likes to execute an IEnumerable as soon as possible, hence why X is doing it inside of the method.

Whereas

Y is thinking that if you wait until the object is actually needed, using differed execution, you’re eliminating wasted objects in the memory.

They are both wrong. The answer isn't digital, this is, there is no 0 or 1 answer. It depends. Sometimes you must execute a collection and return a non-IEnumerable.

###Materialize when working with dabases

Such a case would be querying a database. In this scenario you'd open a database connection (or create a context if it's some ORM) and dispose it at the end. If you don't execute it with ToList or ToArray etc. you won't be able to do it later. The runtime would wrap your enumerator with an anonymous type containing the context but when the execution leaves the method, the context gets disposed and it'll throw an excepiton the moment you try to get the data. In this situation you should return a non-IEnumerable type.

The reason the return type shouldn't be an IEnumerable in this case is that IEnumerable tells me that the return type is lazy so if I wanted to use it multiple times I'd call ToList myslef (again) to get the result which would unnecessrily enumerate the collection again.

So, the bottom line is: if you don't have to materialize the result (because you won't be able to get it later when the service/provider is disposed etc), don't do it but be consistent with the API (return types).

When the result value it's materialized I expect you to communicate this fact clearly by using ICollection, IList or anything else but IEnumerable.

###Materialize for easier debugging when calling resources

As far as your code is concerned you call a web-service there

RestHelper.PostJsonAsync(..)

So you should ask yourself: Is it ok to be done multiple times if someone else uses Any and then starts enumerating it again or is better to prevent such situations (for whatever reason)?

I would use IList here for one more reason: it's quite difficult to debug lazy code that is calling web-services, databases or other resources. When something goes wrong here you'll be having a lot of fun.

###Consider materialized parameters

The same priciples apply to parameters. In your example you execute skus multiple times: with Any and with the foreach loop.

Here, I'd requested an ICollection or an IList to tell the caller: Look out! I'll be using your collection more then once (so you might consider materializing it for better performance before givit it to me).