I had never thought of doing that! Cheers.
-----Original Message-----
From: Paul Gaske [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 30, 2002 2:56 PM
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Tricky little issue..
I'm not sure if this is of interest to you, but I just did this:
internal interface IIThing
{
int Foo { set; }
}
public interface IThing
{
int Foo { get; }
}
public class Thing : IThing, IIThing
{
int _foo = 0;
int IIThing.Foo
{
set
{
_foo = value;
}
}
int IThing.Foo
{
get
{
return _foo;
}
}
}
Then tested with this:
Thing thing = new Thing();
((IIThing)thing).Foo = 10;
Console.WriteLine(((IThing)thing).Foo.ToString());
I have a hunch that you could use this in the following manner:
interface IUser
{
bool IsAdministrator { get; }
}
interface IWriteUser
{
bool IsAdministrator { set; }
}
class User : IUser, IWriteUser
{
public bool IsAdministrator
{
get
{
return _isAdministrator;
}
}
bool IWriteUser.IsAdministrator
{
set
{
_isAdministrator = value;
}
}
}
You get a bonus in that you could even make the IWriteUser interface
internal. The only drawback is that you'd have to cast to IWriteUser before
using the set.
Ie:
bool b = user.IsAdministrator; ((IWriteUser)user).IsAdministrator = b;
Cheers,
pg
-----Original Message-----
From: Alex Henderson [mailto:[EMAIL PROTECTED]]
Sent: Monday, 29 July 2002 8:04 AM
To: [EMAIL PROTECTED]
Subject: Re: Tricky little issue..
Well I'm back (the original poster) I guess realistically It's just a matter
of defining a property - I was assuming (and I'm probably correct from a
CLR/IL point of view) that a property is a set and a get method, syntactic
sugar.
>From a C# point of view though it is obviously a commitment to providing a
single "property" with certain abilities (read/write/whatever) this is
probably reinforced by the fact that the set and get methods are all
contained within the properties declaration - showing the ownership runs a
little deeper.
However I must say that if a class supported write as well as read for a
property, this shouldn't affect the classes support for an interface that
only supports read - The class when cast to the interface would still
satisfy the interfaces requirements, and is that's whats really important?
- Alex
-----Original Message-----
From: Charlie Poole [mailto:[EMAIL PROTECTED]]
Sent: Sunday, July 28, 2002 9:31 AM
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Tricky little issue..
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.
You can read messages from the Advanced DOTNET archive, unsubscribe from
Advanced DOTNET, or subscribe to other DevelopMentor lists at
http://discuss.develop.com.
You can read messages from the Advanced DOTNET archive, unsubscribe from
Advanced DOTNET, or subscribe to other DevelopMentor lists at
http://discuss.develop.com.
You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced
DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
