[3.0/LINQ] base class access outside method

In VB.NET you can access a base class via the MyBase keyword, and in C# it is via base keyword.

My question is, does anyone know why C# is designed in such a way that you can only access this base class variable inside a method. In VB it is within scope anywhere in the class (other than shared methods).

Code:

---

'this works
Public Class ExtendedTextbox
    Inherits System.Windows.Forms.TextBox

    Private _backColor As Color = MyBase.BackColor
End Class

//this doesn't
class ExtendedTextbox : System.Windows.Forms.TextBox
{
    private Color _backColor = base.BackColor; //ERROR ON THIS LINE
}

---

This might be completely wrong but if you use this.BackColor I think it works...?

this produces the same type of error.

this is not in scope at the class level, just as base is not.

You'll need to move the assignment into the constructor of your class.

MyBase acts as though the object has been instantiated, base does not.

Code:

---

    class ExtendedTextbox : System.Windows.Forms.TextBox
    {
        private Color _backColor;

        public ExtendedTextbox()
        {
            _backColor =  base.BackColor;
        }
    }

---

Yeah that was the conclustion I came too.

Someone else even told me VB is more of a "syntactical sugar" type of implementation where the generated IL actually moves these variable assignment statements to the class constructor.

I still think it is stupid for C# to hide the base class from the class level itself, but maybe they had a good reason for it. Or maybe I am just very VB ;)

When doing a MyBase, the ILDASM shows this in the constructor

Code:

---

  IL_0034:  call      instance valuetype [System.Drawing]System.Drawing.Color [System.Windows.Forms]System.Windows.Forms.TextBoxBase::get_BackColor()
  IL_0039:  stfld      valuetype [System.Drawing]System.Drawing.Color vbdotnettestlibrary.ExtendedTextbox::_backColor

---

And for C#

Code:

---

  IL_000a:  call      instance valuetype [System.Drawing]System.Drawing.Color [System.Windows.Forms]System.Windows.Forms.TextBoxBase::get_BackColor()
  IL_000f:  stfld      valuetype [System.Drawing]System.Drawing.Color vbftest1.ExtendedTextbox::_backColor

---

So it's pretty much the same.

While there are syntactical differences in the way that you use it in VB.NET and C#, the differences arise because of the differing design philosophies of what is and isn't available in the languages for developers to use. For example, VB.NET allows for XML literals. It isn't there in C#. I suppose the reasoning for MyBase would be to make it easier to assign values or make calls anywhere, while C# restricts you, keeping you closer to IL.

Right, same in the IL pretty much. I meant its a "syntactical sugar" feature of the VB language itself to allow the access when coding to mybase outside of a class method/property.

The compilers do their job of moving it to where it needs to be to work with respect to the CLR running the IL.

Someone had asked me about a code sample I wrote in VB not translating well to C#, so that is why I was having a look at all this. VB is so much more productive than C# in the IDE right now, that I am sad I can't write full XNA apps in VB right now.

I haven't worked with XNA. Do they restrict you to C#?

yes they do.

There were some claims that it was an actual limitation of VB itself (either language or compiler) that would not allow things to work properly with XNA. These things were said to be resolved as of VB9, however XNA 3.0 just went CTP, with still no VB support.

However all is not lost, you can actually develop 90 some odd % of a game in VB by referencing the XNA libraries. You still are required to run the main exe in C#, but that literally could consist of one small class to run the content pipeline (the thing that loads all the game content) and hook it up to your VB code.

Chris Williams has a few cool demos I saw him show at the MVP summit where he created some quick 3d based XNA demo apps written in as much VB as they can be.

http://ilovevb.net/web/Default.aspx

I figured since I want to do a little game dev stuff, it was the perfect time to increase my C# syntax skills.

Quote:

---

Originally Posted by kleinma

I still think it is stupid for C# to hide the base class from the class level itself, but maybe they had a good reason for it. Or maybe I am just very VB ;)

---

You are very VB! 'this' and 'base' are meaningless outside an instance method therefore it makes no sense to permit them at the class level. This is a case of VB syntax being typically implicit and C syntax being typically explicit and strict.

well you can init standard variables outside an instance method, so its not crazy to think that access to the base class should be available in this same scope too. I can see errors when trying to use base or this to assign a value to a shared member, but these are private internal members.

So if the standard members can be assigned values outside the constructor, and still be instantiated at runtime and assigned their values, the same could be done with base and this in this context.