This sounds familiar somehow but how about having a derived class with no
constructors automatically have the base's instead of just an empty one?
From my experience, if I've left out calling the super(sufficient, params)
I'm most likely going to just copy all the ones from the base class and
directly call super() with those params. Like Exception specifically:
class MyException: Exception {}
If I don't have a constructor, it could assume Exception's one.
I think, like me, everyone's tired of adding  this(char[] msg)
{ super(msg); } to their exceptions :)  it's not that bad actually, just an
idea here.

It also could be said that classes just assume Object's empty constructor instead of having a dual constructor rule (adding empty one if no base).

I'd rather it be illegal for a subclass to fail to specify a ctor, when its base has done so (of any parameter-count, or visibility, including defaults).

"Vathix" <vathix@dprogramming.com> wrote in message news:bhpvpd$2jol$1@digitaldaemon.com...
> This sounds familiar somehow but how about having a derived class with no
> constructors automatically have the base's instead of just an empty one?
> From my experience, if I've left out calling the super(sufficient, params)
> I'm most likely going to just copy all the ones from the base class and
> directly call super() with those params. Like Exception specifically:
> class MyException: Exception {}
> If I don't have a constructor, it could assume Exception's one.
> I think, like me, everyone's tired of adding  this(char[] msg)
> { super(msg); } to their exceptions :)  it's not that bad actually, just
an
> idea here.
>
> It also could be said that classes just assume Object's empty constructor instead of having a dual constructor rule (adding empty one if no base).
>
>
>

Perhaps, as a compromise, add a keyword 'inherited' to a constructor, which
indicates that the constructor is automatically inherited by derived
classes?
I don't think implicit behavior would be good here, but an explicit keyword
is ok. Drawback is that you cannot see this constructor by reading the
derived class' code; perhaps it would be better to add a special constructor
to the derived class instead (something like 'inherited this( char[] msg )')
and no body

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bhq2ah$2n53$1@digitaldaemon.com...
> I'd rather it be illegal for a subclass to fail to specify a ctor, when
its
> base has done so (of any parameter-count, or visibility, including
> defaults).
>
> "Vathix" <vathix@dprogramming.com> wrote in message news:bhpvpd$2jol$1@digitaldaemon.com...
> > This sounds familiar somehow but how about having a derived class with
no
> > constructors automatically have the base's instead of just an empty one? From my experience, if I've left out calling the super(sufficient,
params)
> > I'm most likely going to just copy all the ones from the base class and
> > directly call super() with those params. Like Exception specifically:
> > class MyException: Exception {}
> > If I don't have a constructor, it could assume Exception's one.
> > I think, like me, everyone's tired of adding  this(char[] msg)
> > { super(msg); } to their exceptions :)  it's not that bad actually, just
> an
> > idea here.
> >
> > It also could be said that classes just assume Object's empty
constructor
> > instead of having a dual constructor rule (adding empty one if no base).
> >
> >
> >
>
>
>

"Jeroen van Bemmel" <anonymous@somewhere.com> wrote in message news:bhqtk7$ukn$1@digitaldaemon.com...
> Perhaps, as a compromise, add a keyword 'inherited' to a constructor,
which
> indicates that the constructor is automatically inherited by derived
> classes?
> I don't think implicit behavior would be good here, but an explicit
keyword
> is ok. Drawback is that you cannot see this constructor by reading the derived class' code; perhaps it would be better to add a special
constructor
> to the derived class instead (something like 'inherited this( char[]
msg )')
> and no body

But is such a case, where's the effort in just calling the base ctor?

Remember, more than 60% of all coding is in the maintenance phase (Robert Glass, 2003), so why does anyone care about a few characters typed at creation time?

This is a non-issue.

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bhrgfi$1ri6$1@digitaldaemon.com...
>
> "Jeroen van Bemmel" <anonymous@somewhere.com> wrote in message news:bhqtk7$ukn$1@digitaldaemon.com...
> > Perhaps, as a compromise, add a keyword 'inherited' to a constructor,
> which
> > indicates that the constructor is automatically inherited by derived
> > classes?
> > I don't think implicit behavior would be good here, but an explicit
> keyword
> > is ok. Drawback is that you cannot see this constructor by reading the derived class' code; perhaps it would be better to add a special
> constructor
> > to the derived class instead (something like 'inherited this( char[]
> msg )')
> > and no body
>
> But is such a case, where's the effort in just calling the base ctor?
>
> Remember, more than 60% of all coding is in the maintenance phase (Robert Glass, 2003), so why does anyone care about a few characters typed at creation time?
>
> This is a non-issue.
>

I find it very tedious if you want a lot of constructors and a lot of derived classes. Functions and variables are inherited from a base class, why have all this extra work for constructors?

"Vathix" <vathix@dprogramming.com> wrote in message news:bhs81d$2sbs$1@digitaldaemon.com...
> "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bhrgfi$1ri6$1@digitaldaemon.com...
> >
> > "Jeroen van Bemmel" <anonymous@somewhere.com> wrote in message news:bhqtk7$ukn$1@digitaldaemon.com...
> > > Perhaps, as a compromise, add a keyword 'inherited' to a constructor,
> > which
> > > indicates that the constructor is automatically inherited by derived
> > > classes?
> > > I don't think implicit behavior would be good here, but an explicit
> > keyword
> > > is ok. Drawback is that you cannot see this constructor by reading the derived class' code; perhaps it would be better to add a special
> > constructor
> > > to the derived class instead (something like 'inherited this( char[]
> > msg )')
> > > and no body
> >
> > But is such a case, where's the effort in just calling the base ctor?
> >
> > Remember, more than 60% of all coding is in the maintenance phase
(Robert
> > Glass, 2003), so why does anyone care about a few characters typed at creation time?
> >
> > This is a non-issue.
> >
>
> I find it very tedious if you want a lot of constructors and a lot of derived classes. Functions and variables are inherited from a base class, why have all this extra work for constructors?

Because a constructor defines the actual state of an object, which is (a)
conceptually different from any regular method, and (b) is a very important
thing, one that should not be implicit.

But as I said, this is just an irrelevance.

If you are writing lots of classes by hand, then they're either different such that they warrant your attention, or they're extremely similar which means that perhaps it's your design that warrants attention. Irregardless, you will want to maintain these classes (I assume we are discussing real software, rather than test programs or toy projects), and the effort of writing these pesky ctors will end up being a squintillionth of the total keystrokes you'll spend on the classes. (This effort will be far less, for all these classes in total, than will be the effort of finding just one weird runtime bug caused as a result of the requested syntax laxity.)

If you're auto-generating your classes, why do you care?

> But as I said, this is just an irrelevance.
>
> If you are writing lots of classes by hand, then they're either different such that they warrant your attention, or they're extremely similar which means that perhaps it's your design that warrants attention. Irregardless, you will want to maintain these classes (I assume we are discussing real software, rather than test programs or toy projects), and the effort of writing these pesky ctors will end up being a squintillionth of the total keystrokes you'll spend on the classes. (This effort will be far less, for all these classes in total, than will be the effort of finding just one weird runtime bug caused as a result of the requested syntax laxity.)
>

I kind of agree with you here, Matt. My remark was more in the context of "suppose [for some reason] you would want this auto-constructor feature", in which case I think it should be something explicit (which requires a bit more typing, which probably annilates the benefits)

This sounds wrong.  What if you intentionally want there to be no (publicly accessible) constructor?  How would you specify that?

I second Vathix's idea.  Make classes with no constructors inherit the superclass's.

I really think there should also be something in D to match C++'s using construct.  So that if you want to change the visibility of a superclass method, you don't have to override it and provide an interface that merely calls the base class.  With that, you could just bring forward your superclass's constructors by using them in your interface in a public section.  Constructors are not the only thing you may want to bring forward.

Think about a class derived from string.  (dumb example, I know, because in D, string is a builtin.)  You make a derived class:

class pathname : public string
{
}

Then you have to add lots of constructors

class pathname : public string
{
    this() { super.this(); }
    this(char[] s) { super.this(s); }
    this(wchar[] s) { super.this(s); }
    this(char* p, uint len) { super.this(p,len); }
    this(pathname f) { super.this(cast(string)f); }
}

You probably want one to match any useful constructor in string.  All I really wanted to do, though, is expose string's constructors and add one of my own:

class pathname : public string
{
    using string.this();
    using string.this(char[] s);
    using string.this(wchar[] s);
    using string.this(char* p, uint len);
    this(pathname f) { super.this(cast(string)f); }
}

But that's almost as wordy as overriding them.  Some way to just import all the superclass constructors would be nice.  You automatically get all the superclass methods, why not constructors?  At least if there was a way to get them...

Sean

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bhq2ah$2n53$1@digitaldaemon.com...
> I'd rather it be illegal for a subclass to fail to specify a ctor, when
its
> base has done so (of any parameter-count, or visibility, including
> defaults).
>
> "Vathix" <vathix@dprogramming.com> wrote in message news:bhpvpd$2jol$1@digitaldaemon.com...
> > This sounds familiar somehow but how about having a derived class with
no
> > constructors automatically have the base's instead of just an empty one? From my experience, if I've left out calling the super(sufficient,
params)
> > I'm most likely going to just copy all the ones from the base class and
> > directly call super() with those params. Like Exception specifically:
> > class MyException: Exception {}
> > If I don't have a constructor, it could assume Exception's one.
> > I think, like me, everyone's tired of adding  this(char[] msg)
> > { super(msg); } to their exceptions :)  it's not that bad actually, just
> an
> > idea here.
> >
> > It also could be said that classes just assume Object's empty
constructor
> > instead of having a dual constructor rule (adding empty one if no base).

That sounds better than "using".  I guess.  But you still have to specify which constructors you mean.

Maybe:


class B : A
{
    public inherit this;  // inherit all constructors from super
    this(B b2) {} // and add a new ctor
}

Maybe we could get some use out of the "super" keyword here.

Sean

"Jeroen van Bemmel" <anonymous@somewhere.com> wrote in message news:bhqtk7$ukn$1@digitaldaemon.com...
> Perhaps, as a compromise, add a keyword 'inherited' to a constructor,
which
> indicates that the constructor is automatically inherited by derived
> classes?
> I don't think implicit behavior would be good here, but an explicit
keyword
> is ok. Drawback is that you cannot see this constructor by reading the derived class' code; perhaps it would be better to add a special
constructor
> to the derived class instead (something like 'inherited this( char[]
msg )')
> and no body

It's an issue that comes up more than you might think, and not only with constructors.  It's similar to the issue of forwarding functions in general. It sucks to be forced to explicitly type in lots of "glue" code.  Code that chains one function to another.  You get this alot in any interface work. It's a maintenance problem because the more code you have to type, the more code that the maintenance programmers must maintain.  And, to use your own argument, more than 60% of all coding is in the maintenance phase.

Say you have a class that has a bug.  Say this class has 50 constructors. You want to subclass this class and fix the bug in your version of the class (the class is someone else's library, you can't change it).  To do so you have to manually, and tediously, write forwarding constructors for all 50 or you lose functionality!  Plus if the base class later gets new ctors, your class won't get them.  You now have a situation where you have to manually maintain 50 direct links to the base class.

It's not a non-issue.  When moving classes around in the hierarchy due to fluctuating designs, you often have to type such glue code.  I'd rather be doing something more productive, save the slave labor.

It's almost as bad as cut and paste programming, but in this case it's interfaces that are getting copied over and over, instead of commands. Still hard to maintain.

Sean

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bhrgfi$1ri6$1@digitaldaemon.com...
>
> "Jeroen van Bemmel" <anonymous@somewhere.com> wrote in message news:bhqtk7$ukn$1@digitaldaemon.com...
> > Perhaps, as a compromise, add a keyword 'inherited' to a constructor,
> which
> > indicates that the constructor is automatically inherited by derived
> > classes?
> > I don't think implicit behavior would be good here, but an explicit
> keyword
> > is ok. Drawback is that you cannot see this constructor by reading the derived class' code; perhaps it would be better to add a special
> constructor
> > to the derived class instead (something like 'inherited this( char[]
> msg )')
> > and no body
>
> But is such a case, where's the effort in just calling the base ctor?
>
> Remember, more than 60% of all coding is in the maintenance phase (Robert Glass, 2003), so why does anyone care about a few characters typed at creation time?
>
> This is a non-issue.