We Keep Coding

C# - When i try to create constructor, i get CS7036 error

Firstly, sorry for my English. I hope i can explain my problem.
I have class like this
public class CarCommandExecutorBase
{
protected readonly ICarCommand CarCommand;
public CarCommandExecutorBase(ICarCommand carCommand)
{
CarCommand = carCommand;
}
}
Also i have class like this
public class CarStringCommandExecutor : CarCommandExecutorBase, IStringCommand
{
public CarStringCommandExecutor(Car car)
{
// this Constructor gives me an error.
}
public void ExecuteCommand(string commandObject)
{
}
}
Error message:
[![error][1]][1]
What's the reason and how can i fix it? Thanks.

Since the only constructor in CarCommandExecutorBase is defined like this
public CarCommandExecutorBase(ICarCommand carCommand)
{
CarCommand = carCommand;
}
you have to pass an ICarCommand when creating an instance of CarCommandExecutorBase.
You have to provide an ICarCommand through the constructor of CarStringCommandExecutor, because when instantiating a derived type the base constructor(s) also get called.
See this answer for more detailed information about this: https://stackoverflow.com/a/1882778/8450550
You could do something like this to solve this error:
public class CarStringCommandExecutor : CarCommandExecutorBase, IStringCommand
{
...
public CarStringCommandExecutor(Car car, ICarCommand carCommand)
: base(carCommand) // base() points to the constructor of the base class
{
...
}
or maybe this
public class CarStringCommandExecutor : CarCommandExecutorBase, IStringCommand
{
...
public CarStringCommandExecutor(Car car)
: base(null) // passing null but be aware of NullReferenceExceptions
{
...
}
or you add another constructor to CarCommandExecutorBase which expects no arguments:
public class CarCommandExecutorBase
{
protected readonly ICarCommand CarCommand;
public CarCommandExecutorBase(ICarCommand carCommand)
{
CarCommand = carCommand;
}
// mark this constructor as protected, so only deriving types can call it
protected CarCommandExecutorBase()
{
}
}
Which solution works best in your case is up to you.

One of the things that isn't immediately apparent, thanks to "compiler magic", about a C# class is that every class has a constructor
It needs to be this way because it's a rule that object construction happens in a tree; you construct some class Z which inherits from Y which inherits from X which inherits from object, and Z's cosntructor invokes Y's invokes X's invokes object's, then they finish, in order of object, X, Y, Z and you have your nicely constructed thing - every constructor on the way up the tree had its chance to do its init and ready the object for use (the part of it that each constructor was responsible for)
Even classes that don't seem to have constructors, have constructors:
class X {
}
If you don't provide a constructor, C# provides one for you. You never see it in your source code; just imagine that in between reading the file and compiling it, the compiler inserts it for you. It takes no parameters, has no code, and does nothing other than call its base:
class X {
X():base() { } //C# invisibly writes this for you
}
If you provide a constructor but don't write the base... bit, C# puts base() in for you behind the scenes (and it always calls the no-argument base()) but critically it doesn't provide an empty constructor if you provided one already
This means if you have a class like:
class X{
X(string message){
...
}
}
Your class X has a constructor, so C# won't provide the empty one, so now anything that tries to construct your class must provide a string message:
X x = new X("hello");
If you now inherit from X, you might do one of 3 things (with Y):
class Y:X{
}
You don't add a constructor, C# adds one, but it just dumbly calls base(), which doesn't work because there is no constructor in X that takes no args:
class Y:X{
Y():base() { }
}
You add a constructor but leave off the base bit. C# adds it, again just literally as base() - this also doesn't work for the same reason
class Y:X{
Y(int myArg) //c# adds base() in here for you
{
...
}
}
You add a constructor that includes a call to base and because you know your base class only has a constructor with a string arg, you pass one:
class Y:X{
Y(int myArg) : base("hello")
{
...
}
}
So you're in scenario 2, and you either need to:
Add a no-arg constructor to the base class so that c#'s auto-inserted stuff works or,
Add a call to base(...) with a suitable argument, to stop C# from putting a base() in
I've left out access modifiers from code in this answer for clarity of demonstrating the essential point. Whether a constructor is accessible or not can also have a bearing on all this, but I deemed it out of scope

Why are these two methods not ambiguous?

This is the signature for the Ok() method in ApiController:
protected internal virtual OkResult Ok();
And this is my method from my RestController class (which extends from ApiController):
// Note that I'm not overriding base method
protected IHttpActionResult Ok(string message = null);
Since OkResult implements IHttpActionResult, both of these methods can be called like this:
IHttpActionResult result = Ok();
In fact, that's what I'm doing in my application.
My class PersistenceRestController (which extends from RestController), has these lines of code:
protected override async Task<IHttpActionResult> Delete(Key id)
{
bool deleted = //... Attempts to delete entity
if(deleted) return Ok();
else return NotFound();
}
This compiles fine, and no warning is raised about method ambiguity. Why is that?
PersistenceRestController has also inherited the protected methods from ApiController so it should have both versions of Ok() (and it does).
At execution, the method executed is the one from my RestController.
How does the compiler know which method to run?

Jon Skeet answered a similar question (without the inheritance complication) here:
When the compiler has two otherwise-equal options to choose from, it will use an overload which doesn't need use any unsupplied optional parameters in preference to one that does...
In your case, however, the method from the RestController is being chosen because it's the more derived class. Jon does a good job of addressing the topic in detail in his book C# in Depth -- look at the inheritance section of that page, which essentially states that the compiler will prefer a method on the actual instance class before methods on less derived classes.

EDIT:
I am leaving my original answer for posterity because I think it lets you visualize things, but DO NOT BE CONFUSED! The compiler does not actually treat the optional parameter as syntactic sugar for an overridden method. It treats it as a single method with an optional parameter. Dusty's answer, mentioning that "the method from the RestController is being chosen because it's the more derived class," is correct.
ORIGINAL (With visible edits for correctness):
Because they are NOT ambiguous. In order to be ambiguous the methods need to have the same signature. The fact that the string message parameter has a default value of null effectively creates BEHAVES as though it creates two callable overrides, one of which HIDES the original method, and one of which is distinctly callable with a string.
You are effectively doing creating the same behavior as if you were to do this:
public class RestController : ApiController
{
protected new OkResult Ok()
{
return Ok(null);
}
protected OkResult Ok(string message)
{
// Do your thing...
}
}
You will find there is no way to directly call ApiController.Ok() from PersistenceRestController.
If you want to call ApiController.Ok() from RestController, you'll have to use the base keywoard: base.Ok();

While #DimitarTsonev and #Dusty are telling true stuffs, but your answer is something between their answers. Here, you have inheritance situation. See these classes:
public class Foo {
public void Bar() {
}
}
public class Foo2 : Foo{
public void Bar(string message = null) {
}
}
public class Foo3 : Foo2{
public void Test(){
Bar();
}
}
When you call Bar() in your Foo3 class, the runtime will lookup after the method inside the Foo3 class. If found it, execute it, otherwise go to the top class: Foo2 and look after Bar method. Is there any? yes! so execute it! that's why when you call Ok, your RestControllers' version get executed.
But also, the Foo2.Bar(string message = null) will not conflict with Foo.Bar() because they are NOT ambiguous as #DimitarTsonev said. So, your code will work just fine.
AND, what about calling Foo.Bar() from Foo3? You have to use casting here:
public class Foo3 : Foo2 {
public void Test() {
Bar(); // this will execute Foo2.Bar()
}
public void Test2() {
((Foo)this).Bar(); // this one will execute Foo.Bar()
}
}

public class Foo
{
public void Bar()
{
}
public void Bar(string message = null)
{
}
}
Those are two different methods because the second has the optional argument.
However, please note that the second method called with no arguments will actually execute the first one, which may produce some unexpected behaviour.

Call abstract method from class constructor

I have base class that contain abstract method.
public abstract class ClassBase : IClassBase
{
protected ClassBase()
{
//// some code
}
protected ClassBase(XmlNode settings)
: this()
{
}
protected abstract void Init(XmlNode settings);
}
public class Class_A : ClassBase
{
public Class_A(XmlNode settings)
: this(settings)
{
Init(settings);
}
protected override void Init(XmlNode settings)
{
}
}
Is it ok to call the Init method from Class_A constructor ?
I try to do it and its run ok - but when the constructor is running the virtual tables are not ready yet and the abstract method are not ready as far as i know.

It's unclear exactly what code you meant, as the code you've given doesn't compile for a couple of reasons. Most importantly, did you actually mean to call Init from ClassBase rather than from Class_A? If not, it seems pointless making Init abstract. This answer assumes you did meant that.
Is it ok to call the Init method from Class_A constructor ?
It's valid - but it's not usually a good idea.
It's not a matter of the "virtual tables" no being created - that's fine, and it will execute Class_A.Init. An object is created as an instance of its eventual type immediately. The problem is that you're calling a method on the Class_A instance before its constructor has had a chance to execute. That means it may be in an unexpected state - normal preconditions may not hold, for example.
Example
public class Class_A : ClassBase
{
private readonly string text;
public Class_A(XmlNode settings, string text)
: base(settings) // Which calls Init(settings) as per intro paragraph
{
if (text == null)
{
throw new ArgumentNullException("text");
}
this.text = text;
}
protected override void Init(XmlNode settings)
{
// In here, text is still null... even though it can't be in any
// other method.
}
}
Just occasionally, it's the least worst solution, but in that case:
Really make sure there isn't a better solution
Document it very clearly
Avoid calling the method from anywhere else, as it's often odd to code an implementation which is appropriate in both "I'm half way through initialization" and "I'm fully initialized" states.

How to prevent shadowing and promote given method?

In C++ it is done with "using", and in C#?
public class foo
{
public void print(string s) {...}
}
public class bar : foo
{
// shadowing
public void print(object o) {...}
}
How to promote foo.print, so foo.print and bar.print would be at the same "level" for compiler (for bar of course)?
Update 1
Originally I added a paragraph about common confusion between shadowing and overriding, but then I deleted it, because I thought it will be offensive to readers.
Shadowing is like overloading spanned over inheritance tree. Shadowing is NOT overriding.
Update 2
After shadowing foo.print is no longer taken into account when resolving the overloaded method print. Promoting foo.print would get it back into process -- so when I call bar_object.print("hello") the method foo.print would be called.

In your concrete example, bar.print(object) indeed "shadows" the more specific foo.print(string):
new bar().print("i am a string");
This will call the method defined on bar, although the method on foo would have a parameter that matches the type better.
What happens here is the following: The compiler finds a method on bar with the right name ("print"), the right number of parameters (1) and a parameter type to which the passed in parameter is convertable to (string can be converted to object).
Because of this, there is no reason for the compiler to look further up the inheritance chain.
As far as I am aware, there is no construct similar to C++'s using.
If you want to use the method defined on the base class, you basically have three options:
On the caller side: Convert the bar instance to foo:
var bar = new bar();
var foo = (foo)bar;
foo.print("i am a string"); // Will call foo.print(string)
On the calee side: Inside bar.print(object) check the type of the passed parameter:
public void print(object o)
{
var s = o as string;
if(s != null)
base.print(s);
else
{
// Other code.
}
}
This will come the closest to the C++ using: Actually override or hide the original method in the derived class:
public class bar : foo
{
public new void print(string s)
{
base.print(s);
}
public void print(object o)
{
// some code
}
}

How to return value from C# partial method?

Is there a way to do so as it seems partial method must return void (I really don't understand this limitation but let it be) ?

Well, technically you can "return" a value from a partial method, but it has to be through a ref argument, so it's quite awkward:
partial void Foo(ref int result);
partial void Foo(ref int result)
{
result = 42;
}
public void Test()
{
int i = 0;
Foo(ref i);
// 'i' is 42.
}
In that example, the value of i won't change if Foo() is not implemented.

From MSDN:
Partial method declarations must begin with the contextual keyword partial and the method must return void.
Partial methods can have ref but not out parameters.
So the answer is no, you can't.
Perhaps if you explain a bit more about your situation (why you need to return a value, why the class is partial), we can provide a workaround.

You cannot return a value from a partial method.
Partial methods may or may not be implemented. If it were permitted to return a value from such a method, then what would the caller receive?

The reason for the restriction is this line from MSDN:
A partial class or struct may contain
a partial method. One part of the
class contains the signature of the
method. An optional implementation may
be defined in the same part or another
part. If the implementation is not
supplied, then the method and all
calls to the method are removed at
compile time. -- Emphasis Mine
If the method may not be implemented and can be removed. What would happen to its return value if the call is removed?
As to your question of a work around, that depends on what you are trying to do, but obviously you can't use a partial method.

Oh. Once I had to do this in a project of mine.
You can throw an exception in your method called ReturnValueException which you define as an exception that has an object property named ReturnedValue. Now you can call your method Foo() inside a try block and collect the results in the catch block.
No.. just kidding.
Don't do that. Ever.

Here's a technique relying on the fact that an extension method will be shadowed by a class method.
It's more involved and less clear than the ref parameter technique, so I'll use that instead.
Several shadowing mechanisms in C# could be used instead: using static vs. method, a parent class containing just the default behaviour vs. a new method, a method accepting a dummy object vs. a method with a more specific argument type etc.
The choice between the extension method or the class method when it is present is made at compile-time (that is, it doesn't use late binding). This can lead to some problems if your partial class is not sealed: if you override the customizable method with an implementation which is also customizable, you need to use a fresh interface and extension method
https://repl.it/#suzannesoy/WorthwhileSplendidBotany#main.cs
// On the auto-generated side:
interface IDefaultFoo { int DefaultFoo(); }
static class DefaultFoo {
public static int CustomFoo(this IDefaultFoo o) => o.DefaultFoo();
}
partial class PartialClass : IDefaultFoo {
int IDefaultFoo.DefaultFoo() => 42;
// mark as virtual if you want to override in subclasses too.
public virtual int Foo() => this.CustomFoo();
}
// On the user side:
partial class PartialClass {
// Define this method only if you want to change
// the default implementation of Foo.
public int CustomFoo() => 123;
}
// In subclasses use override on the Foo method as usual
class SubClass1 : PartialClass {
public new int CustomFoo() => 666; // This is not used
public override int Foo() => 999; // Use this instead
}
// If you also want to override in the subclass with a method which
// is also customizable, i.e. to provide a new default behaviour in
// the partial subclass that could also be customized, you'll need
// to add a new interface etc. otherwise the CustomFoo from the
// parent class would be called because it still shadows the
// extension method.
interface IDefaultFooSub2 { int DefaultFoo(); }
static class DefaultFooSub2 {
public static int CustomFooSub2(this IDefaultFooSub2 o) => o.DefaultFoo();
}
partial class SubClass2 : PartialClass, IDefaultFooSub2 {
int IDefaultFooSub2.DefaultFoo() => 1000000;
public override int Foo() => this.CustomFooSub2();
}
class MainClass {
public static void Main (string[] args) {
System.Console.WriteLine(new PartialClass().Foo()); // 123
System.Console.WriteLine(new SubClass1().Foo()); // 999
System.Console.WriteLine(new SubClass2().Foo()); // 1000000
System.Console.WriteLine(((PartialClass)new SubClass2()).Foo()); // 1000000
}
}