Properties of Interfaces

  • Thread starter Thread starter Tony Nassar
  • Start date Start date
T

Tony Nassar

Could someone clarify why this doesn't work? Is there a persuasive reason
why it shouldn't?

interface IGetOnly {
string Name { get; }
}

interface IGetAndSet : IGetOnly {
string Name { set; }
}

It should be clear what I want to do here: extend the interface IGetOnly
with a setter. I know that the getter is implemented as get_Name, but I then
have a class that implements IGetAndSet, it does *not* have a getter. If I
add a getter to the second interface declaration, I have a conflict over
"Name", which I have to resolve by using "new." But the getter isn't new! I
can declare get_Name and set_Name directly, but that doesn't work (I'll
spare the readers the details).
 
I can verify that I too have run into something very similar (and I wouldn't
be surprised if it's the same underlying cause) but I can't really give you
a good reason why it's this way. It's likely there is either a good reason
or it's simply the by-product of the implementation.

My guess is that it's something along the lines of a signature for the
properties is created in the base interface and the derived interface is
breaking that signature.

Sorry, not much help, am I?

Pete
 
Tony,
In Interface extensions, we may add more methods and even new property
skeletons, but we cannot mask off (override) an existing function and
replace it with extra functionality.
We want to achieve:
interface IGetAndSet {
string Name{get;set;}
}
The intention of having "Name{get;}" member now changed to "Name{get;set;}"
is not exactly and extention, but a signature replacement of existing
Interface member.
Thanks,
Fakher Halim
 
I find this explanation completely unpersuasive; it merely reiterates what
the compiler told me. We all know that the "Name" property becomes
get_Name() in the IL; extending the interface with set_Name() would be no
problem IF THE LANGUAGE DESIGNERS HAD ALLOWED IT.
 
Tony,

I think this is by design and correct. What the get_XXX in the IL really
means is "read-only." So, the OO theory says that you wouldn't want derived
classes to alter the semantics of the read-only XXX property, right?

The get_ and put_ methods are just implementation details that express in IL
what the design intent (read-only) is, right? So, if the designer intended
read-only, you wouldn't want to allow derived classes to override that
intent, right?

In your case, I think requiring the "new" keyword is correct, because the
base classes, already being written--possibly by someone else--don't know
anything about the new semantics you want to give the already existing XXX
property.

Hope this helps/makes sense,

-Jason
 
That *is* persuasive; thank you.

Tony

Mailing Lists said:
Tony,

I think this is by design and correct. What the get_XXX in the IL really
means is "read-only." So, the OO theory says that you wouldn't want derived
classes to alter the semantics of the read-only XXX property, right?

The get_ and put_ methods are just implementation details that express in IL
what the design intent (read-only) is, right? So, if the designer intended
read-only, you wouldn't want to allow derived classes to override that
intent, right?

In your case, I think requiring the "new" keyword is correct, because the
base classes, already being written--possibly by someone else--don't know
anything about the new semantics you want to give the already existing XXX
property.

Hope this helps/makes sense,

-Jason
Click to expand...
 
Wait a minute, that's not correct. If get_Name() returns a reference to an
object of reference type, then it is not a read-only reference. Compare

interface IReadOnly {
IList MyList { get; }
}

The return value is in no sense "read-only." It's not a C++-style reference
to const. I cannot overwrite the object's reference to an IList (that would
require a setter), but I can insert into and delete from the object's IList
to my heart's content. Unless of course the object implementing IReadOnly
copies the array, etc., etc., but that's an implementation detail
independent of the interface contract.

Tony
 
Back
Top