Bug or miss feature in nested class?

BCS BCS at pathlink.com
Mon Oct 23 16:52:16 PDT 2006


John Reimer wrote:
> On Mon, 23 Oct 2006 12:31:28 -0700, Jarrett Billingsley  
> <kb3ctd2 at 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



More information about the Digitalmars-d-bugs mailing list