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


 I'm  thinking it's CIS related... flashbacks from C++


 nightmares. :)


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