Why .Net Sucks today
-
The lack of multiple inheritance. Instead of using collections in their native appearance, I like to create a class that inherits from a desired collection type, like so:
public class MyCollection : List<MyClass>
I do this because it allows me to write code specific to that collection, such as custom Add/Remove methods. In this case, I want to create a custom event that these collections send when something happens. Because there's no multiple inheritance, I can't simply write a little base class that implements the custom event code, because I'm already inheriting the List object. Instead, I have to duplicate the event code in every class from which I wish to implement it. Grrr... I now return you to your government-mandated stupors.
".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, 2013John Simmons / outlaw programmer wrote:
The lack of multiple inheritance.
Yup. When you need it, you really need it, and interfaces are a pathetic replacement. Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
-
John Simmons / outlaw programmer wrote:
The lack of multiple inheritance.
Yup. When you need it, you really need it, and interfaces are a pathetic replacement. Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
-
When do you need it?
I updated my original message to provide an example.
".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 -
John Simmons / outlaw programmer wrote:
The lack of multiple inheritance.
Yup. When you need it, you really need it, and interfaces are a pathetic replacement. Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
In point of fact, more often than not interfaces simply aren't appropriate.
".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 -
I updated my original message to provide an example.
".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, 2013I'd need to see the actual use case but maybe extension methods or (IoC like) function injection?
-
The lack of multiple inheritance. Instead of using collections in their native appearance, I like to create a class that inherits from a desired collection type, like so:
public class MyCollection : List<MyClass>
I do this because it allows me to write code specific to that collection, such as custom Add/Remove methods. In this case, I want to create a custom event that these collections send when something happens. Because there's no multiple inheritance, I can't simply write a little base class that implements the custom event code, because I'm already inheriting the List object. Instead, I have to duplicate the event code in every class from which I wish to implement it. Grrr... I now return you to your government-mandated stupors.
".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, 2013This 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
-
The lack of multiple inheritance. Instead of using collections in their native appearance, I like to create a class that inherits from a desired collection type, like so:
public class MyCollection : List<MyClass>
I do this because it allows me to write code specific to that collection, such as custom Add/Remove methods. In this case, I want to create a custom event that these collections send when something happens. Because there's no multiple inheritance, I can't simply write a little base class that implements the custom event code, because I'm already inheriting the List object. Instead, I have to duplicate the event code in every class from which I wish to implement it. Grrr... I now return you to your government-mandated stupors.
".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, 2013I'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"!
-
The lack of multiple inheritance. Instead of using collections in their native appearance, I like to create a class that inherits from a desired collection type, like so:
public class MyCollection : List<MyClass>
I do this because it allows me to write code specific to that collection, such as custom Add/Remove methods. In this case, I want to create a custom event that these collections send when something happens. Because there's no multiple inheritance, I can't simply write a little base class that implements the custom event code, because I'm already inheriting the List object. Instead, I have to duplicate the event code in every class from which I wish to implement it. Grrr... I now return you to your government-mandated stupors.
".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, 2013Why 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...)
-
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
Oops, it took me too long to write my reply (see below) :^)
-
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
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 -
When do you need it?
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 inCommonToAllControlsand access them through the derived instance, and the instance can access methods inCommonToAllControls. 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 likevoid DoSomething() {commonality.DoSomething();}and, as you point out, use IoC to pass in an instance ofICommonToAllControls. 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! MarcImperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
-
The lack of multiple inheritance. Instead of using collections in their native appearance, I like to create a class that inherits from a desired collection type, like so:
public class MyCollection : List<MyClass>
I do this because it allows me to write code specific to that collection, such as custom Add/Remove methods. In this case, I want to create a custom event that these collections send when something happens. Because there's no multiple inheritance, I can't simply write a little base class that implements the custom event code, because I'm already inheriting the List object. Instead, I have to duplicate the event code in every class from which I wish to implement it. Grrr... I now return you to your government-mandated stupors.
".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, 2013List<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
-
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
:thumbsup:
-
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
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 -
John Simmons / outlaw programmer wrote:
The lack of multiple inheritance.
Yup. When you need it, you really need it, and interfaces are a pathetic replacement. Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
I'm glad I'm not the only one that thought that was a WTF thing to do in C#.
Jeremy Falcon
-
The lack of multiple inheritance. Instead of using collections in their native appearance, I like to create a class that inherits from a desired collection type, like so:
public class MyCollection : List<MyClass>
I do this because it allows me to write code specific to that collection, such as custom Add/Remove methods. In this case, I want to create a custom event that these collections send when something happens. Because there's no multiple inheritance, I can't simply write a little base class that implements the custom event code, because I'm already inheriting the List object. Instead, I have to duplicate the event code in every class from which I wish to implement it. Grrr... I now return you to your government-mandated stupors.
".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- 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
-
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 inCommonToAllControlsand access them through the derived instance, and the instance can access methods inCommonToAllControls. 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 likevoid DoSomething() {commonality.DoSomething();}and, as you point out, use IoC to pass in an instance ofICommonToAllControls. 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! MarcImperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
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
-
The lack of multiple inheritance. Instead of using collections in their native appearance, I like to create a class that inherits from a desired collection type, like so:
public class MyCollection : List<MyClass>
I do this because it allows me to write code specific to that collection, such as custom Add/Remove methods. In this case, I want to create a custom event that these collections send when something happens. Because there's no multiple inheritance, I can't simply write a little base class that implements the custom event code, because I'm already inheriting the List object. Instead, I have to duplicate the event code in every class from which I wish to implement it. Grrr... I now return you to your government-mandated stupors.
".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, 2013public 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:
-
The lack of multiple inheritance. Instead of using collections in their native appearance, I like to create a class that inherits from a desired collection type, like so:
public class MyCollection : List<MyClass>
I do this because it allows me to write code specific to that collection, such as custom Add/Remove methods. In this case, I want to create a custom event that these collections send when something happens. Because there's no multiple inheritance, I can't simply write a little base class that implements the custom event code, because I'm already inheriting the List object. Instead, I have to duplicate the event code in every class from which I wish to implement it. Grrr... I now return you to your government-mandated stupors.
".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 -
The lack of multiple inheritance. Instead of using collections in their native appearance, I like to create a class that inherits from a desired collection type, like so:
public class MyCollection : List<MyClass>
I do this because it allows me to write code specific to that collection, such as custom Add/Remove methods. In this case, I want to create a custom event that these collections send when something happens. Because there's no multiple inheritance, I can't simply write a little base class that implements the custom event code, because I'm already inheriting the List object. Instead, I have to duplicate the event code in every class from which I wish to implement it. Grrr... I now return you to your government-mandated stupors.
".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, 2013There's always my way: Implanting Common Code in Unrelated Classes[^] :cool:
