Change base class at runtime?

[User N]

Perhaps this is a stupid question, but here goes anyway. Given
an instance of an arbitrary class, is it possible to change its base
class at runtime? Here's my problem...

I need to extend class Foo, which I can't change. Foo holds a
reference to a collection of Bar objects and/or objects derived
from Bar (which I can't change). My FooExtended class needs to
keep extra information for each Bar [derivative] in that collection.
If I could change the code that populates/manipulates the Bar
collection, I could arrange for it to hold MyBar objects which
have the extra member variables FooExtended needs. But I can't
change that code either.

At first I figured FooExtended could maintain a parallel collection
that stores info for each of the Bars in its Bar collection, and update
that information by hooking the Bar collection changed event. But
that has become complicated in cases where a Bar instance is
temporarily removed from the collection and then added back at a
later time. The extra info needs to be maintained for the life of every
Bar object, and there could be ALOT of them. I could probably
cache the extra info and associate it with Bar instances, but I'm
wondering if there is a more efficient and elegant approach.

If there is some way I could add member variables (perhaps even
associated accessors) to instances of Bars when they are first seen
in the Bar collection, I *think* my problem would be solved. But
is something like that possible?

[Jon Skeet [C# MVP]]

User N <Us***@invalid.invalid> wrote:

Perhaps this is a stupid question, but here goes anyway. Given
an instance of an arbitrary class, is it possible to change its base
class at runtime?
Nope.
Here's my problem...

I need to extend class Foo, which I can't change. Foo holds a
reference to a collection of Bar objects and/or objects derived
from Bar (which I can't change). My FooExtended class needs to
keep extra information for each Bar [derivative] in that collection.
If I could change the code that populates/manipulates the Bar
collection, I could arrange for it to hold MyBar objects which
have the extra member variables FooExtended needs. But I can't
change that code either.

At first I figured FooExtended could maintain a parallel collection
that stores info for each of the Bars in its Bar collection, and update
that information by hooking the Bar collection changed event. But
that has become complicated in cases where a Bar instance is
temporarily removed from the collection and then added back at a
later time. The extra info needs to be maintained for the life of every
Bar object, and there could be ALOT of them. I could probably
cache the extra info and associate it with Bar instances, but I'm
wondering if there is a more efficient and elegant approach.

If there is some way I could add member variables (perhaps even
associated accessors) to instances of Bars when they are first seen
in the Bar collection, I *think* my problem would be solved. But
is something like that possible?

It doesn't sound like it's feasible - it sounds like Foo just wasn't
designed with this kind of scenario in mind.

Can you override the methods which manipulate the collection, and
whenever you're asked to add a Bar, actually add a MyBar?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[User N]

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message news:MP************************@msnews.microsoft.c om...

User N <Us***@invalid.invalid> wrote:
-snip-
Can you override the methods which manipulate the collection, and
whenever you're asked to add a Bar, actually add a MyBar?

Hmmm. Foo has a public virtual get accessor for its private BarsCollection.
So theoretically MyFoo could override that and return a MyBarsCollection
that does what you describe. Is that what you are suggesting?

[Jon Skeet [C# MVP]]

User N <Us***@invalid.invalid> wrote:

-snip-

Can you override the methods which manipulate the collection, and
whenever you're asked to add a Bar, actually add a MyBar?

Hmmm. Foo has a public virtual get accessor for its private BarsCollection.
So theoretically MyFoo could override that and return a MyBarsCollection
that does what you describe. Is that what you are suggesting?

Not quite, but it *might* be enough, assuming that you can override
appropriate things in BarsCollection - and assuming that the base class
only ever uses the property, rather than its own member variable...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too