Prev: Problem with TTable
Next: the Clear method for the Queue class
From: Arne Vajhøj on 30 Jun 2010 20:33
On 30-06-2010 13:35, Jeff Johnson wrote:
> "Duncan"<a(a)b.com> wrote in message
> news:%23dTA0PHGLHA.3640(a)TK2MSFTNGP02.phx.gbl...
>> I'll have a look at what I can do via reflection.
>
> That's easy: anything.

There are a few things it can't: make peace in the
middle east etc..

:-)

But when it comes to class/object access then there are
not many limits.

Arne

From: Peter Duniho on 30 Jun 2010 22:20
Duncan wrote:
> Thanks for the info guys. There's an added complication with not having
> access to the A and B classes. So extending B to provide access to A
> isn't possible.
>
> I'll have a look at what I can do via reflection.

I'm sure you can accomplish it using reflection. But as I mentioned
before, it's usually not a good idea to do so. If you need this kind of
functionality, it usually means your design is broken.

Pete
From: Arne Vajhøj on 30 Jun 2010 22:46
On 30-06-2010 22:20, Peter Duniho wrote:
> Duncan wrote:
>> Thanks for the info guys. There's an added complication with not
>> having access to the A and B classes. So extending B to provide access
>> to A isn't possible.
>>
>> I'll have a look at what I can do via reflection.
>
> I'm sure you can accomplish it using reflection. But as I mentioned
> before, it's usually not a good idea to do so. If you need this kind of
> functionality, it usually means your design is broken.

My guess would be that >90% of all .NET apps uses reflection
for something, so ...

Arne
From: Peter Duniho on 30 Jun 2010 22:57
Arne Vajh�j wrote:
> [...]
>> I'm sure you can accomplish it using reflection. But as I mentioned
>> before, it's usually not a good idea to do so. If you need this kind of
>> functionality, it usually means your design is broken.
>
> My guess would be that >90% of all .NET apps uses reflection
> for something, so ...

I doubt that's true. In very large applications it may be difficult to
avoid it completely, but even there the situations are generally rare.
And in smaller desktop programs, utilities, command-line tools, etc.
there's often no need for reflection at all.

However, be that as it may, I wasn't talking about the reflection
aspect. I was talking about the "inherit a class but don't use its
functionality" aspect.

Pete
From: J.B. Moreno on 1 Jul 2010 00:47
Peter Duniho <NpOeStPeAdM(a)NnOwSlPiAnMk.com> wrote:

> Duncan wrote:
> > Hi,
> >
> > I have a class 'A' that has a virtual member 'm()'. Another class 'B'
> > inherits from A and overrides m. Yet another class 'C' inherits from B.
> >
> > A <- B <- C
> >
> > From C, can I call A's implementation of m(), or the member from the
> > immediate inheritance from B?
>
> Not using only language features, no. C# only exposes the immediate
> base class implementation, through "base".

I agree that it's a bad idea, but


A a = (A) this;
a.m();

or something like it should work...

--
J.B. Moreno
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Problem with TTable
Next: the Clear method for the Queue class