[RESOLVED] Compile-time vs. runtime types... I'm confused...

[mshdsp]

Hi there fellow forum members.

I wanted to call upon your knowledge, as I have a simple concept that I thought I understood until yesterday when I was looking at some code in Visual Studio 2008.

The simple concept relates to reference types.

Consider the following:

    class Shape
    {
        public Shape() { }

        private string _petName = "Shape class";

        public string PetName
        {
            get { return this._petName; }
            set { this._petName = value; }
        }
    }

    class Circle : Shape
    {
        public Circle()
        {
            this.PetName = "Circle class";                        
        }

        public string circleItem = "";
    }

    class Square : Shape
    {
        public Square()
        {
            this.PetName = "Square class";
        }

        public string SquareItem = "";
    }

    class Triangle : Shape
    {
        public Triangle()
        {
            this.PetName = "Triangle class";
        }

        public string TriangleItem = "";
    }

    static class Program
    {
        [STAThread]
        static void Main()
        {
            List<Shape> Shapes = new List<Shape>();
            Shapes.Add(new Circle());
            Shapes.Add(new Square());
            Shapes.Add(new Triangle());

            foreach (Shape shape in Shapes)
            {
                string objectType = shape.GetType().ToString();
            }
        }
    }

In the foreach construct, and at compile-time, reference variable shape is of type Shape; however, at runtime, I understand that the foreach construct will assign objects that derive from Shape into the reference variable shape.

My question is this: Is reference variable shape still of type Shape at runtime, even though it points to a object of a different type? Or does it change depending on the object it is pointing to? For example, in the first iteration of the foreach loop, would reference variable shape's type now be of type Circle?

Again, sorry for the simplicity of the question, but clarification from you experienced developers would be well received.

[MNovy]

As far as I know you cannot create a list of a base class, but add deviated classes.
It is like having an array of short int, but trying to apply long int.

A list must be type consistent.

[nelo]

My question is this: Is reference variable shape still of type Shape at runtime, even though it points to a object of a different type? Or does it change depending on the object it is pointing to? For example, in the first iteration of the foreach loop, would reference variable shape's type now be of type Circle?

You have to understand the concept of inheritance in object oriented programming. The reference variable 'shape' can be of type 'Circle' which is a 'Shape'. For example in the world you insects. A mosquito is an insect. There are certain things that it shares with all insects. An ant is different from a mosquito but it is still an insect. So for example chemical manufacturers produce insect killers that can kill a variety of insects be they ants, roaches, mosquitos, etc.

In your case the concrete type of the first instance in the list might be of type 'Circle' but it can be interpreted as a 'Shape' otherwise you would have had an error when tried to add it to the list.

[Mutant_Fruit]

As far as I know you cannot create a list of a base class, but add deviated classes.
It is like having an array of short int, but trying to apply long int.

Yes you can. The reason why you can't add long ints to a list of short ints is because they are completely different unrelated types. long int does not inherit from short int.

My question is this: Is reference variable shape still of type Shape at runtime,

Yes, it is. A simple testcase is this:

public class BaseClass
{
    public void Method ()
    {
        Console.WriteLine ("Base says hello");
    }
}

public class Derived : Base
{
    public new void Method ()
    {
        Console.WriteLine ("Base says hello");
    }
}

Notice how the derived class declares a new method with the same name as the base class. Now, run this sample:

Base base = new Base ();
base.Method ();

Derived derived = new Derived ();
derived.Method ();

Base base = new Derived ();
derived.Method ();

As the method in question is *not* a virtual method, the compile time type is used to resolve which method will be invoked. Virtual methods will use the runtime type, i.e. the .NET framework will check the type of the object, then go to the virtual method table, then invoke the correct method (overridden) method.

If the compiler was 'smart' and decided to change the type of the variable in that last example, you'd end up calling the incorrect method and the whole world would collapse!

[boudino]

Type of reference variable remains Shape, but the object which it references can be of different (derived) type. The referenced object can at runtime even be of type you have never imagined at compile time, because it can come from dynamicaly loaded (or created) assembly.

[mariocatch]

Throw the screwball of 'dynamic' in c# 4/vs 10 and the universe implodes.

[mshdsp]

Type of reference variable remains Shape, but the object which it references can be of different (derived) type. The referenced object can at runtime even be of type you have never imagined at compile time, because it can come from dynamicaly loaded (or created) assembly.

That's what I thought. Thanks for the clarification.

[mshdsp]

Thanks all for responding to this post; I am most grateful to you for taking the time to be so informative and polite.

[boudino]

Implodes? Explodes, doesn't it? It is just start of next level of spiral development of approaches. Back to basic but on another level from another direction whit slightly modified intention.