Digital Mars - D - no default values in constructors?

↑ ↓ ← → Evan McClanahan <evan dontSPAMaltarinteractive.com> writes:

Burton Radons wrote:
 Evan McClanahan wrote:
 
 this doesn't compile:

 const int broken = 1;

 class Classy
 {
         int internal;

     this(int i = broken)
     {
         internal = broken;
     }
 }

 as a placeholder example, of course.  there are ways of working around 
 this, but it would be cleaner if it was allowed.


 
 Default arguments aren't a part of the language.
 


I see.  Must have missed that.  Is there any compelling reason not to 
include them?

Evan

Nov 12 2002

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

"Evan McClanahan" <evan dontSPAMaltarinteractive.com> wrote in message
news:aqr3s5$7e1$1 digitaldaemon.com...
 Default arguments aren't a part of the language.


 include them?


They aren't necessary with an optimizing compiler. For example, you could
write:

    foo(int i, int j)
    {
        ...
    }

    foo(int i)
    {
        foo(i, default_j);
    }

and the inlining will eliminate the extra function call.

Nov 12 2002

↑ ↓ ← → "Sandor Hojtsy" <hojtsy index.hu> writes:

"Walter" <walter digitalmars.com> wrote in message
news:aqrjqk$o2d$2 digitaldaemon.com...
 "Evan McClanahan" <evan dontSPAMaltarinteractive.com> wrote in message
 news:aqr3s5$7e1$1 digitaldaemon.com...
 Default arguments aren't a part of the language.


 include them?


 They aren't necessary with an optimizing compiler. For example, you could
 write:

     foo(int i, int j)
     {
         ...
     }

     foo(int i)
     {
         foo(i, default_j);
     }

 and the inlining will eliminate the extra function call.


Not necessary from "executable file size and speed" point of view.
Hopefully there are also some other factors considered during a language
design.
Such as intuitive and concise language structure. Such as self
documentation.
And note the evil redundancy in the example. :-)
What's on the other side? Compiler simplicity?

I think the language would be better with default parameters enabled.

Yours,
Sandor

Nov 13 2002

↑ ↓ ← → "Lloyd Dupont" <lloyd galador.net> writes:

one thing puzzle me.
isn't default parameter evil ?

let me explain and you told me why my example isn'ty relevent:

let say I build a library, shipped as a DLL (let's called it Answer.dll)
with a class
class A
{
    void myfunc(int i = 42) {}
}

you use it.
later the developer of Answer realize that 42 isn't the answer !
maybe it's 43 ?
so he rewrite
class A
{
    void myfunc(int i=43) {}
}


and you upgrade your work to use this dll. you don't need to compile again,
it's a dll !
Alas, nothing work well now, as your code use the old default value...

It seems to me that it's a pretty clear example showing default value are
evil.
don't you think ?


"Sab" <sab neuropolis.org> a �crit dans le message de news:
arnqvt$b8j$1 digitaldaemon.com...
 I think the language would be better with default parameters enabled.


 Seconded.

 One nice feature I do appreciate in many other languages
 is this simple and elegant way of optional initialization.
 I, too, hope D will include this (suposedly cheap?) feature
 in the future.

 Thanks,
 Sab

Nov 23 2002

↑ ↓ ← → Evan McClanahan <evan dontSPAMaltarinteractive.com> writes:

Lloyd Dupont wrote:
 one thing puzzle me.
 isn't default parameter evil ?
 
 let me explain and you told me why my example isn'ty relevent:
 
 let say I build a library, shipped as a DLL (let's called it Answer.dll)
 with a class
 class A
 {
     void myfunc(int i = 42) {}
 }
 
 you use it.
 later the developer of Answer realize that 42 isn't the answer !
 maybe it's 43 ?
 so he rewrite
 class A
 {
     void myfunc(int i=43) {}
 }
 
 
 and you upgrade your work to use this dll. you don't need to compile again,
 it's a dll !
 Alas, nothing work well now, as your code use the old default value...
 
 It seems to me that it's a pretty clear example showing default value are
 evil.
 don't you think ?


It might be pretty clear, but I think that something like that should be 
  pretty rare.  Although that situation isn't unimaginable, I feel that 
it's rathat unlikely, seeing what default values are generally used for, 
   to end up as something like that.  In any case, D provides similar 
functionality in any case, or at least a workaround, so it seems like a 
non-issue to me, as your example is more of a case of working with a DLL 
  provided by a poor software developer than something that's language 
dependant.  Working with other people can always stick it to you...


Evan

Nov 23 2002

↑ ↓ ← → "Sab" <sab neuropolis.org> writes:

 later the developer of Answer realize that 42 isn't the answer !
 maybe it's 43 ?
 so he rewrite
 class A
 {
     void myfunc(int i=43) {}
 }

 and you upgrade your work to use this dll. you don't need to compile


 it's a dll !



Well, here the interface of a library has changed!
So you *do* need to recompile. (Or otherwise get
the change propagated to the client stuff; obviously,
if a system silently swallows an interface conflict,
that stuff is simply broken.)

Sab

Nov 23 2002

↑ ↓ ← → "Sandor Hojtsy" <hojtsy index.hu> writes:

"Sab" <sab neuropolis.org> wrote in message
news:arok6l$147i$1 digitaldaemon.com...
 later the developer of Answer realize that 42 isn't the answer !
 maybe it's 43 ?
 so he rewrite
 class A
 {
     void myfunc(int i=43) {}
 }

 and you upgrade your work to use this dll. you don't need to compile


 it's a dll !



 Well, here the interface of a library has changed!
 So you *do* need to recompile. (Or otherwise get
 the change propagated to the client stuff; obviously,
 if a system silently swallows an interface conflict,
 that stuff is simply broken.)

 Sab



I agree. Default parameter is part of the interface of the function.
And if there is no checking for interface conficts, you can easily cause
other errors:

class A
{
  void myfunc(int i);
}

later changed to

class A
{
  void myfunc(double i);
}

Now do you need to recompile the client side??

Please note that C++ already takes care of this. Since default parameters
are in the header files, changing them causes the client side to recompile.

Do you know any other reasons to label default parameters evil?

Yours,
Sandor

Nov 25 2002

↑ ↓ ← → Farmer <itsFarmer. freenet.de> writes:

[snip]
 
 Do you know any other reasons to label default parameters evil?
 
 Yours,
 Sandor
 
 


Here's another example why default parameters are evil, that I saw on a C++ 
web site.


#include <stdio.h>
struct SomeBaseClass
{
   virtual void func(char* msg="Default parameters are EVIL.")
   {
      printf("%s\n", msg);
   }
};

struct SomeClass : public SomeBaseClass
{
   virtual void func(char* msg="Default parameters would be great for D.")
   {
      SomeBaseClass::func(msg);
   }
};

int main(char*, char*[])
{
   SomeBaseClass* p=new SomeClass();
   p->func();  // print "Default parameters would be great for D." 
   return 0;
}

The output of this program is "Default parameters are EVIL." !!
It is not "Default parameters would be great for D." as one expects at the 
first glance.

If this code is translated to D (with default parameters added), the same 
BUG will exist.



Farmer

Jan 11 2003

↑ ↓ ← → "Mike Wynn" <mike.wynn l8night.co.uk> writes:

I must remember that example,
lack of default params in Java annoyed me for the first few weeks of Java
programming, then you get used to putting in a few more methods;

it could be argued that the compile could create the methods for you rather
than "defaulting" the params
so the D (with "predefined" params) would be
 class SomeBaseClass
 {
    void func(char[] msg="Default parameters are EVIL.")
    {
       printf("%.*s\n", msg);
    }
 };

class SomeClass : public SomeBaseClass
{
    void func(char[] msg="Default parameters in D would could be better that
C++." )
    {
        SomeBaseClass::func(msg);
    }
};

which would create (in effect)

 class SomeBaseClass
 {
    void func()
    {
       func("Default parameters are EVIL.")
    }
    void func(char[] msg)
    {
       printf("%.*s\n", msg);
    }
 };

class SomeClass : public SomeBaseClass
{
    void func()
    {
        func("Default parameters would be great for D.");
    }
    void func(char[] msg="Default parameters in D would could be better that
C++.")
    {
        SomeBaseClass::func(msg);
    }
};

so

int main( char[][] )
{
    SomeBaseClass p = new SomeClass();
    p.func();  // will now print print "Default parameters in D would could
be better that C++."
    return 0;
}

obviously it's the same as C++ that only the end params can be "predefined"
class c {
int func( int a, int b =1, int c) {.. } // this is not allowed. 'c' must be
"predefined" too if you want to predefine 'b'
}

so
class c {
int func( int a, int b =1, int c = 2 ) {.. }
}
would expand to

class c {
int func( int a, int b, int c ) {.. }
int func( int a, int b, ) { return func(a, b, 2); }
int func( int a, ) { return func(a, 1, 2); }
}

that's not to say I agree with default/predefined params, but offer a
slighty less error prone solution if you must have them.

"Farmer" <itsFarmer. freenet.de> wrote in message
news:Xns9300BD258659itsFarmer 63.105.9.61...
 [snip]
 Do you know any other reasons to label default parameters evil?

 Yours,
 Sandor


 Here's another example why default parameters are evil, that I saw on a


 web site.


 #include <stdio.h>
 struct SomeBaseClass
 {
    virtual void func(char* msg="Default parameters are EVIL.")
    {
       printf("%s\n", msg);
    }
 };

 struct SomeClass : public SomeBaseClass
 {
    virtual void func(char* msg="Default parameters would be great for D.")
    {
       SomeBaseClass::func(msg);
    }
 };

 int main(char*, char*[])
 {
    SomeBaseClass* p=new SomeClass();
    p->func();  // print "Default parameters would be great for D."
    return 0;
 }

 The output of this program is "Default parameters are EVIL." !!
 It is not "Default parameters would be great for D." as one expects at the
 first glance.

 If this code is translated to D (with default parameters added), the same
 BUG will exist.



 Farmer

Jan 11 2003

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

You can write it as:

class Classy
{    int internal = 1;

    this() { ... }
    this(int i) { internal = i; }
}

"Evan McClanahan" <evan dontSPAMaltarinteractive.com> wrote in message
news:aqr0p6$4c9$1 digitaldaemon.com...
 this doesn't compile:


 const int broken = 1;

 class Classy
 {
      int internal;

 this(int i = broken)
 {
 internal = broken;
 }
 }

 as a placeholder example, of course.  there are ways of working around
 this, but it would be cleaner if it was allowed.

 Evan

Nov 12 2002

↑ ↓ ← → Evan McClanahan <evan dontSPAMaltarinteractive.com> writes:

Yeah, I figured that.  I just thought that the defaults were a cleaner 
way to write that.  However, it's a small and seldom encountered enough 
  thing that I don't care much.  I was just under the assumption that 
they would be in the language and they weren't.  It's easy enough to 
work around that it doesn't bother me.


Evan


Walter wrote:
 You can write it as:
 
 class Classy
 {    int internal = 1;
 
     this() { ... }
     this(int i) { internal = i; }
 }

Nov 13 2002