With ver 2.0, an EntityCollection<T> will not cast to EntityCollectionBase2<T> so my code is broken.

I'm not very new to generics, but have never experienced this before. How do you cast, for example, EntityCollection<CustomerEntity> to EntityCollectionBase2<EntityBase2>?

Thanks for your help!

Jeff

You can't, because C# and VB.NET don't support covariance. (the term for this behavior is covariance). The CLR does, but C# and VB.NET dont.

If you have a List<string> foo and you want to cast it to List<object> like: List<object> bar = (List<object)foo;

it won't work, because even though the generic parameter types are in a hierarchy, the collection's aren't.

This will work: EntityCollection<CustomerEntity> foo = ... ; EntityCollectionBase2<CustomerEntity> bar = (EntityCollectionBase2<CustomerEntity>)foo;

because EntityCollectionBase2<CustomerEntity> is the supertype of EntityCollection<CustomerEntity>. However casting it to EntityCollectionBase2<EntityBase2> doesn't work, as that would mean that the EntityCollectionBase2<EntityBase2> is then a 'portal' to add other EntityBase2 objects to the original EntityCollection<CustomerEntity> collection, of a different type than CustomerEntity.

If you want a generic way to access these collections, use IEntityCollection2.

Hmmmm.... very interesting. It sounds like generic collections aren't very generic. So, other than the performance enhancement that generic collections provide, why use them in LLBLGen projects?

Jeff

Jeff wrote:

Hmmmm.... very interesting. It sounds like generic collections aren't very generic. So, other than the performance enhancement that generic collections provide, why use them in LLBLGen projects? Jeff

They are very generic though the idea that List<string> is a subtype of List<object> and thus can be used in a cast is just something you've to live with. In general the root cause is said to be that: string[] foo; is castable to object[] bar;

which is similar, though C#/VB.NET do support that kind of covariance.

Generic collections are useful because they're compile time checked. No more cast exceptions at runtime. Also, your code is easier, because you don't have to cast when you read an entity from the collection.

However, generic collections in general require you to specify a type for the collection's generic type parameter. To overcome this, I've kept IEntityCollection(2), the interfaces which allow you to use any generic collection through the interface.

Yes, thanks. IEntityCollection2 was the answer that I needed and now my code isn't quite so broken. Not that bad, conversion to ver 2.0 should be completed in a couple of hours.

Then, I'll take your new stuff out for a spin.

Thanks for your help.

Jeff

Jeff wrote:

Yes, thanks. IEntityCollection2 was the answer that I needed and now my code isn't quite so broken. Not that bad, conversion to ver 2.0 should be completed in a couple of hours.

Then, I'll take your new stuff out for a spin.

This is exactly why I kept the interface Interfaces are already a way of doing generic programming, and it helps a lot when working with a generic collection but you don't know the generic type.

I don't know how big your project is, I ran into a problem with large projects and the persistenceinfoprovider class, that's currently being changed (different template), and I hope to have an update of that later today.

If you run into a problem where you need a method of EntityCollectionBase2 to be added in IEntityCollection2, let me know. The code will be reviewed for missing methods in interfaces so it will be taken care of it, but if you need a method added to the interface let me know and I'll add it.

I hope to have a reference manual tomorrow.