An interface defines the minimum contract requirements for a class to implement it, not the maximum. Thus, if an interface only requires that a class allow an accessor to be defined for a given property, the interface does not define that the object be "read-only," but rather that the object provides a means by which to access the value of the property. If an interface defined the entire contract (no more, no less), then new methods that were not present in the interface definition would be banned from implementing classes. This restriction makes little sense.
If an object were referred to by a variable of its interface type, and this interface type specified only an accessor while the implementing class provided both accessor and mutator methods, then access to a provided mutator would be illegal. Thus the defined contract is maintained. Personally, I have thus far avoided .NET class "properties" due to their lack of conformance or similarity to method inheritance. This case is one clear instance of one of these such anomalies. Another example, which peeves me big time, is the inability to assign different visibility modifiers for accessor vs. mutator property code blocks (such as public get {} and internal set {} for the same property). While the getProperty(), setProperty(value) constructs are a bit more verbose and difficult to maintain, I find the two aforementioned deficiencies all too common to warrant the lack of consistency required to have the best of both worlds; thus I stick with the verbose method. joe -----Original Message----- From: John St. Clair [mailto:[EMAIL PROTECTED]] Sent: Friday, July 26, 2002 9:33 AM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Tricky little issue.. 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)? John You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.