I had to implement 2 interface same time with different generic parameter as below. I get confused enough about it. I had no idea which one of them iterate itself in foreach. Now i understand first one is implicitly choosen.
I have tried new BarList().GetEnumerator() but i can not specify type parameter on method level.
Only solution i have found it that casting it to interface like(new BarList() as IEnumerable<string>)
After confusing about it enough. I just wanted to know that this design is not really good idea ? I have to avoid to implement same generic interface one more time ?
class Program
{
static void Main(string[] args)
{
foreach (var item in new BarList())
{
}
}
}
class BarList: IEnumerable<string>, IEnumerable<int>
{
public IEnumerator<int> GetEnumerator()
{
throw new NotImplementedException();
}
System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()
{
throw new NotImplementedException();
}
IEnumerator<string> IEnumerable<string>.GetEnumerator()
{
throw new NotImplementedException();
}
}
Edit:
Let me explain why i am going in this way.
I had to Implement IPagedList<T> interface which is inherited from IList<T>. I wanted to write extension method which convert it to My view model. like below
GetAll().ToPagedList(pageindex);//which is returning IPagedList Then i wanted to use it like below;
GetAll().ToPagedList(pageindex).ToViewModel<T,TViewModel>();
For achieve this I tried to return IPagedList<ViewModel> by that extension method.In that case I have to implement IPagedList 2 times with different parameter. But this strategy made confusing things. This is reason of it.
This seems a bit confusing. Why not make it explicit what is happening by adding the enumerators as properties rather than implementing them on the class. For example,
class ProductCollection
{
public IEnumerable<int> EnumerateTheInts { get { //code to produce enumerator }}
public IEnumerable<string> EnumerateTheStringss { get { //code to produce enumerator }}
}
It isn't always bad to implement an open generic interface twice on an object. For example, IHandle could be implemented by a class which can handle two types of T. However, I would find it confusing to implement IEnumerable twice, because you might not enumerate the type you expect in a for-each or in LINQ. Same reasoning for implementing more than one indexer incidentally. The type of your indexer will determine your result, which I can testify to being extremely confusing!
The compiler is picking the IEnumerator<int> GetEnumerator method by following the rules in 8.8.4 of the C# language specification which first looks for an accessible GetEnumerator() method on the BarList type. The only one of those which is available is the one returning IEnumerator<int>.
If you had made that method use explicit interface implementation as well, then it would have gone onto the later stages of section 8.8.4, which states that if there is more than one type T such that there is an implicit conversion from the expression type (BarList here) to IEnumerable<T> then an error is produced.
I would say this is a confusing design - I would probably add properties or methods to retrieve appropriate "views" on the data.
I'd avoid it. However, it depends on your usage.
It will be okay if you just wanted to pass the instance into a function that expects a IEnumerable<string> parameter explicitely:
you won't have to cast
the function won't even 'see' the other interfaces implemented, so there isn't any confusion.
YMMV
Your current design is confusing. While you have not provided any information about the nature of the collection itself, from the name, I can assume you are supposed to iterate over a bunch of products. Perhaps, you should simply have a class of type Product with a string property and an int property and simply return an IEnumerable<Product> instead.
This way, with LINQ extension methods, you can compose the IEnumerable<T> object you actually mean with:
collection.Select(product => product.IntegerProperty)
collection.Select(product => product.StringProperty)
Of course, you can provide helper methods inside the object as well:
class ProductCollection : IEnumerable<Product> {
public IEnumerable<Product> GetEnumerator() {
// ... return Product objects here.
}
public IEnumerable<int> AsIntegerCollection() {
// yield the integer collection here
}
public IEnumerable<string> AsStringCollection() {
// yield the string collection here
}
}
What are these collections of string and ints? I suppose they mean something in relation with the Product (for example Name, Id, etc...) so I would rather do something like this:
class ProductCollection : IEnumerable<Product>
{
public IEnumerator<Product> GetEnumerator()
{
...
}
public IEnumerator<string> ProductNames // a helper to enumerate product names
{
...
}
public IEnumerator<int> ProductIds // a helper to enumerate product ids
{
...
}
}
Related
I am trying to get two different return values from dictionary extension methods for convenience. The first being an Item of the RealType, the other being a List<RealType>.
The problem / question is this: Getting a single RealType item works like a charm, getting the List crashes and calls for IConvertable implementation. Is there no build in call to convert a full list?
Edit: I am trying to convert from Base Class to Derived Class, not the other way around. Also, I 100% know the data will be of type Derived Class and the caller is passing the correct type each time, without any chance of error.
Why is that? Can I avoid it, without "dirty" tricks?
There are about two dozen RealType - classes that all extend from MyAbstractModel and get saved in a
List<Dictionary<string, MyAbstractModel>. Writing code for two dozen conversions seems like no good idea, when a small dirty (?) trick seems to do it as well.
Consider the following (working) DictionaryExtention class
public static class DictionaryExtenders
{
public static T GetItem<T>(this Dictionary<string, MyAbstractModel> instance, string key)
{
return (T)Convert.ChangeType(instance[key], typeof(T));
}
}
Called like this: RealType item = myDictionary.GetItem<RealType>("choosenIDString");
Edit: Each Dictionary can and will only ever have one type present. There won't ever be two different types stored in one. Yes, this code would allow that and spew out errors, but a saveguard is not needed in this case and is not part of my question.
Now in contrast, the following GetList<RealType> extention calls for IConvertable implementation:
public static List<T> GetList<T>(this Dictionary<string, MyAbstractModel> instance)
{
return (List<T>)Convert.ChangeType(instance.Values.ToList(), typeof(List<T>));
}
I feel like I am missing something here, because the following workaround also returns a List<RealType>, but does not call for IConvertable. I simply loop the dictionary and call GetItem<T>()each time.
public static List<T> GetList<T>(this Dictionary<string, MyAbstractModel> instance)
{
var temp = new List<T>();
foreach (RealType myType in instance.Values.ToList())
{
temp.Add(instance.GetItem<T>(myType.ID));
}
return temp;
}
This does not feel like a solid solution, but like a workaround. What am I missing here? Do the Lists give me a hard time due to faulty syntax on my side, or is there a reason I have to understand?
Your GetList implementations are not valid. All values in dictionary are instances of classes derived from MyAbstractModel but you can't cast them each other in all cases. For example, ModelA and ModelB are both derived from MyAbstractModel. But you can't cast ModelA to ModelB. You can write something like this:
public static List<T> GetList<T>(this Dictionary<string, MyAbstractModel> instance) where T: MyAbstractModel
{
return instance.Values.OfType<T>().ToList();
}
In that case you'll receive all values of particular type T.
you can try this way
public static List<T> GetList<T>(this Dictionary<string, yourModel> instance)
{
return instance.Values.Select(d => (T)Convert.ChangeType(d, typeof(T))).ToList();
}
Got another simple question here that is eluding me.
I have 2 classes:
namespace Assets
{
public class BaseAsset
{
// Code here
}
}
And
namespace Assets
{
public class Asset : BaseAsset
{
// Code here
}
}
I have a function that returns a collection of Asset from the database and I want another function to execute that function and return a collection of BaseAsset.
I have tried this:
public static Collection<BaseAsset> GetCategoryAssets(int CategoryId, string UserId, string CompanyId)
{
return (Collection<BaseAsset>)AssetData.getAssets(CategoryId, UserId, CompanyId);
}
but as you can guess, it doesn't work.
If I was working with lists, I could do:
public static List<BaseAsset> GetCategoryAssets(int CategoryId, string UserId, string CompanyId)
{
return AssetData.getAssets(CategoryId, UserId, CompanyId).Cast<BaseAsset>().ToList();
}
But I would prefer to use a collection, can anyone come up with an elegant solution?
Cheers,
r3plica
This is a very frequently asked question. The name of the feature that you want is generic covariance; that is, the feature that says "if a giraffe is a kind of animal then a list of giraffes is a kind of list of animals."
The problem is that a list of giraffes is not a kind of list of animals. You can put a tiger into a list of animals, but you can't put a tiger into a list of giraffes, and therefore a list of giraffes cannot be used in any context where a list of animals is expected.
The reason you should use IEnumerable<T> instead of Collection<T> is because as of C# 4, IEnumerable<T> is covariant in T, provided that the type arguments provided are both reference types. That is, a sequence of strings can be used as a sequence of objects, because both are reference types. But a sequence of ints cannot be used as a sequence of objects, because one is a value type.
The reason this is safe is because there is no way to insert a tiger into an IEnumerable<Giraffe>.
If you want the ease of .ToList, just write your own .ToCollection extension method. The implementation should be straightforward - take an IEnumerable<T>, loop through it and add everything into a collection with Add.
The problem is that Collection<T> and ICollection<T> are invariant (that is, Collection<BaseAsset> is neither a subtype nor a supertype of Collection<Asset>).
The problem will be very easily solved by returning either IEnumerable<BaseAsset> or IReadOnlyList<BaseAsset> instead of Collection<BaseAsset>.
That is, you can write:
public static IEnumerable<BaseAsset> GetCategoryAssets(int CategoryId, string UserId, string CompanyId)
{
return AssetData.getAssets(CategoryId, UserId, CompanyId);
}
The cast becomes unnecessary.
In general, you should prefer interface types (such as IList<T>, IReadOnlyList<T>, ICollection<T> or IEnumerable<T>) over concrete types (Collection<T> or List<T>) when specifying return values and function parameters.
Instead of trying to cast to the base class, why not just extract an interface and use that.
Since the Collection<T> class has a constructor that takes an IList<T> as an argument, you can always do:
Collection<BaseAsset> = new Collection<BaseAsset>(
assetList.Cast<BaseAsset>().ToList());
Of course, if you need to reuse this behaviour, you could make a CastToCollection extension:
public static Collection<TResult> CastToCollection<TResult>(this IEnumerable source)
{
return new Collection<TResult>(source.Cast<TResult>().ToList());
}
I have followed the suggestions from this post to try and get Distinct() working in my code but I am still having issues. Here are the two objects I am working with:
public class InvoiceItem : IEqualityComparer<InvoiceItem>
{
public InvoiceItem(string userName, string invoiceNumber, string invoiceAmount)
{
this.UserName = userName;
this.InvoiceNumber= invoiceNumber;
this.InvoiceAmount= invoiceAmount;
}
public string UserName { get; set; }
public string InvoiceNumber { get; set; }
public double InvoiceAmount { get; set; }
public bool Equals(InvoiceItem left, InvoiceItem right)
{
if ((object)left.InvoiceNumber == null && (object)right.InvoiceNumber == null) { return true; }
if ((object)left.InvoiceNumber == null || (object)right.InvoiceNumber == null) { return false; }
return left.InvoiceNumber == right.InvoiceNumber;
}
public int GetHashCode(InvoiceItem item)
{
return item.InvoiceNumber == null ? 0 : item.InvoiceNumber.GetHashCode();
}
}
public class InvoiceItems : List<InvoiceItem>{ }
My goal is to populate an InvoiceItems object (we will call it aBunchOfInvoiceItems) with a couple thousand InvoiceItem objects and then do:
InvoiceItems distinctItems = aBunchOfInvoiceItems.Distinct();
When I set this code up and run it, I get an error that says
Cannot implicitly convert type 'System.Collections.Generic.IEnumerable' to 'InvoiceReader.Form1.InvoiceItems'. An explicit conversion exists (are you missing a cast?)
I don't understand how to fix this. Should I be taking a different approach? Any suggestions are greatly appreciated.
Distinct returns a generic IEnumerable<T>. It does not return an InvoiceItems instance. In fact, behind the curtains it returns a proxy object that implements an iterator that is only accessed on demand (i.e. as you iterate over it).
You can explicitly coerce it into a List<> by calling .ToList(). You still need to convert it to your custom list type, though. The easiest way is probably to have an appropriate constructor, and calling that:
public class InvoiceItems : List<InvoiceItem> {
public InvoiceItems() { }
// Copy constructor
public InvoiceItems(IEnumerable<InvoiceItems> other) : base(other) { }
}
// …
InvoiceItems distinctItems = new InvoiceItems(aBunchOfInvoiceItems.Distinct());
Konrad Rudolph's answer should tackle your compilation problems. There is one another important semantic correctness issue here that has been missed: none of your equality-logic is actually going to be used.
When a comparer is not provided to Distinct, it uses EqualityComparer<T>.Default. This is going to try to use the IEquatable<T> interface, and if this is missing, falls back on the plain old Equals(object other) method declared on object. For hashing, it will use the GetHashCode() method, also declared on object. Since the interface hasn't been implemented by your type, and none of the aforementioned methods have been overriden, there's a big problem: Distinct will just fall back on reference-equality, which is not what you want.
Tthe IEqualityComparer<T> interface is typically used when one wants to write an equality-comparer that is decoupled from the type itself. On the other hand, when a type wants to be able to compare an instance of itself with another; it typically implements IEquatable<T>. I suggest one of:
Get InvoiceItem to implement IEquatable<InvoiceItem> instead.
Move the comparison logic to a separate InvoiceItemComparer : IEqualityComparer<InvoiceItem> type, and then call invoiceItems.Distinct(new InvoiceItemComparer());
If you want a quick hack with your existing code, you can do invoiceItems.Distinct(new InvoiceItem());
Quite simply, aBunchOfInvoiceItems.Distinct() returns an IEnumerable<InvoiceItem> and you are trying to assign that to something that is not an IEnumerable<InvoiceItem>.
However, the base class of InvoiceItems has a constructor that takes such an object, so you can use this:
public class InvoiceItems : List<InvoiceItem>
{
public InvoiceItems(IEnumerable<InvoiceItem> items)
base(items){}
}
Then you can use:
InvoiceItems distinctItems = new InvoiceItems(aBunchOfInvoiceItems.Distinct());
As is though, I don't see much benefit in deriving from List<InvoiceItem> so I would probably lean more toward:
List<InvoiceItem> distinctItems = aBunchOfInvoiceItems.Distinct().ToList();
The error has everything to do with your class InvoiceItems, which inherits from List<InvoiceItem>.
Distinct returns an IEnumerable<InvoiceItem>: InvoiceItems is a very specific type of IEnumerable<InvoiceItem>, but any IEnumerable<InvoiceItem> is not necessarily an InvoiceItems.
One solution could be to use an implicit conversion operator, if that's what you wanted to do: Doh, totally forgot you can't convert to/from interfaces (thanks Saed)
public class InvoiceItems : List<InvoiceItem>
{
public InvoiceItems(IEnumerable<InvoiceItem> items) : base(items) { }
}
Other things to note:
Inheriting from List<T> is usually bad. Implement IList<T> instead.
Using a list throws away one of the big benefits of LINQ, which is lazy evaluation. Be sure that prefetching the results is actually what you want to do.
Aside from the custom class vs IEnumerable issue that the other answers deal with, there is one major problem with your code. Your class implements IEqualityComparer instead of IEquatable. When you use Distinct, the items being filtered must either implement IEquatable themselves, or you must use the overload that takes an IEqualityComparer parameter. As it stands now, your call to Distinct will not filter the items according to the IEqualityComparer Equals and GetHashCode methods you provided.
IEqualityComparer should be implemented by another class than the one being compared. If a class knows how to compare itself, like your InvoiceItem class, it should implement IEquatable.
When i complile the code
class customer
{
Order getOrder;
public IEnumerable<Order> MyOrders
{
get { return getOrder; }
set{getOrder=value;}
}
}
class Order:IEnumerable<Order>
{
string itemName;
public string ItemName
{
get { return itemName; }
set { itemName = value; }
}
public IEnumerator<Order> GetEnumerator()
{
return (IEnumerator)this.GetEnumerator();
}
IEnumerator IEnumerable.GetEnumerator( )
{
return this.GetEnumerator ();
}
}
I receive
Cannot implicitly convert type 'System.Collections.Generic.IEnumerable' to 'Order'
How to fix it?
get { return getOrder; }
set{getOrder=value;}
value is of type 'System.Collections.Generic.IEnumerable', getOrder is of type Order. Both are in no way compatible. Maybe you want getOrder (unfortunate naming also) to be IEnumerable, too?
Moreover this looks VERY wrong
Order:IEnumerable<Order>
I guess it should be something like IEnumerable<OrderItem>
The first problem is that you have Order implement IEnumerable, which is fairly strange. You can make this work, but it's odd. Normally, you wouldn't enumerate yourself.
The second problem are here:
public IEnumerator<Order> GetEnumerator()
{
return (IEnumerator)this.GetEnumerator();
}
You need to switch how you're implementing your enumerators. IEnumerator<T> inherits IEnumerator, but you're treating it the other way around. Switch the declarations:
public IEnumerator<Order> GetEnumerator()
{
yield return this; // You need to create an ACTUAL enumerator here!
}
IEnumerator IEnumerable.GetEnumerator()
{
return this.GetEnumerator(); // This can call the above, since IEnumerator<Order> is also IEnumerator
}
However, in the code you posted, you never actually implement GetEnumerator to return an enumerator. There are many options for this, but you need to actually create an enumerator (or use "yield return" and let the compiler do it for you, which I did above).
You have made an Order class that is IEnumerable<Order>, that enables you to enumerate the class, but it doesn't create a collection that you can enumerate.
You probably just want to create a colleciton of Order items:
List<Order> orders = new List<Order>();
If you want to create a class that is a collection of Order items you can simply inherit from a list:
public class OrderList : List<Order> {}
Then you create the list like this:
OrderList orders = new OrderList();
I see two issues. Your property MyOrders has a return type of IEnumerable<Order>, when the field it returns is actually of type Order.
Also, I am not sure if I read this right - Order has a base class of type IEnumerable<Order> - doesn't this create some sort of endless loop? An enumerable of type enumerable of type enumarable of type enumerable of type enumarable of type enumerable of type enumarable...
What is class Order ? Is it supposed to represent a single order, or a collection of orders? If it is the latter, derive from a built-in collection class that already has IEnumerable in it (like List<>) than rename it so that it's classname communicates that it is a collection (Orders or OrderCollection) and delete the IEnumerable and IEnumerator implementations (They come for free by deriving from List<> ...
// inheriting from List<Order> means you get Enumerable for free
class Orders: List<Order>
{
string itemName;
public string ItemName
{
get { return itemName; }
set { itemName = value; }
}
}
Regarding implicit casting, In your case you cannot cast because a collection is not the same type as the type of object which is in the collection.
But, in general, you cannot implicitly cast a more general type to a more specific type, because it might not be the more specific type. If something cpmes in as an Animal, you cannot implicitly cast it to Dog, - it might be a Cat. (The other way around is all right You can implicitly cast a Dog to an Animal)
If this was the problem, you would fix it by explicitly casting instead.
How do I get the type of a generic typed class within the class?
An example:
I build a generic typed collection implementing ICollection< T>. Within I have methods like
public void Add(T item){
...
}
public void Add(IEnumerable<T> enumItems){
...
}
How can I ask within the method for the given type T?
The reason for my question is: If object is used as T the collection uses Add(object item) instead of Add(IEnumerable<object> enumItems) even if the parameter is IEnumerable. So in the first case it would add the whole enumerable collection as one object instead of multiple objects of the enumerable collection.
So i need something like
if (T is object) {
// Check for IEnumerable
}
but of course that cannot work in C#. Suggestions?
Thank you very much!
Michael
You can use: typeof(T)
if (typeof(T) == typeof(object) ) {
// Check for IEnumerable
}
Personally, I would side step the issue by renaming the IEnumerable<T> method to AddRange. This avoids such issues, and is consistent with existing APIs such as List<T>.AddRange.
It also keeps things clean when the T you want to add implements IEnumerable<T> (rare, I'll admit).
If you want to use the is operator in a generic class/method you have to limit T to a reference type:
public void MyMethod<T>(T theItem) where T : class
{
if (theItem is IEnumerable) { DoStuff(); }
}