Søren J. Løvborg wrote:
> 
> (On an unrelated note, shouldn't Exception also support exception chaining?)

More than that, IMO.  Here is the Exception declaration for Ares (note that Error has been removed completely):

class Exception : Object
{
    char[]      msg;
    char[]      file;
    size_t      line;
    Exception   next;

    this(char[] msg, Exception next = null);
    this(char[] msg, char[] file, size_t line, Exception next = null);
    char[] toString();
}

Søren J. Løvborg wrote:
> (On an unrelated note, shouldn't Exception also support exception chaining?)
> 

What do you mean by exception chaining?
Do you mean exception aggregation/composition (where one specifies an exception as a sub cause of the parent exception)?. Or you mean nested exception throwing, where you throw a new, unrelated exception in a catch block and still have info about the previous exception?

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> What do you mean by exception chaining?
> Do you mean exception aggregation/composition (where one specifies an
> exception as a sub cause of the parent exception)?. Or you mean nested
> exception throwing, where you throw a new, unrelated exception in a catch
> block and still have info about the previous exception?

The first. I don't envision any sort of special compiler support for it, which would really be required for the latter.

The latter is also a much less common problem, I think. And if an exception occurs in your exception handler, your primary goal should be to fix the exception handler, anyway (if possible).

-- 
Søren J. Løvborg
web@kwi.dk

> I've just answered myself. This design allows "one to hide superclass ctors", just like kris said, but only now did I get it. I guess that's the reason why the new languages have that behavior? Hum, what's it like in non-C-family OO languages like Ruby and Python, anyone knows ?

I could be wrong here, but since the "constructor" in Python is just a specially named function (__init__), it should inherit.

Which makes things like, for example, writing new Exceptions stupidly easy since you can do the equivalent of:

class MyExceptionThatDoesntDoMuch : Exception {}

And leave it at that.  Personally, I've always been fond of this behaviour since it allows you to quickly customise the operation of a particular class (bonus evil points for then *replacing* the original class ^_^).

> (Also, DMD could print a better message when an inserted implicit
> super() is not found.)

Oh yeah, I've been bitten by that one.  "What do you mean there's no valid constructor of zero arguments--I'm not trying to call one!  Which line are you complaining about?!?!"

	-- Daniel

-- 

v1sw5+8Yhw5ln4+5pr6OFma8u6+7Lw4Tm6+7l6+7D a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP    http://hackerkey.com/

Daniel Keep wrote:
>> I've just answered myself. This design allows "one to hide superclass
>> ctors", just like kris said, but only now did I get it. I guess that's
>> the reason why the new languages have that behavior? Hum, what's it like
>> in non-C-family OO languages like Ruby and Python, anyone knows ?
> 
> I could be wrong here, but since the "constructor" in Python is just a
> specially named function (__init__), it should inherit.
> 
> Which makes things like, for example, writing new Exceptions stupidly
> easy since you can do the equivalent of:
> 
> class MyExceptionThatDoesntDoMuch : Exception {}
> 
> And leave it at that.  Personally, I've always been fond of this
> behaviour since it allows you to quickly customise the operation of a
> particular class (bonus evil points for then *replacing* the original
> class ^_^).
> 

Well, in any case, in order to have that (constructor inheritance), we would either have to lose functionality (ability to hide superclass constructors) or devise a way to that (hide superclass constructors) in an opt-out way.


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

* Bruno Medeiros:
> d-bugmail@puremagic.com wrote:
>> http://d.puremagic.com/bugzilla/show_bug.cgi?id=91
>>
>>
>> ------- Comment #3 from smjg@iname.com  2006-04-07 11:55 -------
>> Yes, including C++ and Java.  If anybody could circumvent the requirement to
>> use a constructor simply by creating a derived a class, it would defeat the
>> point.
>>
>> You can, however, put a protected constructor in the base class.  This is a
>> constructor created specifically for derived classes to base their constructors
>> on.  You would be able to completely override* a constructor if the base class
>> has a protected constructor that does nothing.  But can you think of an example
>> in which this would make sense?
>>
>> * Actually, constructors don't override as such.  A constructor is a member
>> only of the class in which it is defined, not of any derived classes.  Hence if
>> the base class has no default constructor, then when deriving a class from it
>> you must explicitly define a constructor.
>>
>>
> 
> Ok, so the spec says:
> 
> "If there is no constructor for a class, but there is a constructor for the base class, a default constructor of the form:
>     this() { }
> is implicitly generated."
> 
> But why is this? Why must a derived class have it's own constructor, explicit or not? I don't think this makes sense. One time, I wanted to create a new exception class, just to throw around and make use of it's class type. So it didn't have any new content. I coded:
> 
>   class MyException : Exception { }
> 
> ... and surprised I was when this didn't compile, as it isn't valid code. (Because an implicit constructor "this() { }" is inserted, but there isn't a super constructor with 0 parameters). Seems to me this idea of inserting an implicit default constructor doesn't make sense, yet both Java and C# have this behavior (and C++ for what was said), so can it be I'm missing something? :/
> 

I struggling with constructor issues right now. And I am about to loose my sanity.

I have toying with D for a few month now and so far everything was pretty much nice. Or even better than nice =)
Until I started with class hierarchies...

I see two major and one minor problems here:

1. Implicit generated call for super in constructor. If i have a this() constructor in base class, eventually it will be called implicitly (I already experienced this). And you could spend nights trying to understand why your objects misbehave. My opinion: implicitly generated super() calls are Evil.

2. Forcing to call base constructors. I just don't get it. When I define a constructor in subclass, I do it to overload functionality of base classes. Isn't it obvious? But when I *forced* to call super constructors, there is no sense in them at all. I some case I could have some init() method to overload, but in some case i do not see a sane way to fix it. My opinion: It is a design flaw, to force workarounds instead of solutions.

3. Inability for compiler to determine suitable constructor in hierarchy if no defined in current class. Programmer need to explicitly define dumb constructors passing parameters to super(). My opinion: this is unnecessary redundancy and could lead to maintenance hell when base constructors being changed or even worse - added new.

It would be excellent if constructors in D were behave like virtual methods. And not forced to call super constructors, please!!!

-- 
serg.

* Serg Kovrov:
> 2. Forcing to call base constructors. I just don't get it. When I define a constructor in subclass, I do it to overload functionality of base classes. Isn't it obvious? But when I *forced* to call super constructors, there is no sense in them at all. I some case I could have some init() method to overload, but in some case i do not see a sane way to fix it. My opinion: It is a design flaw, to force workarounds instead of solutions.

In my previous post i misused term 'overload', should read 'override' instead.

-- 
serg.

Serg Kovrov wrote:
> * Bruno Medeiros:
>> d-bugmail@puremagic.com wrote:
>>> http://d.puremagic.com/bugzilla/show_bug.cgi?id=91
>>>
>>>
>>> ------- Comment #3 from smjg@iname.com  2006-04-07 11:55 -------
>>> Yes, including C++ and Java.  If anybody could circumvent the requirement to
>>> use a constructor simply by creating a derived a class, it would defeat the
>>> point.
>>>
>>> You can, however, put a protected constructor in the base class.  This is a
>>> constructor created specifically for derived classes to base their constructors
>>> on.  You would be able to completely override* a constructor if the base class
>>> has a protected constructor that does nothing.  But can you think of an example
>>> in which this would make sense?
>>>
>>> * Actually, constructors don't override as such.  A constructor is a member
>>> only of the class in which it is defined, not of any derived classes.  Hence if
>>> the base class has no default constructor, then when deriving a class from it
>>> you must explicitly define a constructor.
>>>
>>>
>>
>> Ok, so the spec says:
>>
>> "If there is no constructor for a class, but there is a constructor for the base class, a default constructor of the form:
>>     this() { }
>> is implicitly generated."
>>
>> But why is this? Why must a derived class have it's own constructor, explicit or not? I don't think this makes sense. One time, I wanted to create a new exception class, just to throw around and make use of it's class type. So it didn't have any new content. I coded:
>>
>>   class MyException : Exception { }
>>
>> ... and surprised I was when this didn't compile, as it isn't valid code. (Because an implicit constructor "this() { }" is inserted, but there isn't a super constructor with 0 parameters). Seems to me this idea of inserting an implicit default constructor doesn't make sense, yet both Java and C# have this behavior (and C++ for what was said), so can it be I'm missing something? :/
>>
> 
> I struggling with constructor issues right now. And I am about to loose my sanity.
> 
> I have toying with D for a few month now and so far everything was pretty much nice. Or even better than nice =)
> Until I started with class hierarchies...
> 
> I see two major and one minor problems here:
> 
> 1. Implicit generated call for super in constructor. If i have a this() constructor in base class, eventually it will be called implicitly (I already experienced this). And you could spend nights trying to understand why your objects misbehave. My opinion: implicitly generated super() calls are Evil.

This is the same behavior as in C++. I don't think it's evil, it's a logical part of how class hierarchies work. So it is not a bug, it's a feature.

> 2. Forcing to call base constructors. I just don't get it. When I define a constructor in subclass, I do it to overload functionality of base classes. Isn't it obvious? But when I *forced* to call super constructors, there is no sense in them at all. I some case I could have some init() method to overload, but in some case i do not see a sane way to fix it. My opinion: It is a design flaw, to force workarounds instead of solutions.

There are a lot more details involved than I can think of right now, but I think it comes down to the idea that every class must be constructable by itself. For instance if you inherit from a class with private members, you can't access these private members in the derived class. So they need to be initialized by the parent class, hence the need for super. You don't want to overload constructors, if you inherit some implementation the base class is the proper place to construct things, not the derived class. For some classes to work a constructor is needed, if derived classes are allowed to disable these constructors it will create more of a maintenance nightmare.

> 3. Inability for compiler to determine suitable constructor in hierarchy if no defined in current class. Programmer need to explicitly define dumb constructors passing parameters to super(). My opinion: this is unnecessary redundancy and could lead to maintenance hell when base constructors being changed or even worse - added new.
> 
> It would be excellent if constructors in D were behave like virtual methods. And not forced to call super constructors, please!!!
> 

Consider an abstract base class or interface instead and use composition or possibly mixins for code reuse instead of inheritance. This might solve such problems imho.