Properties of Interfaces

[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).

[Pete Davis]

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

--
http://www.petedavis.net

"Tony Nassar" <tn*****@theanalysiscorp.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

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).

[Fakher Halim]

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

"Pete Davis" <pd******@hotmail.com> wrote in message
news:0e******************************@news.meganet news.com...

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

--
http://www.petedavis.net

"Tony Nassar" <tn*****@theanalysiscorp.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

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).

[Tony Nassar]

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.

The intention of having "Name{get;}" member now changed to "Name{get;set;}" is not exactly an extention, but a signature replacement of existing
Interface member.
Thanks,
Fakher Halim

[Mailing Lists]

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

"Tony Nassar" <tn*****@theanalysiscorp.com> wrote in message
news:eE**************@TK2MSFTNGP11.phx.gbl...

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.

The intention of having "Name{get;}" member now changed to

"Name{get;set;}"

is not exactly an extention, but a signature replacement of existing
Interface member.
Thanks,
Fakher Halim

[Tony Nassar]

That *is* persuasive; thank you.

Tony

"Mailing Lists" <ml******@berkea.com> wrote in message
news:eF**************@TK2MSFTNGP10.phx.gbl...

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

"Tony Nassar" <tn*****@theanalysiscorp.com> wrote in message
news:eE**************@TK2MSFTNGP11.phx.gbl...

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.

The intention of having "Name{get;}" member now changed to

"Name{get;set;}"

is not exactly an extention, but a signature replacement of existing
Interface member.
Thanks,
Fakher Halim

[Tony Nassar]

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

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

"Tony Nassar" <tn*****@theanalysiscorp.com> wrote in message
news:eE**************@TK2MSFTNGP11.phx.gbl...

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.

The intention of having "Name{get;}" member now changed to

"Name{get;set;}"

is not exactly an extention, but a signature replacement of existing
Interface member.
Thanks,
Fakher Halim