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