feature question

[Kamen Yotov]

hi all,
i first posted this on
http://msdn.microsoft.com/vcsharp/te...k/default.aspx
(ask a c# language designer) a couple of days ago, but no response so far...
therefore, i am pasting it here as well... enjoy!

(you can skip to the source at the end of the message if you like...)

Consider:

1) a class relationships A -> B and C -> D
2) a delegate declaration "delegate C DF (B b);"
3) a function with signature "D F (A a);"

According to C# syntax and semantics, an instance of the delegate DF
cannot be created from the function F, as the parameter types and the
return type do not match the delegate declaration.

I would argue that from formal language type theory, it should be
possible, because of polymorphism.

Suppose this hypothetic code:

{
DF d = new DF(F);

B b = new ...

C c = d(b);
}

I have no reasons to believe that such code should break. In fact:

1) d is an instance of DF using function F

2) d is called with parameter b which is of type B, which derives from
A,
therefore F can be called itself with b

3) d's result is assigned to c, which is of type C, which type D derives
from. Because F returns D, it's result is assignable to C-typed
objects...

In summary I would argue that it is type-safe to allow this. Further I
don't think that it adds any further complexity in the language and it
is something worth having. I personally expected to see it there, was
disappointed when it I did not, and I have needed it a number of times.

One fact that confirms my thesis is that if we write the following
function:

C auxF (B b)
{
return F(b);
}

The new auxF is compatible with the delegate and does exactly what we
want.
To refine my question further I would say: Why do we need auxF???

Please find a "working" C# program below that illustrates the issue!

Please outline the reasons for which this is not part of the C#
language.
Do not hesitate to contact me personally if you need more information
regarding this question.

Best Regards,
Kamen Yotov
ka***@yotov.org
http://yotov.org

using System;

class A {}
class B: A {}
class C {}
class D: C {}

delegate C DF (B b);

class Run
{
static D F (A a)
{
return new D();
}

static C auxF (B b) // I would like to get rid of this function
{
return F(b);
}

static void Main(string[] args)
{
DF d = new DF(auxF); // I want "new DF(F)" here!
B b = new B();

Console.WriteLi ne(d(b));
}
}

[Bruno Jouhier [MVP]]

Makes sense. This does not create any hole in the type system and it could
be handy in some cases.

The same reasoning could be applied to overrides:

1) a class relationships A -> B and C -> D
2) a base method with signature "C BM(B b);"
3) an override with signature "D OM(A a);"

Why doesn't C# let you override BM with OM in this case? Quite often, I
would like to do this, especially replacing the return type (C) by a more
specialized one (D) into the override, but I cannot do it, I am forced to
use C as return type and then my code is polluted by (D) casts.

To me, this is more rigorous than the following:

A[] aArray = new B[10];

which will let you store objects that don't derive from B into aArray. The
compiler allows it and you get a runtime exception!

Bruno.

"Kamen Yotov" <ka***@yotov.or g> a écrit dans le message de
news:eY******** ******@TK2MSFTN GP09.phx.gbl...

hi all,
i first posted this on
http://msdn.microsoft.com/vcsharp/te...k/default.aspx
(ask a c# language designer) a couple of days ago, but no response so far... therefore, i am pasting it here as well... enjoy!

(you can skip to the source at the end of the message if you like...)

Consider:

1) a class relationships A -> B and C -> D
2) a delegate declaration "delegate C DF (B b);"
3) a function with signature "D F (A a);"

According to C# syntax and semantics, an instance of the delegate DF
cannot be created from the function F, as the parameter types and the
return type do not match the delegate declaration.

I would argue that from formal language type theory, it should be
possible, because of polymorphism.

Suppose this hypothetic code:

{
DF d = new DF(F);

B b = new ...

C c = d(b);
}

I have no reasons to believe that such code should break. In fact:

1) d is an instance of DF using function F

2) d is called with parameter b which is of type B, which derives from
A,
therefore F can be called itself with b

3) d's result is assigned to c, which is of type C, which type D derives
from. Because F returns D, it's result is assignable to C-typed
objects...

In summary I would argue that it is type-safe to allow this. Further I
don't think that it adds any further complexity in the language and it
is something worth having. I personally expected to see it there, was
disappointed when it I did not, and I have needed it a number of times.

One fact that confirms my thesis is that if we write the following
function:

C auxF (B b)
{
return F(b);
}

The new auxF is compatible with the delegate and does exactly what we
want.
To refine my question further I would say: Why do we need auxF???

Please find a "working" C# program below that illustrates the issue!

Please outline the reasons for which this is not part of the C#
language.
Do not hesitate to contact me personally if you need more information
regarding this question.

Best Regards,
Kamen Yotov
ka***@yotov.org
http://yotov.org

using System;

class A {}
class B: A {}
class C {}
class D: C {}

delegate C DF (B b);

class Run
{
static D F (A a)
{
return new D();
}

static C auxF (B b) // I would like to get rid of this function
{
return F(b);
}

static void Main(string[] args)
{
DF d = new DF(auxF); // I want "new DF(F)" here!
B b = new B();

Console.WriteLi ne(d(b));
}
}

[Bruno Jouhier [MVP]]

Ooop, my post is not very clear. You should read:

1) a class relationships A -> B and C -> D
2) a base method BM with signature "C M(B b);"
3) an override OM with signature "D M(A a);"

Typical example is the Object/Factory pattern where you have two parallel
hierarchies: BaseObject, DerivedObject on one side and BaseFactory,
DerivedFactory on the other side. You want to define
BaseFactory GetFactory() in the BaseObject class
and override it as:
DerivedFactory GetFactory() in the DerivedObject class

There are ways around it (with the "new" keyword) but things would be
cleaner if the type system was a bit smarter.

Note: GetFactory() can be replaced by a get-only Factory property, this does
not change the point above. On the other hand, we cannot make the property
get/set because then we have a typing problem on the set (the override set
accessor has a more restrictive signature than the base accessor).

Bruno

"Bruno Jouhier [MVP]" <bj******@clu b-internet.fr> a écrit dans le message de
news:%2******** **********@TK2M SFTNGP10.phx.gb l...

Makes sense. This does not create any hole in the type system and it could
be handy in some cases.

The same reasoning could be applied to overrides:

1) a class relationships A -> B and C -> D
2) a base method with signature "C BM(B b);"
3) an override with signature "D OM(A a);"

Why doesn't C# let you override BM with OM in this case? Quite often, I
would like to do this, especially replacing the return type (C) by a more
specialized one (D) into the override, but I cannot do it, I am forced to
use C as return type and then my code is polluted by (D) casts.

To me, this is more rigorous than the following:

A[] aArray = new B[10];

which will let you store objects that don't derive from B into aArray. The
compiler allows it and you get a runtime exception!

Bruno.

"Kamen Yotov" <ka***@yotov.or g> a écrit dans le message de
news:eY******** ******@TK2MSFTN GP09.phx.gbl...

hi all,
i first posted this on
http://msdn.microsoft.com/vcsharp/te...k/default.aspx
(ask a c# language designer) a couple of days ago, but no response so

far...

therefore, i am pasting it here as well... enjoy!

(you can skip to the source at the end of the message if you like...)

Consider:

1) a class relationships A -> B and C -> D
2) a delegate declaration "delegate C DF (B b);"
3) a function with signature "D F (A a);"

According to C# syntax and semantics, an instance of the delegate DF
cannot be created from the function F, as the parameter types and the
return type do not match the delegate declaration.

I would argue that from formal language type theory, it should be
possible, because of polymorphism.

Suppose this hypothetic code:

{
DF d = new DF(F);

B b = new ...

C c = d(b);
}

I have no reasons to believe that such code should break. In fact:

1) d is an instance of DF using function F

2) d is called with parameter b which is of type B, which derives from
A,
therefore F can be called itself with b

3) d's result is assigned to c, which is of type C, which type D derives
from. Because F returns D, it's result is assignable to C-typed
objects...

In summary I would argue that it is type-safe to allow this. Further I
don't think that it adds any further complexity in the language and it
is something worth having. I personally expected to see it there, was
disappointed when it I did not, and I have needed it a number of times.

One fact that confirms my thesis is that if we write the following
function:

C auxF (B b)
{
return F(b);
}

The new auxF is compatible with the delegate and does exactly what we
want.
To refine my question further I would say: Why do we need auxF???

Please find a "working" C# program below that illustrates the issue!

Please outline the reasons for which this is not part of the C#
language.
Do not hesitate to contact me personally if you need more information
regarding this question.

Best Regards,
Kamen Yotov
ka***@yotov.org
http://yotov.org

using System;

class A {}
class B: A {}
class C {}
class D: C {}

delegate C DF (B b);

class Run
{
static D F (A a)
{
return new D();
}

static C auxF (B b) // I would like to get rid of this function
{
return F(b);
}

static void Main(string[] args)
{
DF d = new DF(auxF); // I want "new DF(F)" here!
B b = new B();

Console.WriteLi ne(d(b));
}
}

[Stephen Martin]

While the return type doesn't present a problem since type D is always also
type C, the input parameter is a problem. Your delegate DF is a guarantee
that you can call that method with a parameter of type B or any subclass of
B.

If I have type Q -> B and you pass me a delegate d of type DF but it can
only accept a parameter of type A then it will compile fine but when I try
to invoke the delegate with a parameter of type Q I will get a nasty runtime
error because you've broken the contract that I can use any subclass of B
with that delegate.

There is also a similar problem with overrides. The base class guarantees
that the method can be called with any subclass of the parameter type but
the override narrows that guarantee so the method can no longer be used
polymorphically .

I think that overriding the return types is simpler since it doesn't, in
fact, violate the interface contract and I'm sure overriding the parameter
types could be done but I'm not sure it would be desirable and I don't think
it would be simple.

"Kamen Yotov" <ka***@yotov.or g> wrote in message
news:eY******** ******@TK2MSFTN GP09.phx.gbl...

hi all,
i first posted this on
http://msdn.microsoft.com/vcsharp/te...k/default.aspx
(ask a c# language designer) a couple of days ago, but no response so far... therefore, i am pasting it here as well... enjoy!

(you can skip to the source at the end of the message if you like...)

Consider:

1) a class relationships A -> B and C -> D
2) a delegate declaration "delegate C DF (B b);"
3) a function with signature "D F (A a);"

According to C# syntax and semantics, an instance of the delegate DF
cannot be created from the function F, as the parameter types and the
return type do not match the delegate declaration.

I would argue that from formal language type theory, it should be
possible, because of polymorphism.

Suppose this hypothetic code:

{
DF d = new DF(F);

B b = new ...

C c = d(b);
}

I have no reasons to believe that such code should break. In fact:

1) d is an instance of DF using function F

2) d is called with parameter b which is of type B, which derives from
A,
therefore F can be called itself with b

3) d's result is assigned to c, which is of type C, which type D derives
from. Because F returns D, it's result is assignable to C-typed
objects...

In summary I would argue that it is type-safe to allow this. Further I
don't think that it adds any further complexity in the language and it
is something worth having. I personally expected to see it there, was
disappointed when it I did not, and I have needed it a number of times.

One fact that confirms my thesis is that if we write the following
function:

C auxF (B b)
{
return F(b);
}

The new auxF is compatible with the delegate and does exactly what we
want.
To refine my question further I would say: Why do we need auxF???

Please find a "working" C# program below that illustrates the issue!

Please outline the reasons for which this is not part of the C#
language.
Do not hesitate to contact me personally if you need more information
regarding this question.

Best Regards,
Kamen Yotov
ka***@yotov.org
http://yotov.org

using System;

class A {}
class B: A {}
class C {}
class D: C {}

delegate C DF (B b);

class Run
{
static D F (A a)
{
return new D();
}

static C auxF (B b) // I would like to get rid of this function
{
return F(b);
}

static void Main(string[] args)
{
DF d = new DF(auxF); // I want "new DF(F)" here!
B b = new B();

Console.WriteLi ne(d(b));
}
}

[Daniel O'Connell [C# MVP]]

"Bruno Jouhier [MVP]" <bj******@clu b-internet.fr> wrote in message
news:%2******** ********@TK2MSF TNGP09.phx.gbl. ..

Ooop, my post is not very clear. You should read:

1) a class relationships A -> B and C -> D
2) a base method BM with signature "C M(B b);"
3) an override OM with signature "D M(A a);"

Typical example is the Object/Factory pattern where you have two parallel
hierarchies: BaseObject, DerivedObject on one side and BaseFactory,
DerivedFactory on the other side. You want to define
BaseFactory GetFactory() in the BaseObject class
and override it as:
DerivedFactory GetFactory() in the DerivedObject class

There are ways around it (with the "new" keyword) but things would be
cleaner if the type system was a bit smarter.

Frankly, why are you using a derived factory system if the derived class
needs to be cast to to use it? You should be designing the system to rely on
the functionality of C, otherwise I really don't think there is much point
to a base class.
By using casts and implicit knowledge of type, you break most of the
benifits of using a factory system, where in you shouldn't have to need to
know the exact type of the object, just that it derives from your target
object or implements a given interface. If D provides all the functionality,
then shouldn't D be the base class? If you know you are always going to be
using D, why bother with a factory? Outside of perhaps the base class
providing strong caching or something(gener ics should help with this), I see
little need for derivation in your situation.
Can you explain this to me in more detail?
Note: GetFactory() can be replaced by a get-only Factory property, this does not change the point above. On the other hand, we cannot make the property
get/set because then we have a typing problem on the set (the override set
accessor has a more restrictive signature than the base accessor).

Bruno

"Bruno Jouhier [MVP]" <bj******@clu b-internet.fr> a $BqD(Brit dans le message de news:%2******** **********@TK2M SFTNGP10.phx.gb l...

Makes sense. This does not create any hole in the type system and it could be handy in some cases.

The same reasoning could be applied to overrides:

1) a class relationships A -> B and C -> D
2) a base method with signature "C BM(B b);"
3) an override with signature "D OM(A a);"

Why doesn't C# let you override BM with OM in this case? Quite often, I
would like to do this, especially replacing the return type (C) by a more specialized one (D) into the override, but I cannot do it, I am forced to use C as return type and then my code is polluted by (D) casts.

To me, this is more rigorous than the following:

A[] aArray = new B[10];

which will let you store objects that don't derive from B into aArray. The compiler allows it and you get a runtime exception!

Bruno.

"Kamen Yotov" <ka***@yotov.or g> a $BqD(Brit dans le message de
news:eY******** ******@TK2MSFTN GP09.phx.gbl...

hi all,
i first posted this on
http://msdn.microsoft.com/vcsharp/te...k/default.aspx
(ask a c# language designer) a couple of days ago, but no response so

far...

therefore, i am pasting it here as well... enjoy!

(you can skip to the source at the end of the message if you like...)

Consider:

1) a class relationships A -> B and C -> D
2) a delegate declaration "delegate C DF (B b);"
3) a function with signature "D F (A a);"

According to C# syntax and semantics, an instance of the delegate DF
cannot be created from the function F, as the parameter types and the
return type do not match the delegate declaration.

I would argue that from formal language type theory, it should be
possible, because of polymorphism.

Suppose this hypothetic code:

{
DF d = new DF(F);

B b = new ...

C c = d(b);
}

I have no reasons to believe that such code should break. In fact:

1) d is an instance of DF using function F

2) d is called with parameter b which is of type B, which derives from
A,
therefore F can be called itself with b

3) d's result is assigned to c, which is of type C, which type D derives from. Because F returns D, it's result is assignable to C-typed
objects...

In summary I would argue that it is type-safe to allow this. Further I
don't think that it adds any further complexity in the language and it
is something worth having. I personally expected to see it there, was
disappointed when it I did not, and I have needed it a number of times.
One fact that confirms my thesis is that if we write the following
function:

C auxF (B b)
{
return F(b);
}

The new auxF is compatible with the delegate and does exactly what we
want.
To refine my question further I would say: Why do we need auxF???

Please find a "working" C# program below that illustrates the issue!

Please outline the reasons for which this is not part of the C#
language.
Do not hesitate to contact me personally if you need more information
regarding this question.

Best Regards,
Kamen Yotov
ka***@yotov.org
http://yotov.org

using System;

class A {}
class B: A {}
class C {}
class D: C {}

delegate C DF (B b);

class Run
{
static D F (A a)
{
return new D();
}

static C auxF (B b) // I would like to get rid of this function
{
return F(b);
}

static void Main(string[] args)
{
DF d = new DF(auxF); // I want "new DF(F)" here!
B b = new B();

Console.WriteLi ne(d(b));
}
}

[Eric Gunnerson [MS]]

This is usually known as "delegate contravariance" (assuming I've got my co
and contras correct today (covariance would be on the return type)), and
while it isn't supported in C# now, it may show up in the future.

--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://weblogs.asp.net/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.
"Kamen Yotov" <ka***@yotov.or g> wrote in message
news:eY******** ******@TK2MSFTN GP09.phx.gbl...

hi all,
i first posted this on
http://msdn.microsoft.com/vcsharp/te...k/default.aspx
(ask a c# language designer) a couple of days ago, but no response so far... therefore, i am pasting it here as well... enjoy!

(you can skip to the source at the end of the message if you like...)

Consider:

1) a class relationships A -> B and C -> D
2) a delegate declaration "delegate C DF (B b);"
3) a function with signature "D F (A a);"

According to C# syntax and semantics, an instance of the delegate DF
cannot be created from the function F, as the parameter types and the
return type do not match the delegate declaration.

I would argue that from formal language type theory, it should be
possible, because of polymorphism.

Suppose this hypothetic code:

{
DF d = new DF(F);

B b = new ...

C c = d(b);
}

I have no reasons to believe that such code should break. In fact:

1) d is an instance of DF using function F

2) d is called with parameter b which is of type B, which derives from
A,
therefore F can be called itself with b

3) d's result is assigned to c, which is of type C, which type D derives
from. Because F returns D, it's result is assignable to C-typed
objects...

In summary I would argue that it is type-safe to allow this. Further I
don't think that it adds any further complexity in the language and it
is something worth having. I personally expected to see it there, was
disappointed when it I did not, and I have needed it a number of times.

One fact that confirms my thesis is that if we write the following
function:

C auxF (B b)
{
return F(b);
}

The new auxF is compatible with the delegate and does exactly what we
want.
To refine my question further I would say: Why do we need auxF???

Please find a "working" C# program below that illustrates the issue!

Please outline the reasons for which this is not part of the C#
language.
Do not hesitate to contact me personally if you need more information
regarding this question.

Best Regards,
Kamen Yotov
ka***@yotov.org
http://yotov.org

using System;

class A {}
class B: A {}
class C {}
class D: C {}

delegate C DF (B b);

class Run
{
static D F (A a)
{
return new D();
}

static C auxF (B b) // I would like to get rid of this function
{
return F(b);
}

static void Main(string[] args)
{
DF d = new DF(auxF); // I want "new DF(F)" here!
B b = new B();

Console.WriteLi ne(d(b));
}
}

[Kamen Yotov]

There is a misunderstandin g.
When I say "A -> B", I mean "B derives from A".
It is not possible "A -> B" and "Q -> B", at least in C#.
Let me know if you still thing you have a case...

Kamen

"Stephen Martin" <sm*****@remove this.emsoft.and this.ca> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. ..

While the return type doesn't present a problem since type D is always also type C, the input parameter is a problem. Your delegate DF is a guarantee
that you can call that method with a parameter of type B or any subclass of B.

If I have type Q -> B and you pass me a delegate d of type DF but it can
only accept a parameter of type A then it will compile fine but when I try
to invoke the delegate with a parameter of type Q I will get a nasty runtime error because you've broken the contract that I can use any subclass of B
with that delegate.

There is also a similar problem with overrides. The base class guarantees
that the method can be called with any subclass of the parameter type but
the override narrows that guarantee so the method can no longer be used
polymorphically .

I think that overriding the return types is simpler since it doesn't, in
fact, violate the interface contract and I'm sure overriding the parameter
types could be done but I'm not sure it would be desirable and I don't think it would be simple.

"Kamen Yotov" <ka***@yotov.or g> wrote in message
news:eY******** ******@TK2MSFTN GP09.phx.gbl...

hi all,
i first posted this on
http://msdn.microsoft.com/vcsharp/te...k/default.aspx
(ask a c# language designer) a couple of days ago, but no response so

far...

therefore, i am pasting it here as well... enjoy!

(you can skip to the source at the end of the message if you like...)

Consider:

1) a class relationships A -> B and C -> D
2) a delegate declaration "delegate C DF (B b);"
3) a function with signature "D F (A a);"

According to C# syntax and semantics, an instance of the delegate DF
cannot be created from the function F, as the parameter types and the
return type do not match the delegate declaration.

I would argue that from formal language type theory, it should be
possible, because of polymorphism.

Suppose this hypothetic code:

{
DF d = new DF(F);

B b = new ...

C c = d(b);
}

I have no reasons to believe that such code should break. In fact:

1) d is an instance of DF using function F

2) d is called with parameter b which is of type B, which derives from
A,
therefore F can be called itself with b

3) d's result is assigned to c, which is of type C, which type D derives
from. Because F returns D, it's result is assignable to C-typed
objects...

In summary I would argue that it is type-safe to allow this. Further I
don't think that it adds any further complexity in the language and it
is something worth having. I personally expected to see it there, was
disappointed when it I did not, and I have needed it a number of times.

One fact that confirms my thesis is that if we write the following
function:

C auxF (B b)
{
return F(b);
}

The new auxF is compatible with the delegate and does exactly what we
want.
To refine my question further I would say: Why do we need auxF???

Please find a "working" C# program below that illustrates the issue!

Please outline the reasons for which this is not part of the C#
language.
Do not hesitate to contact me personally if you need more information
regarding this question.

Best Regards,
Kamen Yotov
ka***@yotov.org
http://yotov.org

using System;

class A {}
class B: A {}
class C {}
class D: C {}

delegate C DF (B b);

class Run
{
static D F (A a)
{
return new D();
}

static C auxF (B b) // I would like to get rid of this function
{
return F(b);
}

static void Main(string[] args)
{
DF d = new DF(auxF); // I want "new DF(F)" here!
B b = new B();

Console.WriteLi ne(d(b));
}
}

[Stephen Martin]

Hi,

My apologies, I tend to read this type of thing using the UML standard with
the arrow pointing to the base class. So, I thought you were arguing for
parameter covariance something I generally believe to be a very poor idea.

"Kamen Yotov" <ka***@yotov.or g> wrote in message
news:%2******** ********@TK2MSF TNGP10.phx.gbl. ..

There is a misunderstandin g.
When I say "A -> B", I mean "B derives from A".
It is not possible "A -> B" and "Q -> B", at least in C#.
Let me know if you still thing you have a case...

Kamen
<snip>

[Bruno Jouhier [MVP]]

> Frankly, why are you using a derived factory system if the derived class

needs to be cast to to use it? You should be designing the system to rely on the functionality of C, otherwise I really don't think there is much point
to a base class.
By using casts and implicit knowledge of type, you break most of the
benifits of using a factory system, where in you shouldn't have to need to
know the exact type of the object, just that it derives from your target
object or implements a given interface. If D provides all the functionality, then shouldn't D be the base class? If you know you are always going to be
using D, why bother with a factory? Outside of perhaps the base class
providing strong caching or something(gener ics should help with this), I see little need for derivation in your situation.
Can you explain this to me in more detail?

My factories do a lot more than instanciate objects, they also hold a wealth
of meta information about the objects (more than I could reasonably encode
in attributes, which is why I introduced Factory classes).
Then, I use these factories in two contexts:

1) In BaseObject, I have generic methods that operate on objects by
accessing the meta information that I can find in their factory. So, these
methods call baseObject.GetF actory() to get the BaseFactory, and then they
use the meta information of the BaseFactory to their job in a very generic
way. At this level, I don't have any casts and I don't have any "implicit
knowledge" of the type.

2) In DerivedObject, I have specialized methods that are implemented by
passing a piece of meta information that I get from DerivedFactory to a
generic method implemented at the BaseObject level. A typical example is:

public string Foo { return
GetStringValue( ((DerivedFactor y)GetFactory()) .FooProperty); }
// GetStringValue is a generic method inherited from BaseObject
// FooProperty is a piece of meta information that I find in
DerivedFactory but not in BaseFactory.

So, here, inside DerivedObject, I still need to access the factory, but this
time, I need to get the "derived" factory, not the base factory. So, I would
be really nice if I could override GetFactory() as:

public DerivedFactory GetFactory() { return
(DerivedFactory )base.GetFactor y(); }

I hope that this example will explain why it may be interesting to have an
override that "casts" in a subclass. The intent is not to use it at the base
level (which would be against good OO programming practices), but to use it
at the derived level.

In fact, C# lets me redefine GetFactory() as returning DerivedFactory in the
DerivedObject class but I have to use the "new" keyword to keep the C#
compiler happy. I find it a bit strange that I have to use new here, because
the method of the derived class has basically the same semantics as the
method of the base class (it returns the object's factory), and new is
supposed to solve the case where you have a name clash but the methods have
different semantics.

The real fix to this would be to have a more advanced typing system. You
should be able to say that:
BaseFactory is Factory<BaseObj ect>
DerivedFactory is Factory<Derived Object>
T.GetFactory() returns Factory<T>

Current C# does not let you do that. I hope that Whidbey generics will let
us do it, but I have not tested this yet.

In any case, I think that the point made by Kamen Yotof is very valid. From
a theoretical standpoint, there is no reason to reject the type
compatibility rule that he is proposing because this rule does not create
any hole in the type system, and this rule could be extended to "overrides" .
But there are probably some "practical" issues that led the C# designer to
stick to a much stricter rule.

Bruno.

[Daniel O'Connell [C# MVP]]

"Bruno Jouhier [MVP]" <bj******@clu b-internet.fr> wrote in message
news:eO******** *****@TK2MSFTNG P12.phx.gbl...

Frankly, why are you using a derived factory system if the derived class
needs to be cast to to use it? You should be designing the system to rely

on

the functionality of C, otherwise I really don't think there is much

point to a base class.
By using casts and implicit knowledge of type, you break most of the
benifits of using a factory system, where in you shouldn't have to need to know the exact type of the object, just that it derives from your target
object or implements a given interface. If D provides all the

functionality,

then shouldn't D be the base class? If you know you are always going to be using D, why bother with a factory? Outside of perhaps the base class
providing strong caching or something(gener ics should help with this), I

see

little need for derivation in your situation.
Can you explain this to me in more detail?

My factories do a lot more than instanciate objects, they also hold a

wealth of meta information about the objects (more than I could reasonably encode
in attributes, which is why I introduced Factory classes).
Then, I use these factories in two contexts:

1) In BaseObject, I have generic methods that operate on objects by
accessing the meta information that I can find in their factory. So, these
methods call baseObject.GetF actory() to get the BaseFactory, and then they
use the meta information of the BaseFactory to their job in a very generic
way. At this level, I don't have any casts and I don't have any "implicit
knowledge" of the type.

2) In DerivedObject, I have specialized methods that are implemented by
passing a piece of meta information that I get from DerivedFactory to a
generic method implemented at the BaseObject level. A typical example is:

public string Foo { return
GetStringValue( ((DerivedFactor y)GetFactory()) .FooProperty); }
// GetStringValue is a generic method inherited from BaseObject
// FooProperty is a piece of meta information that I find in
DerivedFactory but not in BaseFactory.

So, here, inside DerivedObject, I still need to access the factory, but this time, I need to get the "derived" factory, not the base factory. So, I would be really nice if I could override GetFactory() as:

public DerivedFactory GetFactory() { return
(DerivedFactory )base.GetFactor y(); }

I hope that this example will explain why it may be interesting to have an
override that "casts" in a subclass. The intent is not to use it at the base level (which would be against good OO programming practices), but to use it at the derived level.

In fact, C# lets me redefine GetFactory() as returning DerivedFactory in the DerivedObject class but I have to use the "new" keyword to keep the C#
compiler happy. I find it a bit strange that I have to use new here, because the method of the derived class has basically the same semantics as the
method of the base class (it returns the object's factory), and new is
supposed to solve the case where you have a name clash but the methods have different semantics.

The real fix to this would be to have a more advanced typing system. You
should be able to say that:
BaseFactory is Factory<BaseObj ect>
DerivedFactory is Factory<Derived Object>
T.GetFactory() returns Factory<T>
This does sound like a generic factory more than a what I suspected(I would
actually probably not derive the factory itself, just the functionality
needed). but this should work, basically

public class BaseFactory<T> : Factory<T>
where T : BaseClass
{

}

public class DerivedFactory< T> : BaseFactory<T>
where T : DerivedClass
{

}

Should be sufficent. Its not perfect but it is possible. Current C# does not let you do that. I hope that Whidbey generics will let
us do it, but I have not tested this yet.

In any case, I think that the point made by Kamen Yotof is very valid. From a theoretical standpoint, there is no reason to reject the type
compatibility rule that he is proposing because this rule does not create
any hole in the type system, and this rule could be extended to "overrides" . But there are probably some "practical" issues that led the C# designer to
stick to a much stricter rule.
Its more simplicity. It makes it easier to work with the language as a
whole.
Bruno.