www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Suggestion: shortcut for 'new X'

reply Kristian <kjkilpi gmail.com> writes:
How about this:

     Obj obj1 =3D new Obj;
     Obj obj2 =3D new Obj(10);

could be reduced to:

     Obj obj1 =3D new;
     Obj obj2 =3D new(10);

This way only one class name would be required per variable. (That is, o=
ne  =

at maximum: "Obj obj1 =3D new, obj2 =3D new(10);" is also valid of cours=
e.)  =

Redundance would be reduced.

I know, it looked quite 'odd' for me too at first, but now it looks very=
  =

natural, and even clearer than the longer way.


I'm not sure if using of this syntax should be possible outside the  =

variable declarations. Later in a code "obj1 =3D new;" is less informati=
ve  =

than "obj1 =3D new Obj;". However, someone may like it too... it's up to=
 a  =

programmer how to code (which is not always a good thing(tm) though).
Aug 24 2006
next sibling parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Kristian wrote:
 How about this:
 
     Obj obj1 = new Obj;
     Obj obj2 = new Obj(10);
 
 could be reduced to:
 
     Obj obj1 = new;
     Obj obj2 = new(10);
 
 This way only one class name would be required per variable. (That is, 
 one at maximum: "Obj obj1 = new, obj2 = new(10);" is also valid of 
 course.) Redundance would be reduced.

You can already do: auto obj1 = new Obj; auto obj2 = new Obj(10); which takes care of the redundant Obj.
Aug 24 2006
parent reply Kristian <kjkilpi gmail.com> writes:
On Thu, 24 Aug 2006 18:10:12 +0300, Oskar Linde  =

<oskar.lindeREM OVEgmail.com> wrote:

 Kristian wrote:
 How about this:
      Obj obj1 =3D new Obj;
     Obj obj2 =3D new Obj(10);
  could be reduced to:
      Obj obj1 =3D new;
     Obj obj2 =3D new(10);
  This way only one class name would be required per variable. (That i=


 one at maximum: "Obj obj1 =3D new, obj2 =3D new(10);" is also valid o=


 course.) Redundance would be reduced.

You can already do: auto obj1 =3D new Obj; auto obj2 =3D new Obj(10); which takes care of the redundant Obj.

Yes, and it's nice. But you cannot always use auto. Obj func() { Obj ret =3D new; ret.doSomething(); ... return(ret); } That would be nice too. :)
Aug 24 2006
next sibling parent reply BCS <BCS pathlink.com> writes:
Kristian wrote:
 On Thu, 24 Aug 2006 18:10:12 +0300, Oskar Linde  
 <oskar.lindeREM OVEgmail.com> wrote:
 
 Kristian wrote:

 How about this:
      Obj obj1 = new Obj;
     Obj obj2 = new Obj(10);
  could be reduced to:
      Obj obj1 = new;
     Obj obj2 = new(10);
  This way only one class name would be required per variable. (That 
 is,  one at maximum: "Obj obj1 = new, obj2 = new(10);" is also valid 
 of  course.) Redundance would be reduced.

You can already do: auto obj1 = new Obj; auto obj2 = new Obj(10); which takes care of the redundant Obj.

Yes, and it's nice. But you cannot always use auto. Obj func() { Obj ret = new; ret.doSomething(); ... return(ret); } That would be nice too. :)

IIRC this works: Obj func() { auto ret = new Obj; ret.doSomething(); ... return(ret); }
Aug 24 2006
parent reply Kristian <kjkilpi gmail.com> writes:
On Thu, 24 Aug 2006 19:08:22 +0300, BCS <BCS pathlink.com> wrote:

 Kristian wrote:
 On Thu, 24 Aug 2006 18:10:12 +0300, Oskar Linde   =


 <oskar.lindeREM OVEgmail.com> wrote:

 Kristian wrote:

 How about this:
      Obj obj1 =3D new Obj;
     Obj obj2 =3D new Obj(10);
  could be reduced to:
      Obj obj1 =3D new;
     Obj obj2 =3D new(10);
  This way only one class name would be required per variable. (That=




 is,  one at maximum: "Obj obj1 =3D new, obj2 =3D new(10);" is also =




 of  course.) Redundance would be reduced.

You can already do: auto obj1 =3D new Obj; auto obj2 =3D new Obj(10); which takes care of the redundant Obj.

But you cannot always use auto. Obj func() { Obj ret =3D new; ret.doSomething(); ... return(ret); } That would be nice too. :)

IIRC this works: Obj func() { auto ret =3D new Obj; ret.doSomething(); ... return(ret); }

It seems that you're right. Thanks for pointing it out. :) However, I don't think that it's not good programming style to use auto = a = lot. :/ Consider the following: Obj func2() {...} void func() { auto obj =3D func2(); } When looking at 'func()' only it's impossible to know the type of 'obj'.= Of course I could write "auto Obj obj" or "Obj obj", but it's inconsiste= nt = with 'anonymous autos': void func() { auto Obj obj1 =3D func(); auto obj2 =3D new Obj; } I would really prefer the following: void func() { Obj obj1 =3D func(); Obj obj2 =3D new; Obj obj3; } Or: void func() { auto Obj obj1 =3D func(); auto Obj obj2 =3D new; auto Obj obj3; } (Note the usage of the shortcut of 'new'.)
Aug 24 2006
parent reply BCS <BCS pathlink.com> writes:
Kristian wrote:
 
 However, I don't think that it's good programming style to use auto 
 a  lot. :/
 

substitute excessive for a lot and I agree.
 Consider the following:
 
 Obj func2() {...}
 
 void func() {
     auto obj = func2();
 }
 
 When looking at 'func()' only it's impossible to know the type of 'obj'.

that can be a bit of a gotcha. I haven't done it but putting in a static assert(is(obj : Obj)); could serve as a bit of type documentation and as a guard against API changes.
Aug 24 2006
parent reply Kristian <kjkilpi gmail.com> writes:
On Thu, 24 Aug 2006 21:17:23 +0300, BCS <BCS pathlink.com> wrote:

 Kristian wrote:
  However, I don't think that it's good programming style to use auto =


 lot. :/

substitute excessive for a lot and I agree.
 Consider the following:
  Obj func2() {...}
  void func() {
     auto obj =3D func2();
 }
  When looking at 'func()' only it's impossible to know the type of  =


 'obj'.

that can be a bit of a gotcha. I haven't done it but putting in a static assert(is(obj : Obj)); could serve as a bit of type documentation and as a guard against API =

 changes.

That's too hackish to my taste, and who have energy to write such long = statements for simple variable declarations? ;) Better have a simple, clear way to declare a variable, haven't it? "Obj obj =3D new;" is short, non-redundant, and it tells everybody that = = 'obj' is of type 'Obj'.
Aug 24 2006
parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Kristian wrote:
 On Thu, 24 Aug 2006 21:17:23 +0300, BCS <BCS pathlink.com> wrote:
 
 Kristian wrote:
  However, I don't think that it's good programming style to use auto 
 a  lot. :/

substitute excessive for a lot and I agree.
 Consider the following:
  Obj func2() {...}
  void func() {
     auto obj = func2();
 }
  When looking at 'func()' only it's impossible to know the type of 
 'obj'.

that can be a bit of a gotcha. I haven't done it but putting in a static assert(is(obj : Obj)); could serve as a bit of type documentation and as a guard against API changes.

That's too hackish to my taste, and who have energy to write such long statements for simple variable declarations? ;) Better have a simple, clear way to declare a variable, haven't it? "Obj obj = new;" is short, non-redundant, and it tells everybody that 'obj' is of type 'Obj'.

Well true, but auto obj = new Obj(); is not much longer, also isn't redundant and it also tells everyone what type 'obj' is.
Aug 24 2006
parent reply Kristian <kjkilpi gmail.com> writes:
On Thu, 24 Aug 2006 23:30:25 +0300, Ivan Senji  =

<ivan.senji_REMOVE_ _THIS__gmail.com> wrote:

 Kristian wrote:
 On Thu, 24 Aug 2006 21:17:23 +0300, BCS <BCS pathlink.com> wrote:

 Kristian wrote:
  However, I don't think that it's good programming style to use aut=




 a  lot. :/

substitute excessive for a lot and I agree.
 Consider the following:
  Obj func2() {...}
  void func() {
     auto obj =3D func2();
 }
  When looking at 'func()' only it's impossible to know the type of =




 'obj'.

that can be a bit of a gotcha. I haven't done it but putting in a static assert(is(obj : Obj)); could serve as a bit of type documentation and as a guard against AP=



 changes.



 statements for simple variable declarations? ;)
  Better have a simple, clear way to declare a variable, haven't it?
  "Obj obj =3D new;" is short, non-redundant, and it tells everybody t=


 'obj' is of type 'Obj'.

Well true, but auto obj =3D new Obj(); is not much longer, also isn't redundant and it also tells everyone wh=

 type 'obj' is.

That's right, but it raises a matter of (in)consistence in some cases as= I = wrote in my earlier post:
 However, I don't think that it's not good programming style to use aut=

 a lot. :/

 Consider the following:

 Obj func2() {...}

 void func() {
      auto obj =3D func2();
 }

 When looking at 'func()' only it's impossible to know the type of 'obj=

 Of course I could write "auto Obj obj" or "Obj obj", but it's  =

 inconsistent with 'anonymous autos':

 void func() {
      auto Obj obj1 =3D func();
      auto obj2 =3D new Obj;
 }

 I would really prefer the following:

 void func() {
      Obj obj1 =3D func();
      Obj obj2 =3D new;
      Obj obj3;
 }

 Or:

 void func() {
      auto Obj obj1 =3D func();
      auto Obj obj2 =3D new;
      auto Obj obj3;
 }

 (Note the usage of the shortcut of 'new'.)

Aug 24 2006
parent reply =?ISO-8859-15?Q?=22R=E9my_J=2E_A=2E_Mou=EBza=22?= writes:
 Kristian wrote:
 Consider the following:

 Obj func2() {...}

 void func() {
      auto obj = func2();
 }


For such cases, there is the typeof() operator : Obj func2 () { ... } void func () { typeof ( func2 ) obj = func2 (); } And one knows exactly that obj's type is the same as func2 return type, and there is no mistake possible with an auto type, althought it becomes redundant. It does not matter that much in a dynamically typed language : def func2 (): return Something () def func (): obj = func2 () It seems that there will always be some redundancy in a typed language à la C, nonetheless D has made great improvement.
Aug 25 2006
next sibling parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Rémy J. A. Mouëza wrote:
 
 Kristian wrote:
 Consider the following:

 Obj func2() {...}

 void func() {
      auto obj = func2();
 }


For such cases, there is the typeof() operator : Obj func2 () { ... } void func () { typeof ( func2 ) obj = func2 (); }

Why that when this works: void func() { auto obj = func2(); } What I think Kristian was saying is that you cannot see the type from the above, but you can know the type if it is: Obj obj1 = func2(); Obj obj1 = new; While it does make sense, I don't think that "auto obj = func2();" is a big problem and prefer auto.
Aug 25 2006
prev sibling parent reply Kristian <kjkilpi gmail.com> writes:
On Fri, 25 Aug 2006 11:38:18 +0300, Rémy J. A. Mouëza  
<ray.jay.ay.moueza do.not.spam.gmail.com> wrote:

 Kristian wrote:
 Consider the following:

 Obj func2() {...}

 void func() {
      auto obj = func2();
 }


For such cases, there is the typeof() operator : Obj func2 () { ... } void func () { typeof ( func2 ) obj = func2 (); } And one knows exactly that obj's type is the same as func2 return type, and there is no mistake possible with an auto type, althought it becomes redundant. It does not matter that much in a dynamically typed language : def func2 (): return Something () def func (): obj = func2 () It seems that there will always be some redundancy in a typed language à la C, nonetheless D has made great improvement.

Well yes, but you missed my point though. void func() { auto obj1 = func2(); typeof(func2) obj2 = func2(); } You (or someone reading the code, lets say, a year later) know that the type of both 'obj1' and 'obj2' are the same as the type of 'func2()'. But you don't know the type of 'func2()' without looking at the definion of 'func2()' or at the docs. Someone may argue that declaring 'Obj' in "auto obj1 = func2();" is redundant because 'func2()' returns 'Obj'. But that information is not apparent to you when you look at 'func()'. So it's not redundant code inside 'func()'. If you like to use 'obj1', then you have to know its type, of course. It's good programming style to declare the type for 'obj1' or you may end up with code that nobody knows the types of objects without looking at the documention/function declarations all the time. It would be very painful to modify the code later, even if you do it by yourself.
Aug 25 2006
parent =?ISO-8859-15?Q?=22R=E9my_J=2E_A=2E_Mou=EBza=22?= writes:
Kristian a écrit :
 On Fri, 25 Aug 2006 11:38:18 +0300, Rémy J. A. Mouëza 
 <ray.jay.ay.moueza do.not.spam.gmail.com> wrote:
 
 Kristian wrote:
 Consider the following:

 Obj func2() {...}

 void func() {
      auto obj = func2();
 }


For such cases, there is the typeof() operator : Obj func2 () { ... } void func () { typeof ( func2 ) obj = func2 (); } And one knows exactly that obj's type is the same as func2 return type, and there is no mistake possible with an auto type, althought it becomes redundant. It does not matter that much in a dynamically typed language : def func2 (): return Something () def func (): obj = func2 () It seems that there will always be some redundancy in a typed language à la C, nonetheless D has made great improvement.

Well yes, but you missed my point though. void func() { auto obj1 = func2(); typeof(func2) obj2 = func2(); } You (or someone reading the code, lets say, a year later) know that the type of both 'obj1' and 'obj2' are the same as the type of 'func2()'. But you don't know the type of 'func2()' without looking at the definion of 'func2()' or at the docs. Someone may argue that declaring 'Obj' in "auto obj1 = func2();" is redundant because 'func2()' returns 'Obj'. But that information is not apparent to you when you look at 'func()'. So it's not redundant code inside 'func()'. If you like to use 'obj1', then you have to know its type, of course. It's good programming style to declare the type for 'obj1' or you may end up with code that nobody knows the types of objects without looking at the documention/function declarations all the time. It would be very painful to modify the code later, even if you do it by yourself.

Thus it has nothing to do with syntax : it's more about documenting one's code. I completely missed your point, indeed. My apologizes. I sometimes code that way : void aMethod ( Something aThing ) { Something a = this.processIt ( this.thing ); auto b = processIt ( aThing ); ... } The first line of the method is a kind of reminder to tell the reader about the types and the methods used. In the remaining lines, I use the possible shortcuts. It's a matter of discipline ( or good programming style ). We, programmers, too often speak about code : source code looks more like some kind of software text/litterature than cryptic and secret code that only few people can understand.
Aug 25 2006
prev sibling parent reply freeagle <freeagle inmail.sk> writes:
Kristian wrote:
 On Thu, 24 Aug 2006 18:10:12 +0300, Oskar Linde 
 <oskar.lindeREM OVEgmail.com> wrote:
 
 Kristian wrote:
 How about this:
      Obj obj1 = new Obj;
     Obj obj2 = new Obj(10);
  could be reduced to:
      Obj obj1 = new;
     Obj obj2 = new(10);
  This way only one class name would be required per variable. (That 
 is, one at maximum: "Obj obj1 = new, obj2 = new(10);" is also valid 
 of course.) Redundance would be reduced.

You can already do: auto obj1 = new Obj; auto obj2 = new Obj(10); which takes care of the redundant Obj.

Yes, and it's nice. But you cannot always use auto. Obj func() { Obj ret = new; ret.doSomething(); ... return(ret); } That would be nice too. :)

And if you want to create object of inherited class and store it into referenco to base class?? class A { } class B : A { } A a = new/* B */; ??
Aug 24 2006
parent Kristian <kjkilpi gmail.com> writes:
On Thu, 24 Aug 2006 19:06:29 +0300, freeagle <freeagle inmail.sk> wrote:=


 Kristian wrote:
 On Thu, 24 Aug 2006 18:10:12 +0300, Oskar Linde  =


 <oskar.lindeREM OVEgmail.com> wrote:

 Kristian wrote:
 How about this:
      Obj obj1 =3D new Obj;
     Obj obj2 =3D new Obj(10);
  could be reduced to:
      Obj obj1 =3D new;
     Obj obj2 =3D new(10);
  This way only one class name would be required per variable. (That=




 is, one at maximum: "Obj obj1 =3D new, obj2 =3D new(10);" is also v=




 of course.) Redundance would be reduced.

You can already do: auto obj1 =3D new Obj; auto obj2 =3D new Obj(10); which takes care of the redundant Obj.

But you cannot always use auto. Obj func() { Obj ret =3D new; ret.doSomething(); ... return(ret); } That would be nice too. :)

And if you want to create object of inherited class and store it into =

 referenco to base class??

 class A
 {
 }

 class B : A
 {
 }

 A a =3D new/* B */; ??

If you write "A a =3D new;" it would equal to "A a =3D new A;" If you would like to create an object of type B, then you have to use th= e = longer (normal) version: A a =3D new B; There is no redundancy in "A a =3D new;" and "A a =3D new B;". However, = there = is redundancy in "A a =3D new A;".
Aug 24 2006
prev sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Kristian wrote:
 How about this:
 
     Obj obj1 = new Obj;
     Obj obj2 = new Obj(10);
 
 could be reduced to:
 
     Obj obj1 = new;
     Obj obj2 = new(10);
 
 This way only one class name would be required per variable. (That is, 
 one  at maximum: "Obj obj1 = new, obj2 = new(10);" is also valid of 
 course.)  Redundance would be reduced.
 
 I know, it looked quite 'odd' for me too at first, but now it looks 
 very  natural, and even clearer than the longer way.
 
 
 I'm not sure if using of this syntax should be possible outside the  
 variable declarations. Later in a code "obj1 = new;" is less 
 informative  than "obj1 = new Obj;". However, someone may like it too... 
 it's up to a  programmer how to code (which is not always a good 
 thing(tm) though).

Would this pose any ambiguities with custom class allocators? -- Chris Nicholson-Sauls
Aug 24 2006
parent reply Sean Kelly <sean f4.ca> writes:
Chris Nicholson-Sauls wrote:
 Kristian wrote:
 How about this:

     Obj obj1 = new Obj;
     Obj obj2 = new Obj(10);

 could be reduced to:

     Obj obj1 = new;
     Obj obj2 = new(10);

 This way only one class name would be required per variable. (That is, 
 one  at maximum: "Obj obj1 = new, obj2 = new(10);" is also valid of 
 course.)  Redundance would be reduced.

 I know, it looked quite 'odd' for me too at first, but now it looks 
 very  natural, and even clearer than the longer way.


 I'm not sure if using of this syntax should be possible outside the  
 variable declarations. Later in a code "obj1 = new;" is less 
 informative  than "obj1 = new Obj;". However, someone may like it 
 too... it's up to a  programmer how to code (which is not always a 
 good thing(tm) though).

Would this pose any ambiguities with custom class allocators?

I was wondering the same thing, but I think it could be resolved via look-ahead. That said, I'm not sure I like the syntax as it seems a bit confusing. Is it really so hard to specify the type name? Sean
Aug 24 2006
parent Kristian <kjkilpi gmail.com> writes:
On Fri, 25 Aug 2006 00:01:46 +0300, Sean Kelly <sean f4.ca> wrote:
 Chris Nicholson-Sauls wrote:
 Kristian wrote:
 How about this:

     Obj obj1 =3D new Obj;
     Obj obj2 =3D new Obj(10);

 could be reduced to:

     Obj obj1 =3D new;
     Obj obj2 =3D new(10);

 This way only one class name would be required per variable. (That i=



 one  at maximum: "Obj obj1 =3D new, obj2 =3D new(10);" is also valid=



 course.)  Redundance would be reduced.

 I know, it looked quite 'odd' for me too at first, but now it looks =



 very  natural, and even clearer than the longer way.


 I'm not sure if using of this syntax should be possible outside the =



 variable declarations. Later in a code "obj1 =3D new;" is less  =



 informative  than "obj1 =3D new Obj;". However, someone may like it =



 too... it's up to a  programmer how to code (which is not always a  =



 good thing(tm) though).


I was wondering the same thing, but I think it could be resolved via =

 look-ahead.  That said, I'm not sure I like the syntax as it seems a b=

 confusing.  Is it really so hard to specify the type name?

Never underestimate the power of the dark laziness! But seriously... One= = could also ask why 'this' is used in constructors/destructors instead of= = the class name. I was very pleased to find out that D does that. In Qt, for instance, you normally use pointers to objects. So, every tim= e = I wrote "X ... X" (e.g. "QCanvasPolygonalItem *item =3D new = QCanvasPolygonalItem;") I was thinking that there must be a better way t= o = do that. I started to use a new, bigger monitor a while ago. There was a negative= = side to it, however, paying money. And I thought I don't need it, not = really, the old one has served me fine in the past... Well, now I wouldn= 't = switch back to the old one.
Aug 25 2006