Regan Heath wrote:
> 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.

Yes. Mostly. I do not expect so many ParserErrors out there.

>>> 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.

Yes. And everything is about this "slightly easier" words.

>> 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.

Yes. But then I lost whole Parser object that I wish to use somewhere (when I catch Parser.Error). I wan't to free as much resources as I can, but no more. Parser destructor will handle rest right after handling exception.

>> 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.

Sometime cost of coping needed information would be much larger than just
using already allocated memory. The whole point isn't about memory and
resources. I've said about unregistering just to give an example of
functionality. The reason why I need it nested is because I don't want to
free this "broken" Parser instance right now, but right after handling
exception. I can find many reasons why I would like such a behaviour:
- maybe exception handler would like to store somewhere this broken parser;
- maybe ex. h. know how to "fix" this Parser instance and reuse it;
- maybe ex. h. wan't to log something and I don't know what; it may be
little part of whole Parser, but I don't know which one;
- they may be many ex. handlers and I can not be sure what else can they do;
anyhow I want to let them do as much as I can;

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

Aesthetic & convenience. The whole diffrence between nested class and static nested class is this hidden pointer. So if I want described behavior I will pass this reference manually. You may disagree with me if such behaviour of Errors/Exceptions is right or not, but someone may find an example (something else than Errors) that you would agree with him. So if nested functions were added to D to pass this reference automagically than we shall use it for our convenience. But current nested classess have somewhat limited (artificialy IMO) functionality. I say artificialy because I think (I may be wrong) just leting described inheritance work wouldn't created any change in other parts of the language.

I hope we disagree only about Errors, and not a need of allowing "derrivering nested in child class from nested in parent".

Yes - and sorry for my english. :)
-- 
Dawid Ciężarkiewicz | arael

On Tue, 28 Jun 2005 12:08:08 +0200, Dawid Ciężarkiewicz <arael@fov.pl> wrote:
> I hope we disagree only about Errors, and not a need of allowing
> "derrivering nested in child class from nested in parent".

It seems useful. I've not done a lot of programming with nested classes so I can't really say much more.

I was mainly interested in the reasoning for making the Error class nested. You seem to have it well thought out and I tend to agree with you, it does seem useful. Thanks.

> Yes - and sorry for my english. :)

Your english is very good. I wish I spoke a second language half as well.

Regan