Sorry, forgot the :) on the "syntactic sugar" remark ... > 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
Sorry, forgot the :) on the "syntactic sugar" remark ... > 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. Yes, but as I was trying to point out, the issue here is understanding what it means to implement an interface -- as in "fulfilling a contract." In that sense, it really doesn't matter *how* you are storing "what is actually retrieved." So, the point was that if the interface only provides a getter, providing a setter seems to violate the contract. Otherwise, I completely agree with your remarks regarding properties and class inheritance. John > > Charlie Poole > [EMAIL PROTECTED] > www.pooleconsulting.com > www.charliepoole.org > You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
