John, > Sorry, forgot the :) on the "syntactic sugar" remark ...
Not sure I would have interpreted it correctly anyway. > > 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 ... Not sure... :-) > > 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. I think we're probably in complete agreement and I just didn't express myself clearly. I was expanding on your point about interfaces. What I'm saying is that adding an entirely different function to the object that implements an interface is the way to go if you need to provide the additional functionality that the OP tried to get by just adding in a setter. That leaves the interface intact and only clients that use implementing class by name will be able to access the functionality. This is a common pattern, when a factory object needs to set up an object correctly before returning the interface. 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.
