how to make non overridable sub to be overridable

[seco]

hi
is there any way to make the non overridable subs to be overridable in the dll file ?hack it or somthing like that ?

any help

thanks in advance.

 

[cjard]

It's Not Overridable for a reason.. If you could redefine it to be overridable youre breaking an inbuilt language security feature.. And you might as well remove all security features in that case..

 

[JohnH]

Declare it Shadows

 

[cjard]

Question, John:

If I wanted to replace some Not Overridable method in the framework, with a customised version.. If I did it shadows, then which version would be called? Does it depend on the inheritance hierarchy and boxing of the variable?

Suppose the framework contained a class Child, which was a child of Parent. Child.SomeNotOverridable() is a not overridable method.

Now suppose I made a class: ChildChild which is a subclass of child, and i declared my own version of the method as Shadows SomeNotOverridable..


Another class in the framework, at one point, declares:

Parent p = New Child
p.SomeNotOverridable()

Whose method is called in this case? Is it microsoft's Child.SomeNotOverridable() or my ChildChild.SomeNotOverridable()?


Later, it does:
Child c = New Child
c.SomeNotOverridable()

What is called now? Is it microsoft's Child.SomeNotOverridable() or my ChildChild.SomeNotOverridable()?


Because microsoft didnt know about my ChildChild.SomeNotOverridable() when they wrote the framework, they can never directly declare an instance of my ChildChild (it didnt exist when they wrote the framework).. So I'm wondering if their classes will ever call my method?

 

[JohnH]

I don't see you use ChildChild anywhere (no box, no object), but generally both for overriding and shadowing it is the "box" that determines what method implementation that is called.

Dim p As Parent = New Child 
p.calls() 'Parent method() is called

Dim c As Child = New Child 
c.calls() 'Child method() is called

Base/parent classes never calls inherited childs methods. There is one exception to this, with use of Interface some class can safely call any class' method implementation.

 

[seco]

i mean i want to hack the dlls of the framework

 

[JohnH]

Use Reflector to read the code in the framework libraries, if that was what you meant. You can't change the official libraries themselves, because they are digitally signed and it is illegal.

 

[cjard]

I'm sure I wrote a reply to this, but its not here, so I'll try again..

generally both for overriding and shadowing it is the "box" that determines what method implementation that is called.

If this is the case, then the .NET inheritance rules differ from Java significantly, which could be the source of my confusion. In java:

When a child member overrides a parent member, the implementation that is called is the child, regardless of boxing
When a child member shadows a parent member, the boxing is used to determine which implementation to call

If (as you state) the boxing determines what impl to call, then why does the following label display "abc 123", rather than "System.Object"

Label1.Tag = "abc {0}"
Label1.Text = String.Format(Label1.Tag.ToString(), 123)

The Tag is an object, hence our string is boxed as an Object, but the impl of ToString() that is called is String.ToString() which returns the string. If the boxing of object were enforcing the use of Object.ToString() rather than the overridden String.ToString(), why does it not say "System.Object" in the label text (which is what Object.ToString would return)

TIA!

 

[JohnH]

Oops, sorry about that, you are right, this is the same "rule" as Java. I mixed overrides and overloads. Overloads behaves same as Shadows and uses the implementation of the current box, but Overrides calls to the overridden member. It must have been to much mess and confusion when I tested code yesterday. Overriding ToString is a good example and very commonly used.