Why .Net Sucks today

[Sascha Lefevre]

This wouldn't do?

class EventCollection<T> : List<T>
{
// event methods
}

class MyCollection : EventCollection<MyClass>
{
// ...
}

If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson

[Lost User]

I'm probably misinterpreting what it is that you want to do, but wouldn't something like this help?

public abstract class AbstractCollection<T> : List<T>
{
public delegate void OnItemAddedEventHandler(T item);

public event OnItemAddedEventHandler OnItemAdded;

public new void Add(T item)
{
    // Custom implementation
    if (OnItemAdded != null)
    {
        OnItemAdded(item);
    }

    base.Add(item);
}

public new void Remove(T item)
{
    // Custom implementation

    base.Remove(item);
}

public new void RemoveAt(int index)
{
    // Custom implementation

    base.RemoveAt(index);
}

}

The whole thing's rigged to blow, touch those tanks and "boooom"!

[U G Leander]

Why not write a class with your custom event code which inherits the List object, and then inherit this class in MyCollection/whatever? At least then you wouldn't have to duplicate the event code... ...or use the custom event code class as a Property in MyCollection? (just some thoughts, of course it may not work this way for your purposes...)

[U G Leander]

Oops, it took me too long to write my reply (see below) :^)

[realJSOP]

Why yes, that would work. But I still want multiple inheritance. :)

".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013

[Marc Clifton]

Duncan Edwards Jones wrote:

When do you need it?

The use case that I've come up against in the past is the ability to extend a UI control's behavior to include some common behaviors. For example, what I want is: class MySmartLabel : Label, CommonToAllControls {} The idea being here that I can implement behaviors in CommonToAllControls and access them through the derived instance, and the instance can access methods in CommonToAllControls. If I write it as an interface: public class MyLabel : Label, ICommonToAllControls {} I have to implement the interface functions in each class. At best, this means having stubby functions like void DoSomething() {commonality.DoSomething();} and, as you point out, use IoC to pass in an instance of ICommonToAllControls. Or, I can invert it:

class CommonToAllControls
{
Control target;
// ... common stuff I want to do ...
}

But then I lose the ability to reference, without casting, the specific properties/methods of a control when I need them. There are now other ways to skin the cat -- extension methods, for example. Now, arguably, one might say that multiple inheritance is bad design because it fixes the implementation, whereas I might want to vary the implementation of CommonToAllControls. I can to a large extend agree with that, it's just that interfaces are a sort of klunky half-way solution to that problem. Then again, maybe I've got some big gaping hole in my understanding of OOP! Marc

Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!

[Sander Rossel]

List<T> probably isn't the class you want to inherit anyway. Try Collection<T>[^] instead :rolleyes:

Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.

Simplicity is prerequisite for reliability. — Edsger W. Dijkstra

Regards, Sander

[Slacker007]

:thumbsup:

[realJSOP]

No, I really do want List.

".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013

[Jeremy Falcon]

I'm glad I'm not the only one that thought that was a WTF thing to do in C#.

Jeremy Falcon

[Philippe Mori]

1. You can use extension methods. 2) For future maintenance purpose, almost always a better idea to use composition instead of multiple inheritance. 3) If the list is a private member of a class, then the custom method could be added to that class instead. 4) You can also use composition and have a property that returns the list if for example, your class purpose is to build a list. In practice, you might loose a few minutes now but the application will usually be more maintainable if every class follow the SOLID principle. When refactoring code, complex hierarchy are much harder to work with...

Philippe Mori

[Philippe Mori]

In such case, extension method is definitively the best solution if you don't need events and properties... Otherwise, I would use an interface and an helper class. The less coupled the code is, the easier it will be to maintain.

Philippe Mori

[Shelby Robertson]

public class CollectionBase: List
{
//custom events
}

public class MyCollection : CollectionBase
{
}

Could be lack of sleep, but why wouldn't that work?

CPallini wrote:

You cannot argue with agile people so just take the extreme approach and shoot him. :Smile:

[snorkie]

According to Eric Lippert, you don't need it... Why C# does not support multiple inheritance? - Stack Overflow[^]

Hogan

[PIEBALDconsult]

There's always my way: Implanting Common Code in Unrelated Classes[^] :cool:

[Camilo Reyes]

My previous team got around this by implementing 15 layers of bullshit inheritance. What? Not good enough? ;P