Daniel
Fri Mar 10 15:03:32 CST 2006
"Axel Dahmen" <NO_SPAM@NoOneKnows.invalid> wrote in message
news:%23gsncDHRGHA.1728@TK2MSFTNGP11.phx.gbl...
>> Add copy constructors and you have a whole host of things that have to be
>> figured out. Are they allowed strictly for upcasting?
>
> Well, it would help a great deal if at least upcasting was possible. Just
> adding a couple of member functions to a base class (by creating a derived
> class with no new fields) should not throw an InvalidCastException.
>
It would be nice ocassionally, but I don't think its worth the
compiler\language complexity nor does it seem like something that would be
used consistently. I'm quite sure you should be able to work around it
easily.
>
>> What if their are new fields?
>
> Like I said in one of my previous posts: If there are no new fields, then
> upcasting will not be a problem because there's nothing added to the
> object.
> This option should be available automatically using no copy constructor.
>
That isn't the point. It adds complexity. What if there are new fields? What
errors should the compiler emit? How do you make it simple and easy for
everyone to understand? How do you do it in a language independent manner(or
do you?) Is it valuable across a wide range of users? Its alot to consider
for a feature that may only be really useful to C++ developers that dabble
in C# and occasionally useful to the regular C# dev.
> If there are new fields introduced by the deriving class then an explicit
> constructor is required, utilizing a copy constructor, provided by .NET,
> like:
>
>
> public MyDerivedClass(MyBaseClass baseClass) : base(baseClass)
> {
> ...
> }
>
>
> plus explicit conversion operator, like:
>
> public static explicit operator MyDerivedClass (MyBaseClass baseClass)
> {
> return new MyDerivedClass(baseClass);
> }
>
>
>> How does the compiler deal with dataloss?
>
> There is no dataloss.
I dislike explicit operators and copy constructors both, so I don't like
this much. Not only does it rewrite some base rules, it has some potential
problems, which I'll address later.
There could also be data loss, quite easily. Consider this scenario which
illustrates why you can't convert a base type to a derived type and where
dataloss can occur:
Considering these classes:
class MyBaseClass
{
string stringA;
}
class MyDerivedClass : MyBaseClass
{
void NewMethod();
}
class MyDerivedClass2 : MyBaseClass
{
string apple;
}
how does this code work out?
MyBaseClass mbc = new MyDerivedClass2();
MyDerivedClass mdc = <MyDerivedClass>mbc;
The copy constructor can lose data and the user wouldn't be able to tell,
especially if MyDerivedClass2 is returned by another component instead of
being constructed right there. You could use a runtime error, but that will
eventually just come down ontop of the end user. It's to easy to mess this
up, probably worse than casting as it stands, which is pretty messy, IMHO.
Someone else will just have the same problem you are, just in a slightly
different way. Language features like this should really be resolvable at
compile time, IMHO.
>> In your case, I get the impression you just want another view. A copy
> isn't
>> the right thing to do here, IMHO, since you are wasting memory and
>> complicating state management(assuming there *is* state management) for
>> no
>> clear reason. Encapsulation would probably be my first thought(and that
>> would get you over the explicit conversion problem).
>
> No...
>
> a) encapsulation (=aggregation) will add unnecessary overhead to my
> implementation as I would need to provide each and every functionality
> from
> the base class in my derived class just to call my encapsulated member.
>
> b) I can't downcast if I just encapsulate. I need to derive from a base
> class.
You appear to only have one dataset. It'd be pretty simple to build a series
of explicit conversions or constructors from the dataset class to the
functionality class instead of up and down casting.
FilterXClass fxc = new FilterXClass(data);
Also, out of curiosity, have you looked into the proposed extension methods
from C# 3.0[1]? Assuming they survive into the final product, you'd be able
to sort of paste on methods from other classes based on using statements
instead of having to cast around for new functionality. Its kinda ugly, but
it is a possiblity.
1.
http://dotnet.org.za/ernst/archive/2005/11/19/48385.aspx