Develop Reference

In C# 8.0 is there a way to expose default member implementation on the class?

In C# 8.0 interfaces can have default implementations for some members. These implementations are explicit meaning that they are inaccessible through the class instance and we must cast to the interface type to call them. Is there a way to expose this implementation on the class instance with the same name? It is possible to expose it under another name by casting the this pointer to the interface type and calling the method like:
void A()
{
((ISomething)this).B();
}
However I can't seem to find a way to expose the implementation with the original name of B because if I declare a method B it counts as the one implementing the interface which causes infinite recursion. Is there some way to expose the implementation without copying it or there is something I am missing?
To clarify, I am looking for a way to achieve traits-like functionality i.e. being able to import the implementation from the interface directly into the class's public API without changing the method name (presumably the name in the interface was the best one). The question is not about how to call the method as a user of the class but how to make it part of the public API of the class.
Extension methods are one solution but default interface implementations have access to protected members and can be overloaded.

One possibility is to provide properties for them. This is what I do when I need to refer to explicit implementations from within the class.
class Something : IInterfaceA, IInterfaceB {
public IInterfaceA A => this;
public IInterfaceB B => this;
}
...
something.A.AMethod();
something.B.BMethod();
You might also consider using extension methods instead of default implementations. They are somewhat similar anyway.
interface IInterface {
}
static class IInterfaceExtensions {
public static void DoSomething(
this IInterface me
) {
// do something
}
}

There's no simple way to do it; various ugly workarounds are possible that all boil down to delegating to some other method (a static method or relying on a helper class that doesn't itself implemented the method) to access it, and even then you need to pass in state somehow. There's a proposal for a base(T) syntax, draft specification here, which should allow base(ISomething).B() to refer to the implementation without causing a cyclic reference. This was originally slated to be part of C# 8, but this proved to be too ambitious and it was cut. As of writing, it's a candidate for inclusion in C# 9.

How Can I have abstract parameters in method?

Basiclly I have a class like Individual and another class that inherits from it - IndividualForSomeAnotherWork.
I have a class called Population too and methods like Add(Individual individual).
Can I pass the IndividualForSomeAnotherWork to Add method through Individual type? Or should I use interface or abstract class? I'm asking because I'm getting NullReferenceException all the time.
EDIT:
Sorry for not answering so long. My problem was not initializing a List containing objects so I couldn't add to it. But I also wanted to know that can I pass arguments as I said earlier. Thanks for answers.

I would recommend an IIndividual type of interface. In this case, if you have:
abstract class Individual : IIndividual {
}
class IndividualForSomeOtherWork : Individual {
}
... then Population.Add(IIndividual Individual) will accept the base class Individual as well as any descendants of Individual.
Think of the interface as a contract with the Population class that any individual within it's collection will have implemented all the functions it requires of the individual.
Note that the abstract Individual is not required to implement all functions defined within the interface. If the interface requires:
interface IIndividual {
void DoWork();
}
... then the base Individual is not knowledgeable of what specialized work an IndividualForSomeOtherWork will actually perform. So in the abstract class:
abstract void DoWork();
This function must be defined within the specialized individual descendants.

Yes, you can pass an IndividualForSomeAnotherWork to Add(Individual individual). It should work correctly. Your error is due to something else. Try debugging it yourself, or post more details and code and we might be able to help.

In terms of what you are trying to do here, an abstract class is not fundamentally different from an interface. In both cases it's not possible to have a argument whose type exactly matches the type of the formal parameter. See DrawImage for an explicit example of this (Image is an abstract class).
The NullReferenceException you are seeing is not directly related to the parameter type being abstract.

Does a types accessibility depend on the file it's contained in?

If I declare an interface, or a type as private in one file, is it private to that file or the namespace?
The compiler generates an error for File2: 'Error 14 Inconsistent accessibility: parameter type 'DIDemo1.IImageRepository' is less accessible than method 'DIDemo1.ImageGetter.ImageGetter(DIDemo1.IImageRepository)'
What I don't understand is that MyClass can use the interface but ImageGetter class cannot.
File1:
namespace DIDemo1 {
interface IImageRepository {
Image[] GetImages();
}
public class MyClass : IImageRepository {
#region IImageRepository Members
public Image[] GetImages() {
return new Image[] { };
}
#endregion
}
}
File2:
namespace DIDemo1 {
public class ImageGetter {
IImageRepository _repo;
public ImageGetter(IImageRepository repository) {
_repo = repository;
}
public Image[] GetImages() {
return _repo.GetImages();
}
}
}

Since you did not specify an access modifier for your interface, it defaults to internal, which is lower than public. That means only code in the same assembly are aware of its existence.
A public class can implement an internal interface, because other code inside that same assembly would see your class with the interface, and code outside would simply see the public class, with no interface.
However, in File2, you are making an internal interface part of that class' public contract - that is, your class is public, which means any code can see it, but in order to use it they must also be able to understand the types in the constructor. Since one of the types required in the constructor is internal, external code cannot understand it, and this contract is impossible to fulfill.

What I don't understand is that MyClass can use the interface but ImageGetter class cannot.
ImageGetter can use the interface, it just can't present it in one of its method signatures which are more accessible. Likewise if MyClass tried to use it in one of its method signatures you'd get the same error. Read below.
Top level interfaces, structs, and classes default to internal access. To fix your problem put public before your interface declaration.
internal types in C# are accessible only within the same assembly.
You can't use a more restrictive access modifier in a less restrictive signature for obvious reasons. (How could someone who can't access the more restrictive type call the function for example?)

No, which file the code is in is irrelevant. The interface is private to the namespace, not the file.
The error message is not because the ImageGetter class can't reach the interface, it's because the class can't be used from outside the namespace.
The difference lies in how you use the interface. The class MyClass only implements the interface, so you can still use the class even if you can't use the interface. The constructor in the ImageGetter class requires a reference to the interface, so you can't use that class without also having access to the interface.

Interfaces and classes default to internal accessibility (because there is no concept of a class being private inside a namespace). The error explains what happens there - IImageRepository is less accessible (it is internal) than ImageGetter constructor, which exposes IImageRepository as a parameter.
Basically a public method on ImageGetter exposes a type that is internal. This is not allowed in C#.

C# class design - what can I use instead of "static abstract"?

I want to do the following
public abstract class MyAbstractClass
{
public static abstract int MagicId
{
get;
}
public static void DoSomeMagic()
{
// Need to get the MagicId value defined in the concrete implementation
}
}
public class MyConcreteClass : MyAbstractClass
{
public static override int MagicId
{
get { return 123; }
}
}
However I can't because you can't have static abstract members.
I understand why I can't do this - any recommendations for a design that will achieve much the same result?
(For clarity - I am trying to provide a library with an abstract base class but the concrete versions MUST implement a few properties/methods themselves and yes, there are good reasons for keeping it static.)

You fundamentally can't make DoSomeMagic() work with the current design. A call to MyConcreteClass.DoSomeMagic in source code will be translated into MyAbstractClasss.DoSomeMagic in the IL. The fact that it was originally called using MyConcreteClass is lost.
You might consider having a parallel class hierarchy which has the same methods but virtual - then associate each instance of the original class with an instance of the class containing the previously-static members... and there should probably only be one instance of each of those.

Would the Singleton pattern work perhaps? A link to the MSDN article describing how to implement a singleton in C#:
http://msdn.microsoft.com/en-us/library/ff650316.aspx
In your particular example, the Singelton instance could extend an abstract base class with your MagicId in it.
Just a thought :)

I would question that there are "good reasons" for making the abstract members static.
If your thinking is that these members might reflect some property of the derived class itself rather than a given instance, this does not necessarily mean the members should be static.
Consider the IList.IsFixedSize property. This is really a property of the kind of IList, not any particular instance (i.e., any T[] is going to be fixed size; it will not vary from one T[] to another). But still it should be an instance member. Why? Because since multiple types may implement IList, it will vary from one IList to another.
Consider some code that takes any MyAbstractClass (from your example). If this code is designed properly, in most cases, it should not care which derived class it is actually dealing with. What matters is whatever MyAbstractClass exposes. If you make some abstract members static, basically the only way to access them would be like this:
int magicId;
if (concreteObject is MyConcreteClass) {
magicId = MyConcreteClass.MagicId;
} else if (concreteObject is MyOtherConcreteClass) {
magicId = MyOtherConcreteClass.MagicId;
}
Why such a mess? This is much better, right?
int magicId = concreteObject.MagicId;
But perhaps you have other good reasons that haven't occurred to me.

Your best option is to use an interface with MagicId only using a setter
public interface IMagic
{
int MagicId { get; }
}
By the nature of Static meaning there can only be one (yes like Highlander) you can't override them.
Using an interface assumes your client will implement the contract. If they want to have an instance for each or return the value of a Static variable it is up to them.
The good reason for keeping things static would also mean you do NOT need to have it overridden in the child class.

Not a huge fan of this option but...
You could declare the property static, not abstract, virtual and throw a NotImplementedException which returns an error message that the method has to be overridden in a derived class.
You move the error from compile time to run time though which is kinda ugly.

Languages that implement inheritance of static members do it through metaclasses (that is, classes are also objects, and these objects have a metaclass, and static inheritance exists through it). You can vaguely transpose that to the factory pattern: one class has the magic member and can create objects of the second class.
That, or use reflection. But you can't ensure at compile-time that a derived class implements statically a certain property.

Why not just make it a non-static member?

Sounds like a Monostate, perhaps? http://c2.com/cgi/wiki?MonostatePattern

The provider pattern, used by the ASP.NET membership provider, for example, might be what you're looking for.
You cannot have polymorphic behavior on static members, so you'll have a static class whose members delegate to an interface (or abstract class) field that will encapsulate the polymorphic behaviors.

Is there any constraint to specify the access specifier of members of a class when we have specified access specifier of the class?

Suppose that we have a class named class1.
The class1 has several properties and methods and we have decided to specify the access specifier of class1 as internal.
Now, can we set the access specifier of class1 methods as public?

For your specific question, Class 1 which is declared as internal can have a public method.
Why?
Look at Jon Skeets explanation:
You can certainly mark a class as
internal, but that's different from
making its public members internal.
For instance, suppose you have a class
which implements a public interface.
Even though the class may be internal,
an instance may still "get out of the
assembly" by being returned from a
member in another (public) class. That
instance would have to be referenced
by the interface it implements rather
than the class name itself (as the
class isn't known to the outside
assembly) but the public methods can
still be called.
If the public methods aren't
implementing any interfaces, I suspect
it would only make a difference in a
very few reflection cases which you
may not care about.
community wiki - as credit should go to Jon Skeet

Yes, you can set public on members of internal/private/etc types.
As other replies have noted, external code won't be able to see the properties unless it can see the type - but there are lots of nuances:
if the member is on an interface it will be (essentially) part of the public API
the member might be a public override of a virtual/abstract member - in which case it will truly be publicly visible, but via the base-class (again, similar to interfaces)
But there is a lot of other code in the framework that uses reflection and demands public accessibility:
data binding usually works on the public properties
security checks for partial-trust can be fussy about public members
serialization (for example XmlSerializer) may want public members
etc
So there are still lots of reasons to think about public rather than just internal, even if your code is only referenced by the local assembly.

By rule access specifiers on methods and properties can not be more more accessible than that of the class containing it.
But I've tried this:
internal class Test
{
public string Testing{get;set;}
}
and it compiles without any exception! I think it is okay as the class Test will not be accessible outside the namespace assembly we have declared so public property will not make any difference.
This does not works:
private class Test
{
public string Testing{get;set;}
internal string TestingAgain{get;set;}
}