John, > I'm not sure you *should* be able to do it... To me, the original > poster's request might make more sense if it was a matter of properties > on the base class itself (a straightforward inheritance question). > > Instead, the confusion seems to be that properties (as merely > syntactically "sugar") can come in pairs -- he's put one-half on the > original interface -- shouldn't one be able to implement the other half > on the class itself? > > But if you do that, can the class still be described as implementing the > interface (since it is by definition read-only)?
I think properties are *more* than syntactic sugar - although they are often described as such. This example shows why: once you have described a property as NOT being settable, derived classes can't change that. This is similar to other aspects of inheritance such as not being able to change the type of a method when overriding, not being able to change protection levels, etc. If a derived class wants to provide a way to come in behind that property and change what is actually retrieved, it needs to add a new method to do that. The cleanest way is probably to just give the method a different name. Using "new" to hide the old property is likely to lead to confusion, since both properties continue to exist and are accessible to the outside world. Charlie Poole [EMAIL PROTECTED] www.pooleconsulting.com www.charliepoole.org > > > -----Original Message----- > > From: Moderated discussion of advanced .NET topics. [mailto:ADVANCED- > > [EMAIL PROTECTED]] On Behalf Of Ian Griffiths > > Sent: Friday, July 26, 2002 3:16 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [ADVANCED-DOTNET] Tricky little issue.. > > > > Hmm... I don't like that much. > > > > The meaning of the 'new' keyword is, approximately: "Yes I know the > base > > class defines a member of the same name. I want you to treat this as > being > > completely different, even though it has the same name." > > > > new is a C#ism. At the CLR level, the two *will* have different > names. > > IUser.IsAdministrator and SuperUser.IsAdministrator. The 'new' method > will > > also have the 'newslot' flag (I think it's called). This means that > it will > > *not* be invoked through the virtual method dispatch mechanism when > somebody > > tries to read the IUser.IsAdministrator property. > > > > In other words, 'new' is mutually incompatible with 'override'. So I > don't > > think this will do what the original poster was trying to achieve. > > > > Basically you can't do it in C#. > > > > -- > > Ian Griffiths > > DevelopMentor > > > > > > ----- Original Message ----- > > From: "Peter Lillevold" <[EMAIL PROTECTED]> > > > > > > > You will probably have to use the new keyword since adding a > set-method is > > > actually a change of the IUser interface. > > > > > > Peter Lillevold > > > > > > -----Original Message----- > > > From: Alex Henderson [mailto:[EMAIL PROTECTED]] > > > Sent: 26. juli 2002 06:51 > > > To: [EMAIL PROTECTED] > > > Subject: [ADVANCED-DOTNET] Tricky little issue.. > > > > > > > > > I've just come across this and don't really know how to syntatically > get > > > "around" it in an elegant way.. At any rate, have a look > > > > > > If (for example) I have an Interface say IUser: > > > > > > public interface IUser > > > { > > > public IsAdministrator > > > { > > > get; > > > } > > > } > > > > > > And a class that implements it: > > > > > > public class NormalUser : IUser > > > { > > > public bool IsAdministrator > > > { > > > get > > > { > > > return false; > > > } > > > } > > > } > > > > > > And then inherit from it: > > > > > > public class SuperUser : NormalUser > > > { > > > bool _isSuperUser = false; > > > public override bool IsAdminstrator > > > { > > > get > > > { > > > return _isSuperUser; > > > } > > > set > > > { > > > _isSuperUser = value; > > > } > > > } > > > } > > > > > > However I cant compile this because the set method cant override > anything: > > > > > > "SuperUser.IsAdministrator.set': cannot override because > > > 'NormalUser.IsAdministrator' does not have an overridable set > accessor. > > > > > > Is there a way to get round this (without creating a set accessor in > the > > > interface/NormalUser object and throwing an exception in it's > method) - > > > properties in reality are functions (right?) so I should be able to > do > > this > > > from the CLR's point of view. > > > > You can read messages from the Advanced DOTNET archive, unsubscribe > from > > Advanced DOTNET, or > > subscribe to other DevelopMentor lists at http://discuss.develop.com. > > You can read messages from the Advanced DOTNET archive, > unsubscribe from Advanced DOTNET, or > subscribe to other DevelopMentor lists at http://discuss.develop.com. > You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
