We Keep Coding

Accessibility on interfaces

With the recent changes to interfaces that came in C# 8.0, I'm a little confused about how the accessibilities are supposed to work (which are now valid on interfaces, they didn't used to be).
This seemingly simple example does not work as you'd expect:
public interface IFoo
{
public string Bar { get; internal set; }
}
public class Foo : IFoo
{
public string Bar { get; internal set; } //Error - Non-public accessor "Bar.set" cannot implement accessor from interface IFoo
}
The only "working" code I can seem to get for the IFoo interface is this:
public interface IFoo
{
public string Bar { get; internal set; }
}
public class Foo : IFoo
{
string IFoo.Bar { get; set; }
}
In other words, the interface must be implemented explicitly.
Why is the first example invalid? Why does this situation require explicit implementation?

My explanation, with some conjecture on my side:
There's an old rule that if you'd rather not implement an interface member as a public class member, then you must use explicit implementation. This allows to make prescribed interface members "hard to access" because in your implementation they are not suitable for public usage. Note that even then the implementation remains public.
This also seems to apply to interface parts that can now declare themselves with less-than-public visibility, it now seems to be: any member of an interface that *isn't fully public* or that you *don't want to implement as public* must use explicit implementation. Note: I have no source for this, I distilled it from what I see is happening.
Since your property is only "half public", apparently all of it falls under that rule.
Then there is another rule, quoting from the documentation:
An explicit interface implementation doesn't have an access modifier since it isn't accessible as a member of the type it's defined in. Instead, it's only accessible when called through an instance of the interface.
This explains why as soon as you use explicit implementation (forced or not), you can't add access modifiers of your own because the interface defines the applicable access modifiers (with public being the default if omitted).
Consequences of doing this
To access even the public getter, all client code needs to use IFoo:
var f = new Foo(); var x = ((IFoo)f).Bar; // works
IFoo f = new Foo(); var x = f.Bar; // works
var x = new Foo().Bar; // does not compile
It's up to you to decide if it is worth to force this requirement onto your callers.
If needed then I see two ways to avoid that requirement, first way means leaving the internal setter out of the interface and only put it in Foo, but then code using the setter must use Foo as the variable type, it can't use IFoo, while code using the getter can do whatever it likes:
public interface IFoo
{
public string Bar { get; } // no setter (and you can omit `public`)
}
public class Foo : IFoo
{
public string Bar { get; internal set; } // add internal setter as class member
}
Second way, having an internal void SetBar(string value) in the interface, now all code using SetBar() must use IFoo as the variable type, and code using the getter can do whatever it likes:
public interface IFoo
{
public string Bar { get; }
internal void SetBar(string value);
}
public class Foo : IFoo
{
public string Bar { get; private set; } // add private setter as class member
void IFoo.SetBar(string value) { Bar = value; } // use private setter
}

How to redefine a property in C# through interface inheritance?

I have an interface 'IBase' that specifies a nullable int. A later interface 'IDerived' hides the nullable int and 'redefines' it as non-nullable.
interface IBase
{
int? Redefineable { get; set; }
}
interface IDerived : IBase
{
new int Redefineable { get; set; }
}
The class that implements these interfaces must explicitly implement the hidden property, however it's private so the client can't see it.
class TheClass : IDerived
{
public int Redefineable { get; set; }
int? IBase.Redefineable { get; set; }
}
However, even though it's a private property, I can still access it through the IBase interface!
var o = new TheClass();
o.Redefineable = 1; // ok
var hack = o as IBase;
hack.Redefineable = null; // uh!
This seems like some kind of violation of C# access modifiers, but either way it isn't really what I had in mind for redefining (not just hiding) a property. It's correct in the sense that it does what you're asking, get an IBase interface which has a nullable int but this is non-intuitive to the client who could then modify the wrong version of the property.
What I really want, is that if the client accesses IBase.Redefinable, then it behaves as if it's accessing the IDerived.Redefinable property, the 'real' property of TheClass. That way it's actually redefined, as in back through the hierarchy.
class TheClass : IDerived
{
public int Redefineable { get; set; }
int? IBase.Redefineable {
get {
// redirect to redefined property
return this.Redefineable;
}
set
{
// stop client setting it to null
if (!value.HasValue)
throw new InvalidOperationException();
// redirect to redefined property
this.Redefineable = value.Value;
}
}
}
This just feels like a hack, almost as if I'm missing something, so I want to ask if anyone knows a better/alternative way to implement re-definable properties?

However, even though it's a private property, I can still access it through the IBase interface!
It's not a private property. It's just a property using explicit interface implementation. That means it's public through the interface, but only available through the interface. Explicit interface implementation is mostly designed to make it feasible to implement "contradictory" interfaces, as well as being used to "discourage" (but not prohibit) the use of some interface methods. It's not meant to give the impression that the members don't exist at all.
Fundamentally, it sounds like you shouldn't be using inheritance here - if you don't want something to be able to act as an IBase, you shouldn't inherit from IBase.

Reflection, dynamic. How to replace one object with another?

I have an object like this
public class Simple
{
public string Value
{
get { return GetProperty(); }
}
// different methods, fields, events, etc.
}
Possible to replace instance of the class Simple with equal object, but with setter?
How to implement ...
private object Substitution(object simple)
{
object newSimple;
// implementations
newSimple.Value = "data";
return newSimple;
}
To have something like this
public class Simple
{
public string Value { get; set; }
// my methods, fields, events ...
}
I thought to create a class and inherit from SystemObject, then you can create different dynamic properties, but could not do :(
Or maybe try to inherit from this object (how?) and override the properties?
Thanks

You can't change the definition or structure of a loaded type at runtime.
You could, potentially, make a new type that had a similar set of properties and fields, with the property setter added. However, this is going to be of limited use in most cases, as the existing code will not understand the new type (since it's runtime generated), so would still be working off the existing type, which won't be compatible.
Typically, if you need runtime extensibility within a type, there are other options, including using a Dictionary<T,U>, or dynamic with ExpandoObject, or some other mechanism for storing "extra" information within a class that is not known at compile time.

You couuld always use an interface, that only defines a property getter. Then in the implementation have a property setter?
class Program
{
static void Main(string[] args)
{
IMyClass myA = new ClassA{ Property = "Class A" };
Console.WriteLine(myA.Property);
// can't do this
// myA.Property = "New Property";
// can do this
(myA as ClassA).Property = "New Property";
Console.WriteLine(myA.Property);
}
}
interface IMyClass
{
string Property { get; }
}
class ClassA : IMyClass
{
public string Property { get; set; }
}
Failing that, you could do an user defined conversion using the explicit keyword, more info at MSDN

How to hide set method of an implemented property from an interface in C#?

Greetings everyone...
If I have the following interface:
interface IMyInterface
{
int property { get; set; }
}
And the following implementation:
class MyClass : IMyInterface
{
// anything
}
How can I hide the set method of property from the instances of MyClass... In other words, I don't want the set method of property to be public, is that possible?
It would be easy to do with abstract class:
abstract class IMyInterface
{
int property { get; protected set; }
}
Then I could only set the property within the class that implements the abstract class above...

Don't have the set in the interface to begin with. You can still implement it as private.
You can't "hide" it, it's part of the contract. If you don't want it to be part of the contract, don't define it.

If you use the following interface the set method will be unavailable when classes are manipulated via the interface:
interface IMyInterface
{
int property { get; }
}
You could then implement the class like this:
class MyClass : IMyInterface
{
int property { get; protected set; }
}

If some implementations will only implement some parts of an interface, it may be a good idea to subdivide the interface into the parts which each implementation will either implement completely or not at all, and then define interfaces which inherit all the common combinations of them. Adapting your example:
interface IMyReadableInterface
{
int property { get; }
}
interface IMyFullInterface : IMyReadableInterface
{
new int property { get; set; }
}
Classes which want to support read-write access should implement IMyFullInterface; those which want to only support read access should only implement IMyReadableInterface. This segregation will not require any extra work for implementations of either interface which are written in C# and implement property implicitly. Code which implements property in VB, or explicitly implements property in C#, will have to define two implementations of property--a read-only one and a read-write one, but such is life. Note that while one could define an IMyWritableInterface which just had a setter, and have IMyFullInterface inherit both IMyReadableInterface and IMyWritableInterface, IMyFullInterface would still have to define a read-write property of its own, and when using explicit implementation one would then have to define three properties (I really don't understand why C# can't use a read-only and write-only property together as thought they were a read-write property, but it can't).

Assuming you need the setter to be part of the interface but for some reason it does not make sense for it to be used on a particular implementer (in this case MyClass) you can always throw an exception in the setter (such as an InvalidOperationException). This will not protect you at compile time, only at run time. It is a bit strange though, as code that operates on the interface has no idea whether calling the setter is allowed.

There are certainly cases where you want the interface to have a set and then hide it in some concrete class.
I believe the code below shows what we want to accomplish. I.e. the implementation hides the setter, but any IMyInterface aware component will have access to it.
public static void Main()
{
var myClass = new MyClass();
myClass.Property = 123; // Error
((IMyInterface)myClass).Property = 123; // OK
}
It's basically the same pattern you often see for IDisposable.Dispose() where you have an Explicit Interface Implementation. Here's an example for completeness.
public interface IMyInterface
{
int Property { get; set; }
}
public class MyClass : IMyInterface, IDisposable
{
public int Property { get; private set; }
int IMyInterface.Property
{
get => Property;
set => Property = value;
}
void IDisposable.Dispose() {}
}
Too much typing :(
C# doesn't help us much here. Ideally, it would be possible to have an explicit interface implementation for the setter:
// In C# 10 maybe we can do this instead:
public class MyFutureClass : IMyInterface
{
public int Property { get; IMyInterface.set; }
}
See C# feature proposal here.

There is no protected or private in interface, everything is public. Either you don't define any set or use it as public.

Why can't a list of Interfaces use an implementing type?

There must be something fundamental about interfaces/generics I have not yet learned. I hope to learn it now.
Here is the scenario:
I have this interface and class:
public interface IInterface
{
string TestValue { get; set; }
}
public class RealValue: IInterface
{
public string TestValue { get; set; }
}
If I create a method like this it compiles just fine:
public class RandomTest: IMethodInterface
{
public IInterface GetRealValue()
{
RealValue realValue = new RealValue();
return realValue;
}
}
Note that I am returning an object that implements the interface.
Now, if I add to the RandomTest class a method that returns list then it does not work anymore:
public List<IInterface> GetRealValues()
{
List<RealValue> realValues = new List<RealValue>();
return realValues; // ERROR Here <- says it can't convert to a List<IInterface>
}
So, my guess is that generics can't figure this out, but why?
Is there a way around this? What do you do when the return value of the method above is locked because you are implementing an interface like this:
public interface IMethodInterface
{
IInterface GetRealValue();
List<IInterface> GetRealValues(); // Can't just convert the return types to a concrete
// class because I am implementing this. This
// interface is in a separate project that does not
// have the concrete classes.
}
Is there any hope? What would you do?

The reason for this is that List<RealValue> is a specific type, which does not inherit List<IInterface>, so it cannot be converted.
However, in .NET 4.0 you're in luck. The interface IEnumerable<out T> specifies that T can be the class, or a base class, so you can change your method to:
IEnumerable<IInterface> GetRealValues();
on .NET 4.0. Note that this only works because IEnumerable has the out keyword specified on the template parameter.
The out keyword means two things:
The type before which you put the out keyword can only be used for types that go out of the class. So, public T MyMethod() is allowed, but public void MyMethod(T myParam) is not allowed, because this goes into the class;
Because of this restriction, .NET knows that T can be cased to everything that inherits from T. Because of the restriction, this is guaranteed to be a safe operation.

Note that if you could convert List<RealValue> to List<IInterface> you could call .Add(anyObjectImplementingIInterface) which cannot work.
You can, however, use .Cast<IInterface>().ToList().

A List<RealValue> cannot be used in place of a List<IInterface>. If it was permitted, the caller would be able to Add an IInterface to the returned list that is of a type other than RealValue.