Re: a case for multiple inheritance



John wrote:

Hi All,
Although C# has Generics, it still does not support the generic
programming paradigm. Multiple inheritance is required to support real
generic programming. Here is a simple design pattern to illustrate this.

Problem:
I need to expose two lists of objects from a high-level class. I would
like to expose these lists as read-only, but require write access
internally.

Solution:
1) Create a generic ProtectedList<T> class which inherits from List<T>
and overrides the write functions (using the new modifier) to change the
access level from public to protected.
2) Inherit both specialized List<T> by the high-level class

Discussion:
While this usage of inheritance does not conform to the "is-a" relation
imposed by the OOP paradigm, it is a simple and easy way to reuse code
in a generic way.

Thanks for any thoughts, and good solutions to this problem in the
existing C# paradigm.

Hi John,

1) Create a generic ProtectedList<T> class which inherits from List<T>
and overrides the write functions (using the new modifier) to change the
access level from public to protected.

Mhm. FYI The 'new' modifier will define a method as hiding a derived one,
however, take a look at this:

public class A
{
public void Foo ()
{
Console.WriteLine("Foo in A");
}
}

public class B : A
{
private new void Foo ()
{
Console.WriteLine("Foo in B");
}
}

public class E
{
public static void Main ()
{
B b = new B();
b.Foo();
}
}

The output of this will be "Foo in A", because the accessible method from A
is called. If you change the scope of 'Foo' in B to public, the output
will be "Foo in B" as is expected. And, even more interestingly, if you
cast b to A and call 'Foo':

((A)b).Foo();

You'll get A's implementation of 'Foo'. So, as you can see, using the new
keyword will not give you the desired effect here.

2) Inherit both specialized List<T> by the high-level class
Can you explain this a bit more? I'm not sure why you need multiple
inheritance here. If you want to expose two read-only lists from your
high-level class, you can expose them as properties that return an array of
your list's type, then call the ToArray method of the associated list.

--
Tom Spink
University of Edinburgh
.



Relevant Pages

  • Re: The Language I want
    ... It has nothing to do with inheritance. ... The point is that visibility belongs to package / module. ... Generics is a huge mess. ... Yes it does it protects members from access by users, ...
    (comp.lang.misc)
  • Re: The Language I want
    ... It has nothing to do with inheritance. ... The point is that visibility belongs to package / module. ... Generics is a huge mess. ... Yes it does it protects members from access by users, ...
    (comp.lang.misc)
  • Re: The Language I want
    ... inheritance of interfaces from concrete types. ... Generics is a huge mess. ... Templates or hygenic macros are not generics! ...
    (comp.lang.misc)
  • Re: Do I *have* to use OOP to use modules?
    ... Sure, Foo lives in a state of sin from an IOO point of view, ... Why will IOO ... And that's how people will learn Perl objects, ... ** to go through contortions to enable full or partial inheritance. ...
    (comp.lang.perl.misc)
  • Re: Fun with generics
    ... Generics are for when you DON'T know the ... If you protest "But Foo is not a collection of E!", I would reply "Foo isn't a collection at all; but the unknown type is E, and that's what why you write Foo. ... From reading Chris' reply to your post elsewhere in the thread, I'm fairly confident I had guessed correctly at what Chris meant. ...
    (comp.lang.java.programmer)

Loading