www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Class inheritance and string question.

reply "Marcin" <sixpackguy earthlink.net> writes:
I haven't experimented much with D yet, but I spotted something that could
be considered an anomaly to a C++ programmer. Inside the ctor of a derived
class you can call to super to initialize the base portion (this is done
with initializer lists in C++, before the constructor is entered to signify
that base parts are always initialized first, which makes total sense), but
the call to super can be placed anywhere inside the constructor. That means
you get to play around with the derived object before the base parts are set
up, which can cause hell if contained member objects try to use the base
portions. Why isn't this dealt with like in Java, where the call to super
has to be the first call in the constructor, otherwise the default base ctor
is called.
An unrelated question is why does D insist on calling a constructor "this()"
unlike most (all?) other OOP languages? Seems like name pollution to me, and
the keyword this is already reserved for the this reference.

Lastly, I've observed that strings can be initialized like this:
char[] str = null;
That looks very backwards because it allows for code like this:
char[] str = null;
if (str == "")
printf("whatever");

a null reference means there's no string object at all. Yet it (the phantom
string) compares equal to an empty string. Totally unituitive and doesn't
look too well thought out. There's a big discussion about this here:
http://www.osnews.com/comment.php?news_id=6761&offset=30&rows=45 (search for
posts by Marcus, Owen, J.F., ignore the rest)
Jun 09 2004
next sibling parent "Vathix" <vathixSpamFix dprogramming.com> writes:
"Marcin" <sixpackguy earthlink.net> wrote in message
news:ca8hdu$1jnl$1 digitaldaemon.com...
...
 Lastly, I've observed that strings can be initialized like this:
 char[] str = null;
 That looks very backwards because it allows for code like this:
 char[] str = null;
 if (str == "")
 printf("whatever");

 a null reference means there's no string object at all. Yet it (the

 string) compares equal to an empty string. Totally unituitive and doesn't
 look too well thought out. There's a big discussion about this here:
 http://www.osnews.com/comment.php?news_id=6761&offset=30&rows=45 (search

 posts by Marcus, Owen, J.F., ignore the rest)

null is a special case char[] that means address 0 and length 0. When you compare its value with "", they are equal, like: memcmp("", NULL, 0);
Jun 09 2004
prev sibling next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Marcin" <sixpackguy earthlink.net> wrote in message
news:ca8hdu$1jnl$1 digitaldaemon.com...
 I haven't experimented much with D yet, but I spotted something that could
 be considered an anomaly to a C++ programmer.

There are lots of those. D does not purport to be a haven solely for disenchanted C++ programmers. It offers many things to many viewpoints.
 Inside the ctor of a derived
 class you can call to super to initialize the base portion (this is done
 with initializer lists in C++, before the constructor is entered to signify
 that base parts are always initialized first, which makes total sense), but
 the call to super can be placed anywhere inside the constructor. That means
 you get to play around with the derived object before the base parts are set
 up, which can cause hell if contained member objects try to use the base
 portions. Why isn't this dealt with like in Java, where the call to super
 has to be the first call in the constructor, otherwise the default base ctor
 is called.

This is an important point.
 An unrelated question is why does D insist on calling a constructor "this()"
 unlike most (all?) other OOP languages? Seems like name pollution to me, and
 the keyword this is already reserved for the this reference.

This is a pretty trivial issue, don't you think?
 Lastly, I've observed that strings can be initialized like this:
 char[] str = null;
 That looks very backwards because it allows for code like this:
 char[] str = null;
 if (str == "")
 printf("whatever");

 a null reference means there's no string object at all. Yet it (the phantom
 string) compares equal to an empty string. Totally unituitive and doesn't
 look too well thought out.

I think when you get used to it you'll see that it's anything but. It's actually extremenly convenient.
 There's a big discussion about this here:
 http://www.osnews.com/comment.php?news_id=6761&offset=30&rows=45 (search for
 posts by Marcus, Owen, J.F., ignore the rest)

Jun 09 2004
prev sibling next sibling parent James Widman <james jwidman.com> writes:
In article <ca8hdu$1jnl$1 digitaldaemon.com>,
 "Marcin" <sixpackguy earthlink.net> wrote:
 An unrelated question is why does D insist on calling a constructor "this()"
 unlike most (all?) other OOP languages? 

It probably makes life simpler for the parser to have a special name for special functions like that. At any rate, it's simpler than C++, where ctors don't really have names (seeISO C++2003 12.1). Also, special names for ctors are not unheard of in other OO languages. See Python and Ruby for examples. Using 'this' as that special name shouldn't lead us down the path of extreme ambiguity. this() is a ctor, this is the literal "this", and this.this is probably the ctor. :-) James
Jun 09 2004
prev sibling next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <ca8hdu$1jnl$1 digitaldaemon.com>, Marcin says...
I haven't experimented much with D yet, but I spotted something that could
be considered an anomaly to a C++ programmer. Inside the ctor of a derived
class you can call to super to initialize the base portion (this is done
with initializer lists in C++, before the constructor is entered to signify
that base parts are always initialized first, which makes total sense), but
the call to super can be placed anywhere inside the constructor. That means
you get to play around with the derived object before the base parts are set
up, which can cause hell if contained member objects try to use the base
portions. Why isn't this dealt with like in Java, where the call to super
has to be the first call in the constructor, otherwise the default base ctor
is called.

I actually really like that way that D does this. I've had some problems with both C++ and Java. I can't remember the details, but I think it was something like:
    MyClass()  // Java constructor - D would use this()
    {
        try
        {
            super();
            /* the rest */
        }
        catch (Exception e)
        {
             /* do something else */
        }
    }

I may have got the details wrong, but it was something like that. Anyway, Java freaked out because super() wasn't the first thing in the constructor - but you can clearly see it makes perfect sense. Similar problems arise (in Java) if you try to replace try { ... } with synchronized(SomeObject) { ... }. Another situation is:
    this(MyEnum e)
    {
        switch(e)
        {
            case MyEnum.CASE1: super(parameters for case 1); break;
            case MyEnum.CASE2: super(parameters for case 2); break;
            case MyEnum.CASE3: super(parameters for case 3); break;
    ...etc.

No, on the whole, I think D has got it right. If you want super() called first, then call it first, or don't explicitly call it at all. But there will always be the odd special case where you really need to do something differently. Arcane Jill
Jun 09 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:ca8vto$2ahj$1 digitaldaemon.com...
 In article <ca8hdu$1jnl$1 digitaldaemon.com>, Marcin says...
I haven't experimented much with D yet, but I spotted something that could
be considered an anomaly to a C++ programmer. Inside the ctor of a derived
class you can call to super to initialize the base portion (this is done
with initializer lists in C++, before the constructor is entered to signify
that base parts are always initialized first, which makes total sense), but
the call to super can be placed anywhere inside the constructor. That means
you get to play around with the derived object before the base parts are set
up, which can cause hell if contained member objects try to use the base
portions. Why isn't this dealt with like in Java, where the call to super
has to be the first call in the constructor, otherwise the default base ctor
is called.

I actually really like that way that D does this. I've had some problems with both C++ and Java. I can't remember the details, but I think it was something like:
    MyClass()  // Java constructor - D would use this()
    {
        try
        {
            super();
            /* the rest */
        }
        catch (Exception e)
        {
             /* do something else */
        }
    }

I may have got the details wrong, but it was something like that. Anyway, Java freaked out because super() wasn't the first thing in the constructor - but you can clearly see it makes perfect sense.

Not in the slightest, I'm afraid. If you were allowed to do that, you'd have a "validly" constructed MyClass instance whose base class portion was undefined. Very bad.
Jun 10 2004
next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <ca9286$2fe1$1 digitaldaemon.com>, Matthew says...
Not in the slightest, I'm afraid. If you were allowed to do that, you'd have a
"validly" constructed MyClass instance whose base class portion was undefined.
Very bad.

Well, of course, you can do that in C++. This compiles fine using gcc:
   class A
   {
   public :
           A(void);
   };
   
   A::A(void)
   {
   }
   
   class B : public A
   {
   public :
           B(void);
   };

   // This is the interesting bit
   B::B(void)
   try : A()
   {
   }
   catch (...)
   {
   }
   
   int main(void)
   {
   }

Check out the strange and rarely used C++ syntax for the constructor B::B. It will catch exceptions which are thrown in the base class. Arcane Jill
Jun 10 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:ca94m4$2ius$1 digitaldaemon.com...
 In article <ca9286$2fe1$1 digitaldaemon.com>, Matthew says...
Not in the slightest, I'm afraid. If you were allowed to do that, you'd have a
"validly" constructed MyClass instance whose base class portion was undefined.
Very bad.

Well, of course, you can do that in C++. This compiles fine using gcc:
   class A
   {
   public :
           A(void);
   };

   A::A(void)
   {
   }

   class B : public A
   {
   public :
           B(void);
   };

   // This is the interesting bit
   B::B(void)
   try : A()
   {
   }
   catch (...)
   {
   }

   int main(void)
   {
   }

Check out the strange and rarely used C++ syntax for the constructor B::B. It will catch exceptions which are thrown in the base class.

Of course. But C++ trusts the programmer and Java does not.
Jun 10 2004
parent "Jan-Eric Duden" <jeduden whisset.com> writes:
And D trusts the programmer, too. :)
And I like that.

-- 
Jan-Eric Duden
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:ca96fo$2lbm$1 digitaldaemon.com...
 "Arcane Jill" <Arcane_member pathlink.com> wrote in message
 news:ca94m4$2ius$1 digitaldaemon.com...
 In article <ca9286$2fe1$1 digitaldaemon.com>, Matthew says...
Not in the slightest, I'm afraid. If you were allowed to do that, you'd



"validly" constructed MyClass instance whose base class portion was



Very bad.

Well, of course, you can do that in C++. This compiles fine using gcc:
   class A
   {
   public :
           A(void);
   };

   A::A(void)
   {
   }

   class B : public A
   {
   public :
           B(void);
   };

   // This is the interesting bit
   B::B(void)
   try : A()
   {
   }
   catch (...)
   {
   }

   int main(void)
   {
   }

Check out the strange and rarely used C++ syntax for the constructor


 will catch exceptions which are thrown in the base class.

Of course. But C++ trusts the programmer and Java does not.

Jun 10 2004
prev sibling parent reply "Marcin" <sixpackguy earthlink.net> writes:
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:ca9286$2fe1$1 digitaldaemon.com...
 Not in the slightest, I'm afraid. If you were allowed to do that, you'd

 "validly" constructed MyClass instance whose base class portion was

 Very bad.

Exactly. That's why you can't do it in C++/Java/C#. Altough I prefer C++/C# syntax because it lets you catch base class exceptions and then translate and rethrow. With D you have to be careful about your member objects not to call any base portions or it will be undefined, and you have to be careful not to call any methods/functions that will use base poritions or the result will be undefined. Wouldn't it be much better and logical if base class portions were guaranteed to have finished before you can write a single line of code in the derived ctor?
Jun 10 2004
parent reply Sean Kelly <sean f4.ca> writes:
In article <caa5q6$1844$1 digitaldaemon.com>, Marcin says...
Exactly. That's why you can't do it in C++/Java/C#. Altough I prefer C++/C#
syntax because it lets you catch base class exceptions and then translate
and rethrow. With D you have to be careful about your member objects not to
call any base portions or it will be undefined, and you have to be careful
not to call any methods/functions that will use base poritions or the result
will be undefined. Wouldn't it be much better and logical if base class
portions were guaranteed to have finished before you can write a single line
of code in the derived ctor?

Is this even an issue? Why not just do this: class A {} class B { this() { try { super(); } catch( Exception e ) { throw new DerivedException(); } } } It seems far cleaner than the function try blocks in C++. Sean
Jun 10 2004
next sibling parent reply "Marcin" <sixpackguy earthlink.net> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:caa790$1adj$1 digitaldaemon.com...
 In article <caa5q6$1844$1 digitaldaemon.com>, Marcin says...
Exactly. That's why you can't do it in C++/Java/C#. Altough I prefer


syntax because it lets you catch base class exceptions and then translate
and rethrow. With D you have to be careful about your member objects not


call any base portions or it will be undefined, and you have to be


not to call any methods/functions that will use base poritions or the


will be undefined. Wouldn't it be much better and logical if base class
portions were guaranteed to have finished before you can write a single


of code in the derived ctor?

Is this even an issue? Why not just do this: class A {} class B { this() { try { super(); } catch( Exception e ) { throw new DerivedException(); } } } It seems far cleaner than the function try blocks in C++. Sean

You're missing the big picture. I'm not arguing over which syntax is better. Take a look at this: class base { private: int x; public: void print() { printf("%d\n", x); } this() { x = 8; printf("constructing base\n"); } } class derived : base { this() { print(); super(); } } When you construct a derived object, you're accessing a function (print) in an object that doesn't exist yet - base. If this isn't a recipe for disaster then I don't know what is. This must not ever happen. You should really read this: http://www.gotw.ca/gotw/066.htm .
Jun 10 2004
next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <caadke$1jmk$1 digitaldaemon.com>, Marcin says...
class derived : base
{
 this()
 {
  print();
  super();
 }
}

This is just trying to use an object that wasn't instanciated. It's the same as: base b; b.print(); (javac for example will issue an error) I don't see a big problem with it. Ant
Jun 10 2004
parent reply Sean Kelly <sean f4.ca> writes:
In article <caaed0$1km1$1 digitaldaemon.com>, Ant says...
In article <caadke$1jmk$1 digitaldaemon.com>, Marcin says...
class derived : base
{
 this()
 {
  print();
  super();
 }
}

This is just trying to use an object that wasn't instanciated. It's the same as: base b; b.print(); (javac for example will issue an error) I don't see a big problem with it.

This is slightly different. If a class has a constructor then it's safe to assume that something inside that class requires initialization in order to work properly. Assuming the class only contains standard D class references and such then the worst that will happen is the runtime error you've mentioned. But assume for a moment that the class uses pointers, special memory allocators, and all sorts of other weirdness. In that case the program may crash horribly if a function is called on the class before it is properly initialized. So in general terms: "the result of calling a function on an unconstructed class instance is undefined." Usually this means the app will crash but it can also lead to either subtle bugs or crazy stuff like your hard drive being erased. Slightly different from trying to access a null reference :) Sean
Jun 10 2004
parent Ant <Ant_member pathlink.com> writes:
In article <caaevs$1llt$1 digitaldaemon.com>, Sean Kelly says...
This is slightly different.

assume for a moment that the class uses pointers, special memory allocators, and
all sorts of other weirdness.

I see, thanks. But I still like this feature, I believe I use it somewhere. Ant
Jun 10 2004
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <caadke$1jmk$1 digitaldaemon.com>, Marcin says...
You're missing the big picture. I'm not arguing over which syntax is better.
Take a look at this:

class base
{
 private:
 int x;
 public:
 void print()
 {
   printf("%d\n", x);
 }
 this()
 {
  x = 8;
  printf("constructing base\n");
 }
}

class derived : base
{
 this()
 {
  print();
  super();
 }
}

When you construct a derived object, you're accessing a function (print) in
an object that doesn't exist yet - base. If this isn't a recipe for disaster
then I don't know what is. This must not ever happen.

Certainly. D is a tad different from C++ in that it doesn't require superclasses to be initialized first. This is fine so long as the user isn't foolish enough to try your example above :) And I should point out this quote from the D docs: "If no call to constructors via this or super appear in a constructor, and the base class has a constructor, a call to super() is inserted at the beginning of the constructor." So assuming the user isn't deliberately foolish then everything will work out fine. There's really no reason to explicitly call a superclass constructor with no parameters unless you want to catch any exceptions it throws. Sean
Jun 10 2004
parent "Marcin" <sixpackguy earthlink.net> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:caaekv$1l7h$1 digitaldaemon.com...
 In article <caadke$1jmk$1 digitaldaemon.com>, Marcin says...

 Certainly.  D is a tad different from C++ in that it doesn't require
 superclasses to be initialized first.  This is fine so long as the user

 foolish enough to try your example above :)  And I should point out this

 from the D docs:

 "If no call to constructors via this or super appear in a constructor, and

 base class has a constructor, a call to super() is inserted at the

 the constructor."

 So assuming the user isn't deliberately foolish then everything will work

 fine.  There's really no reason to explicitly call a superclass

 no parameters unless you want to catch any exceptions it throws.


 Sean

The example was contrived on purpose so that you can see my point. A lot of times you write code and unknowingly it pretty much does what I just showed you, except now you will be chasing an extremely obscure bug. It's like programming in C, you always want your programs leak and bug free and you never intend to write such programs, but they still happen more often that you'd like to admit to. Having the language help you out is priceless. D doesn't do that and therefore it invites a whole host of bugs. Secondly, why would you not want base class portions initialized first? Would you not start constructing any building with the foundations? All other mature languages guarantee base parts are set up first because it just makes sense from a design standpoint.
Jun 10 2004
prev sibling next sibling parent Arcane Jill <Arcane_member pathlink.com> writes:
In article <caadke$1jmk$1 digitaldaemon.com>, Marcin says...

When you construct a derived object, you're accessing a function (print) in
an object that doesn't exist yet - base. If this isn't a recipe for disaster
then I don't know what is.

So don't do it then. It's not compulsory. Look, you can reason by similar argument that a constructor should not be allowed to call any member function of its own class, because, by definition, if the constructor hasn't returned yet, the object isn't fully constructed yet. Look see:
   class A
   {
       this()
       {
           print();
           printf("finished constructing A\n");
       }

       void print()
       {
           printf("executing A.print()\n");
       }
    }

We can all write dumb code. The trick is, not to. As things stand, D constructors are nice and readable, and if you do something dumb you can expect your program to fall over. And that's how it should be. Compile-time error checking is there to catch the kinds of errors which are NOT obvious. C++ gives you a tortured syntax which make it much harder to figure out construction order. In D you can just SEE it. So I'm not convinced that either the Java way or the C++ way is better. I still think that D has got the better balance between readability and safety, without compromising what you can do. Arcane Jill
Jun 10 2004
prev sibling next sibling parent Jan-Eric Duden <jeduden whisset.com> writes:
Marcin wrote:
 "Sean Kelly" <sean f4.ca> wrote in message
 news:caa790$1adj$1 digitaldaemon.com...
 
In article <caa5q6$1844$1 digitaldaemon.com>, Marcin says...

Exactly. That's why you can't do it in C++/Java/C#. Altough I prefer


C++/C#
syntax because it lets you catch base class exceptions and then translate
and rethrow. With D you have to be careful about your member objects not


to
call any base portions or it will be undefined, and you have to be


careful
not to call any methods/functions that will use base poritions or the


result
will be undefined. Wouldn't it be much better and logical if base class
portions were guaranteed to have finished before you can write a single


line
of code in the derived ctor?

Is this even an issue? Why not just do this: class A {} class B { this() { try { super(); } catch( Exception e ) { throw new DerivedException(); } } } It seems far cleaner than the function try blocks in C++. Sean

You're missing the big picture. I'm not arguing over which syntax is better. Take a look at this: class base { private: int x; public: void print() { printf("%d\n", x); } this() { x = 8; printf("constructing base\n"); } } class derived : base { this() { print(); super(); } } When you construct a derived object, you're accessing a function (print) in an object that doesn't exist yet - base. If this isn't a recipe for disaster then I don't know what is. This must not ever happen. You should really read this: http://www.gotw.ca/gotw/066.htm .

class A { int b; this() { print(); b=1; } void print() { assert(b==1); } } Thus I don't see a problem, with the way D does it with super and derived classes. It actually allows the programmer to do stuff without writing create/inits methods as they are needed in C++. For me this issue is really a no brainer.
Jun 10 2004
prev sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Marcin" <sixpackguy earthlink.net> wrote in message
news:caadke$1jmk$1 digitaldaemon.com...
 "Sean Kelly" <sean f4.ca> wrote in message
 news:caa790$1adj$1 digitaldaemon.com...
 In article <caa5q6$1844$1 digitaldaemon.com>, Marcin says...
Exactly. That's why you can't do it in C++/Java/C#. Altough I prefer


syntax because it lets you catch base class exceptions and then translate
and rethrow. With D you have to be careful about your member objects not


call any base portions or it will be undefined, and you have to be


not to call any methods/functions that will use base poritions or the


will be undefined. Wouldn't it be much better and logical if base class
portions were guaranteed to have finished before you can write a single


of code in the derived ctor?

Is this even an issue? Why not just do this: class A {} class B { this() { try { super(); } catch( Exception e ) { throw new DerivedException(); } } } It seems far cleaner than the function try blocks in C++. Sean

You're missing the big picture. I'm not arguing over which syntax is better. Take a look at this: class base { private: int x; public: void print() { printf("%d\n", x); } this() { x = 8; printf("constructing base\n"); } } class derived : base { this() { print(); super(); } }

I agree with what you're saying (and I bet Sean does also).
Jun 10 2004
prev sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:caa790$1adj$1 digitaldaemon.com...
 In article <caa5q6$1844$1 digitaldaemon.com>, Marcin says...
Exactly. That's why you can't do it in C++/Java/C#. Altough I prefer C++/C#
syntax because it lets you catch base class exceptions and then translate
and rethrow. With D you have to be careful about your member objects not to
call any base portions or it will be undefined, and you have to be careful
not to call any methods/functions that will use base poritions or the result
will be undefined. Wouldn't it be much better and logical if base class
portions were guaranteed to have finished before you can write a single line
of code in the derived ctor?

Is this even an issue? Why not just do this: class A {} class B { this() { try { super(); } catch( Exception e ) { throw new DerivedException(); } } } It seems far cleaner than the function try blocks in C++.

It should have the same requirement as in C++, that one cannot leave the ctor body (once an x has been caught) via a return statement, but should require the coder to write a throw expression (even if it's only "throw;") One thing I find important a lot in C++ is the ability to be able to write and call static methods in the initialiser list. I'd like to be able to do the same prior to calling super(), and I imagine that I probably can at the moment in D. Anyone know?
Jun 10 2004
parent Sean Kelly <sean f4.ca> writes:
In article <caan2q$22ap$1 digitaldaemon.com>, Matthew says...
It should have the same requirement as in C++, that one cannot leave the ctor
body (once an x has been caught) via a return statement, but should require the
coder to write a throw expression (even if it's only "throw;")

I agree completely.
One thing I find important a lot in C++ is the ability to be able to write and
call static methods in the initialiser list. I'd like to be able to do the same
prior to calling super(), and I imagine that I probably can at the moment in D.
Anyone know?

I would be shocked if this weren't allowed. Some pertinent bits from the spec just to back up my guess: "All member initializations must be determinable by the compiler at compile time, hence there is no order-of-evaluation dependency for member initializations, and it is not possible to read a value that has not been initialized." "static this() is called by the startup code before main() is called. . . A current weakness of the static constructors is that the order in which they are called is not defined." So it looks like dependent singleton types may still have some issues but otherwise all should work as expected. Sean
Jun 10 2004
prev sibling parent reply Trejkaz Xaoza <trejkaz xaoza.net> writes:
In article <ca8hdu$1jnl$1 digitaldaemon.com>, Marcin says...
the call to super can be placed anywhere inside the constructor. That means
you get to play around with the derived object before the base parts are set
up, which can cause hell if contained member objects try to use the base
portions. Why isn't this dealt with like in Java, where the call to super
has to be the first call in the constructor, otherwise the default base ctor
is called.

Probably because in Java, you end up with problems like not being able to do this (translated to D for the sake of the group): class NamedObject { private char[] name; this(char[] name) { this.name = name; } } class NonNullNamedObject : NamedObject { this(char[] name) { if (name is null) { //...throw some exception... } super(name); } } The workaround in this case is obviously to call super(name) first and then to check the value, but wouldn't it make more sense to check the value first before creating a useless object? I figure statements before the super() should be permitted, but perhaps D could just prohibit non-static methods being called. TX
Jun 10 2004
next sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <cabl7p$cm3$1 digitaldaemon.com>, Trejkaz Xaoza says...
In article <ca8hdu$1jnl$1 digitaldaemon.com>, Marcin says...
the call to super can be placed anywhere inside the constructor. That means
you get to play around with the derived object before the base parts are set
up, which can cause hell if contained member objects try to use the base
portions. Why isn't this dealt with like in Java, where the call to super
has to be the first call in the constructor, otherwise the default base ctor
is called.

Probably because in Java, you end up with problems like not being able to do this (translated to D for the sake of the group): class NamedObject { private char[] name; this(char[] name) { this.name = name; } } class NonNullNamedObject : NamedObject { this(char[] name) { if (name is null) { //...throw some exception... } super(name); } } The workaround in this case is obviously to call super(name) first and then to check the value, but wouldn't it make more sense to check the value first before creating a useless object?

I would solve your example by having preconditions for super.this(), but I think that's a flaw in the example rather than the idea itself. Suppose a derived class wants to choose which base class constructor to call depending on calculated data? class Derived : Super { ...this( int x ) ...{ .......switch( calculateSomethingWith( x ) ) .......{ .......case 1: super(); break; .......case 2: super( someValue ); break; .......} ...} } In this case the superclass constructor is neither the first call in the derived constructor nor even the first function/method called in the derived constructor, yet the approach seems perfectly legitimate provided the programmer is careful. Sean
Jun 11 2004
parent reply Trejkaz Xaoza <trejkaz xaoza.net> writes:
In article <cacsum$23rb$1 digitaldaemon.com>, Sean Kelly says... 
I would solve

think
that's a

The entire _point_ of checking the value was to check the precondition. Or is there another way? Excluding the in and out blocks, of course, as those are compiled out for release builds, and it's hardly acceptable for your program to work in all cases except the release build. TX
Jun 11 2004
parent Sean Kelly <sean f4.ca> writes:
In article <cae121$mon$1 digitaldaemon.com>, Trejkaz Xaoza says...
In article <cacsum$23rb$1 digitaldaemon.com>, Sean Kelly says... 
I would solve

think
that's a

The entire _point_ of checking the value was to check the precondition. Or is there another way? Excluding the in and out blocks, of course, as those are compiled out for release builds, and it's hardly acceptable for your program to work in all cases except the release build.

I had meant the in/out blocks. Verifying pre and postconditions is what DBC is for, and in many cases debug testing is sufficient to insure acceptable program correctness. Critical software, however, may actually ship with the in/out blocks still in place, as program failure is not an option. If you're worried about performance then just make sure that the code in in/out is fairly efficient, or put in Internal and Production version blocks. Sean
Jun 12 2004
prev sibling parent reply Sam McCall <tunah.d tunah.net> writes:
Trejkaz Xaoza wrote:

 Probably because in Java, you end up with problems like not being able to do
 this (translated to D for the sake of the group):

Which is silly, because you can just do this, if the superclass takes at least one parameter: class NonNullNamedObject : NamedObject { this(char[] name) { super(preconstruct(name)); } char[] preconstruct(char[] name) { if(name is null) { // whatever } return name; } } Just having the compiler add an assert that a superconstructor got called exactly once (only in debug mode of course) sounds like enough to me. Sam
Jun 13 2004
parent reply Trejkaz Xaoza <trejkaz xaoza.net> writes:
Naturally.  That code works in D because it doesn't have the restrictions of
Java.  Java would have complained about code like that since you're calling a
method before the object is instantiated.  I guess you can use a static method
to avoid that, but then again that example I gave wasn't the exact case which I
have encountered anyway, more a simulation. :-)

But anyway... since I have a preference towards developing library code as
opposed to application code, I like being over-careful with what gets passed in.
Having my own code go through debug testing a thousand times doesn't help, if
someone linking to my library passes in a bad value (this is also why I don't
like to rely on the in/out blocks, since I can't guarantee the application which
includes my code will actually compile them in!  I guess if the specification
said in/out blocks were always put in, it would be a different issue.)

Anyway, D's going the right way about it.  'Trust the developer' seems to be its
philosophy and allowing the superconstructor call anywhere is adhering to that.

TX

In article <cahg14$2p7c$1 digitaldaemon.com>, Sam McCall says...
Trejkaz Xaoza wrote:

 Probably because in Java, you end up with problems like not being able to do
 this (translated to D for the sake of the group):

Which is silly, because you can just do this, if the superclass takes at least one parameter: class NonNullNamedObject : NamedObject { this(char[] name) { super(preconstruct(name)); } char[] preconstruct(char[] name) { if(name is null) { // whatever } return name; } } Just having the compiler add an assert that a superconstructor got called exactly once (only in debug mode of course) sounds like enough to me. Sam

Jun 13 2004
parent Sam McCall <tunah.d tunah.net> writes:
Trejkaz Xaoza wrote:

 Naturally.  That code works in D because it doesn't have the restrictions of
 Java.  Java would have complained about code like that since you're calling a
 method before the object is instantiated.  I guess you can use a static method
 to avoid that, but then again that example I gave wasn't the exact case which I
 have encountered anyway, more a simulation. :-)

like it before as a hack, but it was static before, which is a different kettle of fish. Of course it works in D, in D you can put the code before the super() call ;-)
 Having my own code go through debug testing a thousand times doesn't help, if
 someone linking to my library passes in a bad value (this is also why I don't
 like to rely on the in/out blocks, since I can't guarantee the application
which
 includes my code will actually compile them in!  I guess if the specification
 said in/out blocks were always put in, it would be a different issue.)
 
 Anyway, D's going the right way about it.  'Trust the developer' seems to be
its
 philosophy and allowing the superconstructor call anywhere is adhering to that.

library incorrectly, never did a debug build, and released their program complete with resultant bugs then they were a lost cause anyway ;) Sam
Jun 13 2004