[C#] Override a property.. ARGH!

Dj_Jestar

Dj_Jestar

Dj_Jestar

Caporegime
Joined
18 Oct 2002
Posts
29,493
Location
Back in East London
I'm overriding a property. Well, trying to.

Code: 
namespace Foo {
  public class A {
    public TypeA property = new TypeA();
  }

  public void SetSomething(string foo)
  {
    property.blah = foo;
  }
}

namespace Bar {
  public class B : Foo.A {
    public TypeB property = new TypeB();
  }
}

Bar.B foo = new Bar.B();
foo.SetSomething("woowoo");
if (foo.property.blah == null)
{
  // yes, it's null. :(
}

What the deuce?
 
Last edited:
I've been reading through those already, but given what I have builds and runs (but just not with the desired behaviour) I don't see your point of there being a syntax error?

Basically, I'm wanting to override the type of the property. Along with the B extending A, the properties are also subclasses of each other (i.e. TypeB extends TypeA to add extra properties.)

Simply put, declaring an override property on a subclass does not override, it adds another property with the same name - just not on base. The methods/accessors/mutators whatever on base will not use the property of the subclass. Stupid. Why would you *ever* want to do that?
 
Last edited:
Public fields is indeed what I mean. :)

I'm looking those links now, thanks... but I do find it amazing that something so simple has to be so difficult. :) -1 to type strict languages again :p
 
Nah, all I want to do is override the type assigned to a field. If it were not type-strict, it would be sans problem. :)
 
No, the problem is specifically because there are two objects/classes that are identical for all but two fields, hence the extension in the first place, but they do not implement this arbitrary thing called an Interface, despite their actual interface (as in, they have the same methods and properties - just different fields) being identical. Infact the two classes are even called exactly the same thing, just different namespaces.

In C# this "limitation" means that the base class methods, when accessed via a derived object, will update/interact with the derived object properties - at least, it should. It doesn't. The object maintains two instances of the field; one on base, one on the derived class that at first glance appears to be a wrapper on the base class, instead of an extended instance like it should be - and I might add, every other language manages.

I've read Buu Nguyen's blog on this very subject, and it leaves me thinking "So, you've disallowed covariance/contravariance simply because you don't want developers to cause an error in their code.. who the hell are you you patronise so blatantly?" :)

I'm going to bleat about Smalltalk again, because quite frankly it rocks (:p) and has been doing what .NET (and Java) have been unable to do for 50 years; it sensibly handles these kinds of problems by allowing you, the developer, to shoot yourself in the foot every now and then, and to actually learn from it. :) This error/problem with .NET does nothing of the sort, it just leaves me confused, and asking "What they hell were they thinking?" :)
 
Last edited:
The interface is extended. ClassA's interface is in tact, and ClassB extends it; the member type that I wish to override (which I'll dub InterfaceA) in ClassA is with a type that is an extension of InterfaceA (ingeniously dubbed InterfaceB)

The interface, according to the base methods and properties, is un changed. The derived class will use the extended member methods and properties, whilst the base members will be unchanged. Simply because the objects I am using do not have "InterfaceB : InterfaceA" it is not allowed. This is a hinderance, and only one that is achieved via a type-strict language :)

I do have a certian dislike for type-strict languages. The perfect example being this very problem, which is not even a concern in dynamic typed languages. It just simply does not happen with issue, it just works. If an object responds to a method, it should answer it. Not fail to compile because I did not apply an arbitray piece of code telling everything that it should. :)
 
Ultimately it comes down to this. Type strict language developers (ala Buu Nguyen, one of the authors of C# for those that do not know) have imposed these restrictions "to protect developers" ... from their own mistakes, or to be more exact, from the failings of the language in question. So you, as a developer, must adhere to their frame of mind when developing. I strongly disagree with anyone who thinks this is anything but patronisation. :)
 
NathanE said:
Then continue developing in Smalltalk or produce your own language?

It comes down to the simple concept of... "using the correct tool for the job".
Click to expand...

Not an option unfortunately. In this case, the right tool for the job is one that will translate from a WSDL web service to a COM library (via Interop)

Don't even get me started on the politics of that, and the very fact that Interop is there as a work around to the original faults of MS products :p
 
Inquisitor said:
I'm not quite sure what you're trying to say here, but I think you're misunderstanding the nature of polymorphism in .NET. Fields are intentionally not polymorphic in a statically typed language because it doesn't make sense for them to be unless they're either read-only or write-only.
Click to expand...
They are place holders for values.. ergo, variables. :)
The field on the derived class is hiding the field in the base class because in a statically typed language it is not possible to override it. This is not a limitation of static typing, but a semantic problem with what you're trying to do.
Click to expand...
It's a semantic problem of not being able to do what I need to do. The extended/derived class is extending/deriving from the base class purely because of the need for that field to be of different type. All base functionality is identical, it is simply extended upon. Both by the derived class, and that of the type which is being overriden.
I'm not even sure what you'd be trying to achieve by overriding the field in a dynamically typed language anyway; there is no type specification on the field, so what is there to override? :confused:
Click to expand...
I place my baggage on the floor, for a break. :)
Still, though, I'm not sure why you can't see the semantic problems with your goal. As I've said, static typing not only mandates type consistency, but it also introduces the notion of semantic consistency, which isn't present with dynamic typing. In specifying the type of a member, you're also – to some extent – specifying what it is and what it should do, which is why consistency is so important.
Click to expand...
That's the crux of my argument/rant. I don't care what it should do, I don't care what it is called. If I want it to quack, and it quacks, then I don't care if it's a goose, duck, swan, or even an Elephant - just as long as it quacks when I want it to. :)
Again, I can't say I've ever come across typing problems like this in C#. Maybe your dynamic typing just makes you more lax in your approach to OOP :p
Click to expand...
Anything but :)
Well that's just how nominal subtyping and statically typed languages work, sorry :/

Returning to the original problem, though, if the field is read-only, then you can make it a property with only a get accessor and then hide the base property with the the derived class's property using the new keyword. You'll have to use coercion in the deriving property, but it'll behave exactly as it would if it were truly polymorphic (as long as you don't change the implementation).

P.S. static typing also allows for awesome IntelliSense support :cool:
Click to expand...
There are other ways to get IntelliSense outside of static typing. Again, more evangelism, Smalltalk has done just fine with this for years. :)
 
Inquisitor said:
I don't think this is really going anywhere!
Click to expand...
I agree, I don't think it is either, but it's a healthy discussion, even if it does not provide a conclusion, it may help others come to their own. :)
Well I care: what if an elephant's quack has catastrophic (or worse: subtly incorrect) consequences? I just prefer to know in advance if this might happen.
Click to expand...
How is an arbitrary interface going to stop that? If both elephant and duck implement "public void Quack()" and "IQuackable" how is that so safe against not implementing any thing and being dynamic? :)

There's no right answer here. You just don't like this particular typing system, while I (and many others) do. Sucks for you I guess?
Click to expand...
That it does, whilst it also sucks for anyone else wanting to override the type on a property/field between types that do not have a parent interface. I'm above certain I'm not the only one. :)
I'm not arguing against dynamic typing; indeed I use it on a daily basis and it works fine for me. In fact your own evangelism of Smalltalk has made me quite keen to try it out, but unfortunately my host doesn't support Seaside, and I can't see it surpassing C# for Windows app development, if only for C#'s ease of use, seemless integration with Windows, and support from MS.
Click to expand...
I'm glad you were tempted :) Yes, there is not much support for Seaside - and on a side note there is free hosting for non-commerical site at http://www.seasidehosting.st :)

Maybe it's because I'm very mathematically-minded, but I just find the rigourous nature of static typing to be natural and "right". Programming of any kind is closely linked to type theory, which is an aspect of maths. Maths is intrinsically strict in this respect, and so as I see it a program shouldn't compile if it's not consistent.
Click to expand...
Now we're getting somewhere with this discussion. :) I'm not a mathematical minded person other than I am a very logical man. If something is going to break, I want it to break, so I can fix and learn. I do not want something to always alert me long in advance. This of course only applies to software, if I were building a house or something that's a different story entirely. As far as software is concerned, there is so much that cannot be detected at compile time (in terms of desired behaviour) then why even bother with such fallacies (in this case at least) as inconsistency - an inconsistency which is *purely* based on two of my objects not implementing an arbitrary label. :)
Besides, at the end of the day, you're the one who's attacking static typing and evangelizing your preferred typing system, not me!
Click to expand...
I was actually only mentioning Smalltalk because frankly, it's the best I've ever used and ever likely to use. I really don't mean to start a comparison war, this is not what this thread is about. :) I actually do want to find a solution to this problem! :)
 
The intention of an interface is to contractually oblige a (or more than one) behaviour; but in reality it's not that - it's literally just a spec of what methods and/or properties must be available; I could put any behaviour I like behind it and still satisfy the interface. Bad practice, of course, but I think it's a bit zealous to call them contracts (by anyone and everyone, not just you!) :)

I'm certain others have this problem. It is simply a problem because we are using two separate WSDL services for the same (overall) system, one that is an extension of the behaviour of the other, but (of course) can only reference them via the "Service Reference" names and as such, different namespaces. The classes even have the same name, and the same interface - merely a different namespace.
 
Last edited:
Different namespaces :) Which are via the different service references. One is available to the parent, the other to the child. I.e. The crux of the problem (other than inability to override a fields type by extension :p)
 
Last edited:
Heed some advice yourself, I am a fully fledged OO Developer in a fulltime Development role. I am the lead developer and contributor for SSpec - a Behaviour Driven Design framework, sister project of RSpec, and an actual pioneering project in the Development world as far as Testing goes. I have been developing for nearly 9 years, and make a tidy sum from it.

I am questioning one of the very aspects of C#'s behviour-by-design aspects. Of which, after seeing from links found on Google and posted by others in this thread, has been addressed by the authors of C#. In other words, they agree with me.

So, here's some more advice just for you: leave this thread.

Yes, I've just been watching Scrubs and wish I was just like Dr. Cox
 
P.S. Inquisitor - I removed the code samples because they were not representative of the issue. :) I've re-read my OP and amended below to be more true to the real code (unfortunately I cannot post directly, as it is under NDA from Royal Mail :p):

ClassA.cs:
Code: 
using ServiceReferenceOne.TypeA;

namespace NamespaceA
{
  public class ClassA
  {
    public TypeA property = new TypeA();

    public void SetSomething(string foo)
    {
      property.blah = foo;
    }
  }
}

ClassB.cs
Code: 
using ServiceReferenceTwo.TypeA;
using NamespaceA;

namespace NamespaceB
{
  public class ClassB : ClassA
  {
    new public TypeA property = new TypeA();
  }
}
Elsewhere:
Code: 
using NamespaceB;
using ServiceReferenceTwo;

public class Foo
{
  public static void Main(string[] args)
  {
    ClassB foo = new ClassB();
    foo.SetSomething("woowoo");
    if (foo.property.blah == null)
    {
      /*
       * yes, it's null. :( but on inspection during debug,
       * "woowoo" *is* stored, but on base.property - not on the 'new' property.
       */
    }
  }
}
I've fully qualified the TypeA usings merely to highlight they are from different service references. Take note that SetSomething only interacts with base.property, not on the 'new' property.

Also; PsychoDuck - I just spotted the syntax error you mentioned :)
 
Last edited:
There was a hidden message, visible in the quote :) I had literally that second just stopped watching Scrubs with an excellent rant from Dr. Cox. :)

I was inspired. He is my idol. If it were biologically possible, I'd have his babies.
 
You must log in or register to reply here.
Back
Top Bottom