Determining calling type in a base class

[ASB]

Ok,

I have a VB.NET base class.

public MustInherit Class asbBaseClass

public Shared ReadOnly property SomeProperty as integer


And I have an implementation

public Class asbConcrete inherits asbBaseClass


Now at some point I write access to the shared member.

say

intA = asbContrete.SomeProperty

Now:

What I need to do in someproperty is ascertain that the caller is the class asbConcrete, as opposed to anything else that might implement it.

Stuffed if I can figure out how to do this. :-(

obviously since it's a shared member there is no "me". There is no "myclass" either.

The closest I can get to is GetType(asbBaseClass) - but I can't find anyway of getting back from there to the caller.

Any bright ideas ???

[DimPrawn]

WTF?

I don't do the mess they call VB.NET, but in C# you can prefix the derived class implementation of a static member with new to hide the base class implementation.

[ASB]

WTF?

I don't do the mess they call VB.NET, but in C# you can prefix the derived class implementation of a static member with new to hide the base class implementation.

Yes, but it ain't C# :-(.

I'll rephrase the question:-

In a shared base class member how can you the calling class name in VB?

I accept that "why the hell do you want to do that" is a fair answer - but I still do.

Cheers,

[Cowboy Bob]

It's called "encapsulation".

You don't access the property directly, you make that private. Then you have a getter method in your base class which you override in your concrete class. If the base class is the one that needs to know the caller, you can pass an extra parameter down in the accessor method. In Java it would look like this:-

public abstract class BaseClass
{
    private int someProperty;

    // Force implementation in concrete class
    public abstract int getSomeProperty();

    protected int getSomeProperty(Object caller)
    {
        System.out.println("Caller - " + caller.getClass().getName();

        return (someProperty);
    }
}

public class ConcreteClass extends BaseClass
{
    public int getSomeProperty()
    {
        return (getSomeProperty(this));
    }
}

Edit : just realised Shared means static. In which case it would look like this (though you'd need to make it threadsafe yourself):-

public abstract class BaseClass
{
    private static int someProperty;

    protected static int getSomeProperty(Class caller)
    {
        System.out.println("Caller - " + caller.getName();

        return (someProperty);
    }
}

public class ConcreteClass extends BaseClass
{
    public static int getSomeProperty()
    {
        return (getSomeProperty(ConcreteClass.class));
    }
}

[ASB]

CowboyBob,

Yes. I realise I can do that. But that is not actually what I am trying to achieve.

Ideally I need to do it without changing the already existing code. :-(.

The existing code inherits a baseClass. A shared member is invoked. This goes into the new base class.

This in turn simply needs to know which class is calling it. Unfortunately there is nothing in the interface the currently exists which enables me to detemine this.

I guess I'm just going to have to inherit the concrete implementation and modify it.

[3ill]

CowboyBob,

Yes. I realise I can do that. But that is not actually what I am trying to achieve.

Ideally I need to do it without changing the already existing code. :-(.

The existing code inherits a baseClass. A shared member is invoked. This goes into the new base class.

This in turn simply needs to know which class is calling it. Unfortunately there is nothing in the interface the currently exists which enables me to detemine this.

I guess I'm just going to have to inherit the concrete implementation and modify it.

Not sure what it is in VB.Net.. but in C# you should be able to accomplish this by using Reflection

e.g.

MethodBase.GetCurrentMethod().ReflectedType should return you the type of the class that called that property.

[DimPrawn]

CowboyBob,

Yes. I realise I can do that. But that is not actually what I am trying to achieve.

Ideally I need to do it without changing the already existing code. :-(.

The existing code inherits a baseClass. A shared member is invoked. This goes into the new base class.

This in turn simply needs to know which class is calling it. Unfortunately there is nothing in the interface the currently exists which enables me to detemine this.

I guess I'm just going to have to inherit the concrete implementation and modify it.

Don't mean to rain on your parade, but what screwed up design would need a base class to know anything about which derived class called it?

How can a base class ever be expected to know what future derived classes there might be and how should it know how to behave differently in each case?

Sounds like a bad case of arse about face design.

[VectraMan]

intA = asbContrete.SomeProperty

I haven't done basic since I had an Oric 1, but you're not trying to get the caller, you're trying to get the object the method (assuming it's equivalent to a method) is called on.

Assuming it works the same as C++, and "shared" is "static" then essentially the asbConcrete. part gets compiled out and is just used for compile time name resolution. So I don't see how you could possibly ever do a run time test as the information simply doesn't exist at runtime.

Can you not put a "SomeProperty" into asbConcrete as well, or does VB not allow that?

I think this falls firmly in the camp of: if you need to ask this your whole approach is wrong. But I understand you're trying to bodge something into an existing system rather than produce a new elegant solution.

[thunderlizard]

"I guess I'm just going to have to inherit the concrete implementation and modify it."

That is definitely the best option.

The Prawn is right. If your base class is supposed to know what the derived class is, then you're not doing inheritance. You'd be playing with fire. Inheritance is a one way street.

[ASB]

Thanks Guys.

I'll check out 3ill's reflection suggestion. That look promising.

As to "what screwed up design" I'll elaborate a little.

Firstly, the final design for where I am going to end up will include the right properties etc, but I have to migrat about 200,000 lines of procedural cobol as part of the process of evolving.

First step is getting this running in .NET and implementing a part of the new framework. The requirement for the lash up arises because the cobol programs get compiled into one object with one static method. I'm trying to avoid having to do too much in one hit just to get it running initially.

I'm also interested in DimParwns comment: "How can a base class ever be expected to know what future derived classes there might be and how should it know how to behave differently in each case?".

Well - would it be unreasonable to demand a derived class has implemented a specific interface?