-1

I have an interface

public interface IIntf { string Foo { get; set; } }

and a class

class MyClass : IIntf
{
    public string Foo { get; private set; }
}

. Now I get the compiler error

'MyClass' does not implement interface member 'IIntf.Foo.set'. 'MyClass.Foo.set' is not public.

So it seems that Foo.set is its own entity somehow (and Foo.get analogously). Can I do anything with them? If yes, what?

E.g. I tried implementing the missing setter property by using Foo.set - it was even suggested by Visual Studio

enter image description here

but I did not find any syntax that works. When following the suggestion and trying to implement the Foo.set method (without corresponding get because I have that already), I get a different type of compiler error:

enter image description here

But since Visual Studio shows (and, at times, suggests while typing code) Foo.set and Foo.get, I assume that something can be done with them. Any ideas what? Maybe some nice way of redirecting methods to only the getter / only the setter? Or something else?

mjwills
  • 23,389
  • 6
  • 40
  • 63
Kjara
  • 2,504
  • 15
  • 42
  • You can not implement the partial behavior of interface. So if you are implementing property of interface implicitly or explicitly, it has to be the same as it is declared in the interface. – Chetan Dec 07 '18 at 12:14
  • @mjwills Again: My question is not about `IIntf`, `MyClass`, `Foo`. I used this setup solely to 1. show that .get and .set exist as individual entities (in some way) and 2. to illustrate ONE situation where it could be useful to use them (if it is possible): to declate a getter or setter without its corresponding partner. My question is just: **What can I do with the entities `.get` and `.set`? Can I even do anything with them?** (Are they just methods that I can declare or pass around? Are they anything else? What exactly are they?) – Kjara Dec 07 '18 at 12:27
  • 1
    I don't know why Visual Studio is showing `Foo.get` and `Foo.set`. The code generated by using them isn't valid C# code, so I would call it a bug. – Dirk Dec 07 '18 at 12:28
  • 1
    `What can I do with the entities .get and .set?` In practice, nothing. `Are they just methods that I can declare or pass around?` Yes, you could use reflection to get those methods and pass them around. – mjwills Dec 07 '18 at 12:30
  • @mjwills Interesting: the accepted answer in the link you gave says "Yes, the compiler generates a pair of get and set methods for a property". But if that was really just methods, I would be able to write `Func f = Foo.get`. But It gives a compile error. – Kjara Dec 07 '18 at 12:41
  • `But if that was really just methods` See https://dotnetfiddle.net/1uLhbg . They definitely are methods. – mjwills Dec 07 '18 at 12:53
  • 1
    I think its simply a Visual Studio bug, even displaying this options to you. Try to understand how Properties work. There is no need to define the setter and getter separately, since you could simply call a method in the Property block ```{ get{return Dostuff();} set{DoStuff2(value);}}``` For everything else: use reflection. There is no magical something to find here. – FrankM Dec 07 '18 at 13:18

2 Answers2

3

Dealing with the issues / questions that @Kjara has raised in the comments:

  1. Properties are implemented using get and set methods behind the scenes (by the compiler).
  2. You cannot easily access / pass around these methods (without reflection).
  3. When define properties, you must define the get and set at the same time (you can't define the get on one line and the set on another).
  4. As per @FrankM and @Dirk above - the confusion here appears to stem from the fact that the IDE implies (falsely) that you can define the getter and setter separately.
mjwills
  • 23,389
  • 6
  • 40
  • 63
-2

Like this

public class MyClass : IIntf
{
    public string Foo { get; private set; }
    string IIntf.Foo { get => Foo; set => Foo = value; }
}
Wanton
  • 800
  • 6
  • 9