Overload List<>.Add method

[Peter Duniho]

[...]
There are a number of reasons why your contrived example isn't
applicable, not the least of which being that IT'S NOT THE SCENARIO
BEING DISCUSSED HERE!

Pete,

I don't know if I had followed the thread differently but...

I'm just asking the OP why he would go the hard way. He had just
searched a 'hack' to get the extension method working on C# 2.0. I had
shown him two alternatives to get it working on C# 2.0.

Actually, he wrote that he was targeting the 2.0 Framework. It's possible
he's also limited to C# 2.0, but I haven't noticed a statement to that
effect and you can target the 2.0 Framework with VS 2008 (i.e. C# 3.0).
In fact, based on the work-around he's using, it looks to me as though
that's exactly what he's doing.

In any case, it should be clear from my comments that I find _either_ an
extension method or a plain static method equivalent. The only reason for
preferring the extension method to a plain static method is the simpler
syntax in usage; it's functionally the same. All of this, I have written
already.

Then the discussion start when you said that inheriting any class should
be avoided which is contradict to my view. I'm not asking the specific
situation like the problem the OP is having. To me it is like that you
are saying extension methods is a preferable way to extend the
functionality of a type.

I've already stated the justifications for my opinion, and yes...my
opinion is that inheritance should not be the first choice when looking
for ways to incorporate or enhance existing classes. Inheritance isn't
the only feature found in OOP languages, and it's also often not the best
way to address a particular need. Inheriting classes at every possibly
opportunity is a great way to clutter up your code, create overly complex
class hierarchies, and impose unnecessary constraints on future
development and maintenance.

Inheriting a type should provide some _advantage_ over alternative
approaches, if one is going to use inheritance. The only thing that
inheritance does in this particular scenario is complicate things. It
introduces a new type into the context, which is enough of a complication
as it is, but also means that anywhere one wants to use the new method,
the code has to be rewritten to use the new type. How is that _better_?

Pete

 

[Ben Voigt [C++ MVP]]

[...]
So it's somewhat ill advised to lambaste someone with "get your OOP
fundamentals straight" when they are using what is, as near as I can
tell, accepted terminology within the OOP computer science community.

Granted, OOP wasn't even part of the curriculum when I got my CS degree.
But I've never seen the term "member hiding" applied to anything except
members of inherited classes, in the context of C# or elsewhere. I didn't
find any obvious counter-examples using Google either.

In CS, there is the concept of "information hiding", which of course is a
more general concept. But hiding _members_ is about inheritance, as
that's the only context in which you can hide a specific member of a class
(as opposed to the entire instance itself) that wasn't previously hidden
(i.e. "hiding" isn't related to other accessibility control, such as
"private" vs. "public" in C# and other languages).

Other languages (e.g. C++) support private (or protected) inheritance as a
means to expose only a subset of members. So I wouldn't say the concepts
are wholly separate.


__________ Information from ESET NOD32 Antivirus, version of virus signature database 4343 (20090817) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com