www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - Bug or miss feature in nested class?

reply BCS <BCS pathlink.com> writes:
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.
Oct 23 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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.
Oct 23 2006
parent reply "John Reimer" <terminal.node gmail.com> writes:
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
Oct 23 2006
parent reply BCS <BCS pathlink.com> writes:
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
Oct 23 2006
parent John Reimer <terminal.node gmail.com> writes:
== 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
Oct 23 2006