class B{
  class InB{
  }
}

class C:B{
  class InC : B.InB{
  }
}

dmd: class d.C.InC super class InB is nested within B, not C

Where is the problem:
a) in notation;
b) in dmd implementation (this feature isn't implemented yet);
c) in my mind (i'm tring to do something ridiculus)?

What am I tring to achive:
InB and InD are both "class Error", B is "class Task" and C is "class
SpecialTask". I throw them when something went wrong in C/B. In their
constructors I call some cleanup functions on C/B. The InB uses:
char[] B.id();
to [prepare msg / log something to output] .
-- 
Dawid Ciężarkiewicz | arael

"Dawid Ciê¿arkiewicz" <arael@fov.pl> wrote in message news:d9nchv$g85$1@digitaldaemon.com...
> class B{
>  class InB{
>  }
> }
>
> class C:B{
>  class InC : B.InB{
>  }
> }

I asked if this could be implemented when 0.126 came out.  To which Walter replied: "AIEEEE"

So, in short, I doubt it'll be implemented.  :)

Jarrett Billingsley wrote:
> "Dawid Ciężarkiewicz" <arael@fov.pl> wrote in message news:d9nchv$g85$1@digitaldaemon.com...
>> class B{
>>  class InB{
>>  }
>> }
>>
>> class C:B{
>>  class InC : B.InB{
>>  }
>> }
> 
> I asked if this could be implemented when 0.126 came out.  To which Walter replied: "AIEEEE"
> 
> So, in short, I doubt it'll be implemented.  :)

LOL. I remeber this message. Can we let Walter forget about this neat language feature? Of course no. :D There may be some more important things right now, but "AIEEEE" sounds like "oh god, more to work to do, but it defintly should be done". Right? :D
-- 
Dawid Ciężarkiewicz | arael

On Mon, 27 Jun 2005 10:28:08 +0200, Dawid Ciężarkiewicz <arael@fov.pl> wrote:
> Jarrett Billingsley wrote:
>> "Dawid Ciężarkiewicz" <arael@fov.pl> wrote in message
>> news:d9nchv$g85$1@digitaldaemon.com...
>>> class B{
>>>  class InB{
>>>  }
>>> }
>>>
>>> class C:B{
>>>  class InC : B.InB{
>>>  }
>>> }
>>
>> I asked if this could be implemented when 0.126 came out.  To which Walter
>> replied: "AIEEEE"
>>
>> So, in short, I doubt it'll be implemented.  :)
>
> LOL. I remeber this message. Can we let Walter forget about this neat
> language feature? Of course no. :D There may be some more important things
> right now, but "AIEEEE" sounds like "oh god, more to work to do, but it
> defintly should be done". Right? :D

Depends. Why have the Error classes within the other ones?

Regan

"Dawid Ciê¿arkiewicz" <arael@fov.pl> wrote in message news:d9odau$1bc0$1@digitaldaemon.com...
> LOL. I remeber this message. Can we let Walter forget about this neat language feature? Of course no. :D There may be some more important things right now, but "AIEEEE" sounds like "oh god, more to work to do, but it defintly should be done". Right? :D

Maybe.  I mean, it would be a cool feature to have, but I can definitely see how complex and confusing it would be for both the compiler and the compiler writer.  And part of the "D mantra" is "keep it simple, so there are more correct implementations out there."

Though one thing I'd like to see, and don't know why it doesn't work, is this:

class A
{
    class InA
    {
    }

    InA ina;
}

class B : A
{
    InA ina2;
}

Why can't B have an InA?  The error says that the "this" for "ina2" must be an "A," but a B _is_ an A, by the very definition of inheritance.

Regan Heath wrote:
> Depends. Why have the Error classes within the other ones?

I'm not sure if I understand the question. I keep the Error classes inside because they are (conceptionaly) part of outside class. And it's saves the global namespace. This way I can catch Parser.Error rather than ParserError. If Error classes are nested I can do some cleanup easly when throwing such Error (in Parser.Error.this()) and I'm sure I won't lost the track of Parser object (nested class store hidden pointer to outside class - that makes me sure I can do real cleanup and garbage collector will not delete my Parser object as long I will be handling exception). Of course I can declare Parse.Error as static (I'm doing so because of that problem with inheritance in nested classess) and pass Parse.this manually - but aren't nested class created to do this for me?

I strongly agree with "Keep It Simple" directive. But wouldn't be that rather simple addition to language? As I understand nested classess are just normal static nested classess with hidden pointer to outer class. Nothing changes when allowing such inheritance, right? Still there is a pointer, still is it inited with outher class this, still he behaves as normal D's pointer (reference) to class.

Or am I missing something? (it's very possible :) ) If this is realy big problem - as I said - I can "hack" this behavior already without much problem. But if not - it would be neat to have it in D.

Thanks,
-- 
Dawid Ciężarkiewicz | arael

On Mon, 27 Jun 2005 23:45:36 +0200, Dawid Ciężarkiewicz <arael@fov.pl> wrote:
> Regan Heath wrote:
>> Depends. Why have the Error classes within the other ones?
>
> I'm not sure if I understand the question. I keep the Error classes inside
> because they are (conceptionaly) part of outside class. And it's saves the
> global namespace. This way I can catch Parser.Error rather than
> ParserError. If Error classes are nested I can do some cleanup easly when
> throwing such Error (in Parser.Error.this()) and I'm sure I won't lost the
> track of Parser object (nested class store hidden pointer to outside class
> - that makes me sure I can do real cleanup and garbage collector will not
> delete my Parser object as long I will be handling exception). Of course I
> can declare Parse.Error as static (I'm doing so because of that problem
> with inheritance in nested classess) and pass Parse.this manually - but
> aren't nested class created to do this for me?

It seems to me that:
- ParseError would not pollute the global namespace (in any detrimental way I can see).
- ParseError is a name which suggests something conceptually part of something called "Parse".

You're dead right about nested classes though.

However, I'm not sure I understand the need in the case of error classes. An exception/error should contain all the information it requires, I assume you're saying that is the _whole_ main class? thus why you want the nested class?

Surely you don't need it all, but just some part of it? In which case it error class doesn't need to be nested.

> I strongly agree with "Keep It Simple" directive. But wouldn't be that
> rather simple addition to language?

Who knows.. Walters response seemed to indicate that it looked bad (at least at first).

> As I understand nested classess are
> just normal static nested classess with hidden pointer to outer class.
> Nothing changes when allowing such inheritance, right? Still there is a
> pointer, still is it inited with outher class this, still he behaves as
> normal D's pointer (reference) to class.
>
> Or am I missing something? (it's very possible :) ) If this is realy big
> problem - as I said - I can "hack" this behavior already without much
> problem. But if not - it would be neat to have it in D.

Yeah, I can understand the desire. I think we'll have to wait for Walter to comment on this one.

Regan

Regan Heath wrote:
> It seems to me that:
> - ParseError would not pollute the global namespace (in any detrimental
> way I can see).

class ParserError : Error{
 ....
}

class Parser{
 ...
}

vs.

class Parser{
  class Error : object.Error{
    ...
  }
  ...
}

Second is cleaner IMO. Only one class in global namespace declared, shorther (and more readable) names.

> - ParseError is a name which suggests something conceptually part of something called "Parse".

Yes. Error generated by Parser is in some way part of Parser class (not object). But the main reason is naming - I just like Parser.Error better.

> However, I'm not sure I understand the need in the case of error classes. An exception/error should contain all the information it requires, I assume you're saying that is the _whole_ main class? thus why you want the nested class?

The reasons are:
- I can't say what I will be doing with such an Parser.Error. Maybe I would
like to print debug message containing for example "Parser id", "Parser
last token" etc. Having whole Parser will let me to add such things easly
in future. It's cheap in a matter of memory - only one additional pointer,
rather than coping all necessary informations.
- Parser returning Error (unrecovable) should be unregister from owning
objects and cleaned possibly fast (precious resources :) ). I can make it
using Parser.Error constructor and such Parser will not be deleted by GC
because of this hidden pointer inside nested class. Right after
Parser.Error is handled and forgoten GC will take care of freeing memory
used by Parser.Error and  Parser instances.

> Surely you don't need it all, but just some part of it? In which case it error class doesn't need to be nested.

Yes. I can have naming like this without nested class (using static nested
class).

I just change:

class Parser{
  class Error : object.Error{
    this(){
      ..
    }
    ...
  }
  ...
}

into:

class Parser{
  static class Error : object.Error{
    Parser mParser;
    this(Parser p){
      mParser = p
      ..
    }
    ...
  }
  ...
}

and even worst inheritance will work right now.

What am I loosing is:
- convenience - I need to manually take care of "p" reference;

Yes, I know - it's /only/ convenience. But ... :)
-- 
Dawid Ciężarkiewicz | arael

On Tue, 28 Jun 2005 01:58:30 +0200, Dawid Ciężarkiewicz <arael@fov.pl> wrote:
> Regan Heath wrote:
>> It seems to me that:
>> - ParseError would not pollute the global namespace (in any detrimental
>> way I can see).
>
> class ParserError : Error{
>  ....
> }
>
> class Parser{
>  ...
> }
>
> vs.
>
> class Parser{
>   class Error : object.Error{
>     ...
>   }
>   ...
> }
>
> Second is cleaner IMO. Only one class in global namespace declared, shorther (and more readable) names.

Where is the detrimental effect?

The chance of a name collision i.e. someone else with a class called ParserError is slight, it increases only if you name your classes badly (Parser/ParserError is perhaps an example of that, though I imagine it is imported privately into a file defining a parser specialisation and error specialisation eg FooParser/FooParserError).

>> - ParseError is a name which suggests something conceptually part of
>> something called "Parse".
>
> Yes. Error generated by Parser is in some way part of Parser class (not
> object). But the main reason is naming - I just like Parser.Error better.

It's aesthetic preference then.

>> However, I'm not sure I understand the need in the case of error classes.
>> An exception/error should contain all the information it requires, I
>> assume you're saying that is the _whole_ main class? thus why you want the
>> nested class?
>
> The reasons are:
> - I can't say what I will be doing with such an Parser.Error. Maybe I would
> like to print debug message containing for example "Parser id", "Parser
> last token" etc. Having whole Parser will let me to add such things easly
> in future.

It may be slightly easier perhaps, but it's not hard to add them to the error class itself.

> It's cheap in a matter of memory - only one additional pointer,
> rather than coping all necessary informations.

Sure. Except that when an exception is thrown the stack unwinds and your Parser reference goes out of scope, this the Gc could collect it before you handle your error, resulting in less memory used, not more.

> - Parser returning Error (unrecovable) should be unregister from owning
> objects and cleaned possibly fast (precious resources :) ).

Yep, all the more reason not to keep a reference to it in the error class.

> I can make it
> using Parser.Error constructor and such Parser will not be deleted by GC
> because of this hidden pointer inside nested class.

Correct, holding onto possbily useless resources, using more memory.

> Right after
> Parser.Error is handled and forgoten GC will take care of freeing memory
> used by Parser.Error and  Parser instances.

Sure, but you only need Parser to hang round cos you haven't yet copied/referenced the debug/error information you need from it. You don't need it to hang round if you've already copied it.

>> Surely you don't need it all, but just some part of it? In which case it
>> error class doesn't need to be nested.
>
> Yes. I can have naming like this without nested class (using static nested class).

So, the main reason you've nested it is aesthetic? You don't really need/want the outer this pointer in the error class?

Regan

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opss14krjt23k2f5@nrage.netwin.co.nz...
> So, the main reason you've nested it is aesthetic? You don't really need/want the outer this pointer in the error class?

Maybe he wants namespaces.  ;)

I'll just keep plugging it... maybe.. someday...