class C
{
	class A{}
}
class D : C
{
	class B : A{}
}

fails saying A is nested in C, not D

Why should this be a problem? An action that A can perform on a C can be performed on a D. So havening an A object nested from a D object shouldn't be a problem. Deriving from A in something derived from C also shouldn't be a problem either.

Thoughts??

BTW, I actually wanted to do this on a project.

"BCS" <BCS@pathlink.com> wrote in message news:ehirtb$2ntu$8@digitaldaemon.com...
> class C
> {
> class A{}
> }
> class D : C
> {
> class B : A{}
> }
>
> fails saying A is nested in C, not D
>
> Why should this be a problem? An action that A can perform on a C can be performed on a D. So havening an A object nested from a D object shouldn't be a problem. Deriving from A in something derived from C also shouldn't be a problem either.
>
> Thoughts??

I asked Walter his thoughts on this feature when 0.126 first came out with nested classes.  His response, best I can remember, was "AAAIIIIIEEEEEEE!" :)

So I think it's just a matter of it being really difficult to implement.

On Mon, 23 Oct 2006 12:31:28 -0700, Jarrett Billingsley <kb3ctd2@yahoo.com> wrote:


>
> I asked Walter his thoughts on this feature when 0.126 first came out with
> nested classes.  His response, best I can remember, was "AAAIIIIIEEEEEEE!"
> :)
>
> So I think it's just a matter of it being really difficult to implement.
>
>


I've seen him answer a couple of posts like that on rare occasions... I'm thinking it's CIS related... flashbacks from C++ implementation nightmares. :)

-JJR

John Reimer wrote:
> On Mon, 23 Oct 2006 12:31:28 -0700, Jarrett Billingsley  <kb3ctd2@yahoo.com> wrote:
> 
> 
>>
>> I asked Walter his thoughts on this feature when 0.126 first came out  with nested classes.  His response, best I can remember, was  "AAAIIIIIEEEEEEE!"
>> :)
>>
>> So I think it's just a matter of it being really difficult to implement.
>>

I don't see why it would be harder to implement than simple nested classes.

As I understand it (and I may well be totally wrong) a nested class is just a class that has, as a hidden parameter, a reference to another class of the type that it is nested in. When it is constructed you just need to insert the correct object pointer into the field.

In the "cross-nested" case that would be the same.

Constructing the v-table (a compile time activity) shouldn't be any different than the general case for any class, copy the v-table from the inherited class and over wright the overridden methods. This should work just fine.

The semantic processing should work just the same as any other nested class, e.i. the access rules should be the same as if the class it is derived from were not nested in another class.

The only possible problem I see is that their could be an ambiguity between accessing a parameter of the enclosing class of the base class (a.k.a. the base class of the enclosing class) however, I don't think that this would be an issue as the exact same effect would result ether way.


Effectively what I'm saying is that all (or most) of the pieces are there already. Besides allowing the construct, the only parts that aren't are construction (getting the outer pointer passed to the base constructor) and accessing a variable in the "grand daddy" class (which should just consists of allowing the lookup system to pick one)


There would be a distinct advantage of allowing this. As it is, in order to extend a nested class, you have to do so inside of the class it is nested in. For 3rd party libs, this totally bars this. In the following case you wouldn't be able to make new Event or Handler types.


class EventHandler
{
	class Event
	{
	}

	class Handler
	{
		bool Go(Event);
	}

	AddHandler(EventType,Handler){...}
	TiggerEvent(Event){...}
}

> 
> I've seen him answer a couple of posts like that on rare occasions... I'm  thinking it's CIS related... flashbacks from C++ implementation  nightmares. :)

CSI?? (I can't find a reference)

> 
> -JJR

== Quote from BCS (BCS@pathlink.com)'s article

> > I've seen him answer a couple of posts like that on rare
occasions...
> > I'm  thinking it's CIS related... flashbacks from C++
implementation
> > nightmares. :)
> CSI?? (I can't find a reference)

CIS not CSI.. :)   CIS stands for Critical Incident Stress, a condition usually brought on by some traumatic event (physical or psychological).  It's a phrase bandied about in many industries where employees must work in emotionally stressful situations, and periodically experience or witness really nasty things. War veterans and victims who are exposed to severe conditions often experience the syndrome, as do EMS workers, the field in which I work.  I thought C++ compiler designers/implementers might be familiar with the condition as well. ;D

CSI, on the other hand, is some sort of TV show, I think. :)

-JJR