www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - member arguments in D?

reply Penguin <davidcollien gmail.com> writes:
What do you think about:

class Foo {

   int a;
   float b;

   this( member a, member b ) {

   } 

}

instead of:

class Foo {

   int a;
   float b;

   this( int a, float b ) {
      this.a = a;
      this.b = b;
   } 

}
Apr 26 2009
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Penguin wrote:

 What do you think about:
 
 class Foo {
 
    int a;
    float b;
 
    this( member a, member b ) {
 
    } 
 
 }
 
 instead of:
 
 class Foo {
 
    int a;
    float b;
 
    this( int a, float b ) {
       this.a = a;
       this.b = b;
    } 
 
 }



I don't know that saving a few (very simple) lines of code is worth
adding a new keyword and magic behaviour to ctor arguments.

If you really wanted to just do that, you could probably write a mixin
to take care of it.

  -- Daniel
Apr 26 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel Keep" <daniel.keep.lists gmail.com> wrote in message 
news:gt159p$1bq0$1 digitalmars.com...

 Penguin wrote:

 What do you think about:

 class Foo {

    int a;
    float b;

    this( member a, member b ) {

    }

 }

 instead of:

 class Foo {

    int a;
    float b;

    this( int a, float b ) {
       this.a = a;
       this.b = b;
    }

 }



 I don't know that saving a few (very simple) lines of code is worth
 adding a new keyword and magic behaviour to ctor arguments.

 If you really wanted to just do that, you could probably write a mixin
 to take care of it.



I just happen to already have such a thing in my bag-o-tricks. See 
attachment.

Usage:
----
mixin(initMember!(someVar));
mixin(initMember!(a, b, c));
----

Turns Into:
----
this.someVar = someVar;
this.a = a;
this.b = b;
this.c = c;
----
Apr 26 2009
next sibling parent reply downs <default_357-line yahoo.de> writes:
Nick Sabalausky wrote:

 "Daniel Keep" <daniel.keep.lists gmail.com> wrote in message 
 news:gt159p$1bq0$1 digitalmars.com...

 Penguin wrote:

 What do you think about:

 class Foo {

    int a;
    float b;

    this( member a, member b ) {

    }

 }

 instead of:

 class Foo {

    int a;
    float b;

    this( int a, float b ) {
       this.a = a;
       this.b = b;
    }

 }



 adding a new keyword and magic behaviour to ctor arguments.

 If you really wanted to just do that, you could probably write a mixin
 to take care of it.



 I just happen to already have such a thing in my bag-o-tricks. See 
 attachment.
 
 Usage:
 ----
 mixin(initMember!(someVar));
 mixin(initMember!(a, b, c));
 ----
 
 Turns Into:
 ----
 this.someVar = someVar;
 this.a = a;
 this.b = b;
 this.c = c;
 ----
 
 
 



I _also_ have something for this for Phobos (in tools.base), but it's intended
for simple constructors.

class Foo {
  int a; float b;
  mixin This!("a, b");
}

Or to add some instruction: mixin This!("a; #b = 0f; ");

Or to add a super call and defaults: mixin This!("a, super(b=0f)");
Apr 26 2009
parent reply DisForDave <dave icy.com.au> writes:
downs Wrote:


 Nick Sabalausky wrote:

 "Daniel Keep" <daniel.keep.lists gmail.com> wrote in message 
 news:gt159p$1bq0$1 digitalmars.com...

 Penguin wrote:

 What do you think about:

 class Foo {

    int a;
    float b;

    this( member a, member b ) {

    }

 }

 instead of:

 class Foo {

    int a;
    float b;

    this( int a, float b ) {
       this.a = a;
       this.b = b;
    }

 }



 adding a new keyword and magic behaviour to ctor arguments.

 If you really wanted to just do that, you could probably write a mixin
 to take care of it.



 I just happen to already have such a thing in my bag-o-tricks. See 
 attachment.
 
 Usage:
 ----
 mixin(initMember!(someVar));
 mixin(initMember!(a, b, c));
 ----
 
 Turns Into:
 ----
 this.someVar = someVar;
 this.a = a;
 this.b = b;
 this.c = c;
 ----
 
 
 



 I _also_ have something for this for Phobos (in tools.base), but it's intended
for simple constructors.
 
 class Foo {
   int a; float b;
   mixin This!("a, b");
 }
 
 Or to add some instruction: mixin This!("a; #b = 0f; ");
 
 Or to add a super call and defaults: mixin This!("a, super(b=0f)");




but this is something the compiler should really be dealing with, it's such a
common programming practice (the fact so many people have their own hacks for
it is testament to this)

i think it's worth a new keyword
Apr 26 2009
parent downs <default_357-line yahoo.de> writes:
DisForDave wrote:

 downs Wrote:
 

 Nick Sabalausky wrote:

 "Daniel Keep" <daniel.keep.lists gmail.com> wrote in message 
 news:gt159p$1bq0$1 digitalmars.com...

 Penguin wrote:

 What do you think about:

 class Foo {

    int a;
    float b;

    this( member a, member b ) {

    }

 }

 instead of:

 class Foo {

    int a;
    float b;

    this( int a, float b ) {
       this.a = a;
       this.b = b;
    }

 }



 adding a new keyword and magic behaviour to ctor arguments.

 If you really wanted to just do that, you could probably write a mixin
 to take care of it.



 attachment.

 Usage:
 ----
 mixin(initMember!(someVar));
 mixin(initMember!(a, b, c));
 ----

 Turns Into:
 ----
 this.someVar = someVar;
 this.a = a;
 this.b = b;
 this.c = c;
 ----




 class Foo {
   int a; float b;
   mixin This!("a, b");
 }

 Or to add some instruction: mixin This!("a; #b = 0f; ");

 Or to add a super call and defaults: mixin This!("a, super(b=0f)");



 
 but this is something the compiler should really be dealing with, it's such a
common programming practice (the fact so many people have their own hacks for
it is testament to this)
 
 i think it's worth a new keyword



But that's the point - the language is powerful enough that the hacks work fine.

No _need_ for a keyword.
Apr 26 2009
prev sibling parent reply grauzone <none example.net> writes:
Do people really like such code and not cringe over how unclean and 
inelegant it is? Maybe it's just me...
Apr 26 2009
parent DisForDave <dave icy.com.au> writes:
grauzone Wrote:


 Do people really like such code and not cringe over how unclean and 
 inelegant it is? Maybe it's just me...



it's not just you - i agree totally. If i wanted inelegant hacks, i'd be using
C++
plus I always like a standard way of doing simple things.
Apr 26 2009
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 26 Apr 2009 04:17:04 -0400, Daniel Keep  
<daniel.keep.lists gmail.com> wrote:


 Penguin wrote:

 What do you think about:

 class Foo {

    int a;
    float b;

    this( member a, member b ) {

    }

 }

 instead of:

 class Foo {

    int a;
    float b;

    this( int a, float b ) {
       this.a = a;
       this.b = b;
    }

 }



 I don't know that saving a few (very simple) lines of code is worth
 adding a new keyword and magic behaviour to ctor arguments.

 If you really wanted to just do that, you could probably write a mixin
 to take care of it.



There are three benefits I see to the proposal:

1. It saves typing.  This is not usually a big deal, except that this sort  
of constructor is EXTREMELY common with container objects.
2. It saves having to specify the type.  We get the same savings from  
"auto," it should be similar here.  In fact, you could probably change the  
keyword "member" to "auto".
3. It's a little more self documenting.  You know when you see the  
function signature, that what you pass in will at least start being the  
initial value of the named member.

The drawback of course is the keyword.  the magic behavior is not a  
drawback IMO (in fact, it is the point).

If you used auto as the keyword, you don't add a keyword.

I'd vote for it.  Of course, I'd rather have inherited constructors first  
;)

-Steve
Apr 27 2009
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Steven Schveighoffer wrote:

 ...
 
 There are three benefits I see to the proposal:
 
 1. It saves typing.  This is not usually a big deal, except that this
 sort of constructor is EXTREMELY common with container objects.



Fair enough.


 2. It saves having to specify the type.  We get the same savings from
 "auto," it should be similar here.  In fact, you could probably change
 the keyword "member" to "auto".



True, but...


 3. It's a little more self documenting.  You know when you see the
 function signature, that what you pass in will at least start being the
 initial value of the named member.



class Act
{
    this(auto a, auto b) {}

    // a million billion lines of code

    private { int a; Wombat b; }

    // another million billion lines of code.  And a pony.
}

Working out the type of a or b will be a major pain in the arse.

It's less documenting in the sense that you'll see the ctor and have no
idea what you should be passing to it.


 The drawback of course is the keyword.  the magic behavior is not a
 drawback IMO (in fact, it is the point).



The magic-ness is a Bad Thing™.  You're obfuscating the interface.  This
isn't like auto in code since there you care about how you use the
thing, not the exact type.

But here, you have users who NEED to know what the type is.


 If you used auto as the keyword, you don't add a keyword.
 
 I'd vote for it.  Of course, I'd rather have inherited constructors
 first ;)
 
 -Steve



For me, the real nail-in-the-coffin is that you can do this with mixins.
 Yes, grauzone, they're not pretty.  But they work and they don't
require language changes.

Besides, it gives us fuel to bug Walter about implementing macros. :D

  -- Daniel
Apr 27 2009
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 27 Apr 2009 08:51:03 -0400, Daniel Keep  
<daniel.keep.lists gmail.com> wrote:


 Steven Schveighoffer wrote:

 ...

 There are three benefits I see to the proposal:

 1. It saves typing.  This is not usually a big deal, except that this
 sort of constructor is EXTREMELY common with container objects.



 Fair enough.


 2. It saves having to specify the type.  We get the same savings from
 "auto," it should be similar here.  In fact, you could probably change
 the keyword "member" to "auto".



 True, but...


 3. It's a little more self documenting.  You know when you see the
 function signature, that what you pass in will at least start being the
 initial value of the named member.



 class Act
 {
     this(auto a, auto b) {}

     // a million billion lines of code

     private { int a; Wombat b; }

     // another million billion lines of code.  And a pony.
 }

 Working out the type of a or b will be a major pain in the arse.



Just like:

void foo()
{
   int a, b;
   // a million billion lines of code
   auto c = a; // what type is a?
}


 If you used auto as the keyword, you don't add a keyword.

 I'd vote for it.  Of course, I'd rather have inherited constructors
 first ;)

 -Steve



 For me, the real nail-in-the-coffin is that you can do this with mixins.
  Yes, grauzone, they're not pretty.  But they work and they don't
 require language changes.



Yes, the mixin Nick provided is handy.  I guess you are right.

-Steve
Apr 27 2009
prev sibling parent reply "carlos smith" <carlos-smith sympatico.ca> writes:
"Penguin" <davidcollien gmail.com> > 

 class Foo {
   int a;
   float b;
   this( member a, member b ) {
   } 
 }



Why the keyword ?

Why not just:   this(a,b) {  } ?
Apr 26 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
carlos smith:

 Why the keyword ?
 Why not just:   this(a,b) {  } ?



Please, lets not mud the language too much for a small syntax gain.
(What may be added to D is a syntax to create getters/setters in a simple and
short way. We have discussed this in the past, C#4 shows a good starting point
for this).

Bye,
bearophile
Apr 26 2009
prev sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sun, Apr 26, 2009 at 9:02 AM, bearophile <bearophileHUGS lycos.com> wrot=
e:

 carlos smith:

 Why the keyword ?
 Why not just: =A0 this(a,b) { =A0} ?



 Please, lets not mud the language too much for a small syntax gain.



*snort*

Wait a second, who's the one saying this?
Apr 26 2009