• Bill Baxter <wbaxter gmail.com> Nov 12 2009
• Justin Johansson <no spam.com> Nov 12 2009
• Justin Johansson <no spam.com> Nov 12 2009
• xx <xx xx.com> Nov 12 2009
• Bill Baxter <wbaxter gmail.com> Nov 12 2009

Bill Baxter <wbaxter gmail.com> writes:

I fear there could be a long parade of these "How about Go's ____"
topics, but anyway, here goes...

In Go (from what I understand), a struct is stack allocated with
   x := Struct();
and heap allocated with
   x := &Struct();

For D that would be
   auto x = Struct(); // stack
   auto x = &Struct(); // heap
And for D classes one could use
   auto x = Class(); // on the heap
   auto x = *Class(); // on the stack
For arrays
   auto x = &float[14];  // heap
   auto x = &float[](10,20)  // heap
   auto x = float[14];  // alt form of fixed size stack array?
For AAs
   auto x = &float[int];  // heap
   auto x = float[int]; // stack

Mostly just a syntax bikeshed, but this seemed like a nice way to
eliminate the "new" syntax that wasn't mentioned previously.
They also kind of round out the declaration possibilities so that all
these built-ins can be declared as auto or as literals. For instance,
a function that needs a 10 element scratch array passed in could be
called like:
       foo(A,B, float[10][]);
equivalent to
       float[10] tmp;
       foo(A,B, tmp[]);

I haven't really understood Dimscha's request for a templatized
constructor, though.  Maybe this won't help there.

--bb

Justin Johansson <no spam.com> writes:

Bill Baxter Wrote:

 I fear there could be a long parade of these "How about Go's ____"
 topics, but anyway, here goes...
 ....
 Mostly just a syntax bikeshed, but this seemed like a nice way to
 eliminate the "new" syntax that wasn't mentioned previously.
 They also kind of round out the declaration possibilities so that all
 these built-ins can be declared as auto or as literals. For instance,
 a function that needs a 10 element scratch array passed in could be
 called like:
        foo(A,B, float[10][]);
 equivalent to
        float[10] tmp;
        foo(A,B, tmp[]);



'... but this seemed like a nice way to eliminate the "new" syntax that
wasn't mentioned previously.'

Somewhat related to this post ...

Currently in my D projects I use static opCall to eliminate "new" (at least for
classes) such as:

class Foo
{
  int x;
  Foo( int x) { this.x = x; }
  static Foo opCall( int x) { return new Foo( x); }
}

I'm not sure if this considered good D style of not (please advise), but it does
eliminate having to type new all the time to allocate and construct new Foo's.

However, for consistency, I find myself often typing in static opCall
boiler-plate code 
when creating a new class definition even for classes which few instances are
ever created in the wild.  In some cases, then, more overall keystrokes are
incurred just to save the infrequent new keyword when instantiating the class.

Analysing the break-even point (minimum number of new's to save) for the
static opCall keystroke overhead is (at least in this case) .. hmm .. let's see
...

"new" is 3 characters but at least one whitespace separator is needed so that
makes 4 characters "new ".

Now the following comparison text (edited in fixed-width font, 1st line is 50
chars; 2nd is 48):

static Foo opCall( int x) { return new Foo( x); }
new new new new new new new new new new new new

Whilst I like the idea of getting rid of new keyword, I must admit that on the
balance I generally don't save any keystrokes using the static opCall
instrument.

btw.  My thinking for getting rid of new keyword came from some experience
with Scala case classes and companion classes (Object in Scala parlance).
From what I understand/remember, "Object" is Scala's way of getting rid of
"static" in
relation to class member variables and methods.  In some ways, D opCall some
analogy
with these Scala idioms.

What do others think?

Justin Johansson

Justin Johansson <no spam.com> writes:

Justin Johansson Wrote:
 Currently in my D projects I use static opCall to eliminate "new" (at least for
 classes) such as:
 
 class Foo
 {
   int x;
   Foo( int x) { this.x = x; }
   static Foo opCall( int x) { return new Foo( x); }
 }
 
 I'm not sure if this considered good D style of not (please advise), but it
does
 eliminate having to type new all the time to allocate and construct new Foo's.
 
 However, for consistency, I find myself often typing in static opCall
boiler-plate code 
 when creating a new class definition even for classes which few instances are
 ever created in the wild.  In some cases, then, more overall keystrokes are
 incurred just to save the infrequent new keyword when instantiating the class.
 
 Analysing the break-even point (minimum number of new's to save) for the
 static opCall keystroke overhead is (at least in this case) .. hmm .. let's
see ...
 
 "new" is 3 characters but at least one whitespace separator is needed so that
 makes 4 characters "new ".
 
 Now the following comparison text (edited in fixed-width font, 1st line is 50
chars; 2nd is 48):
 
 static Foo opCall( int x) { return new Foo( x); }
 new new new new new new new new new new new new
 
 Whilst I like the idea of getting rid of new keyword, I must admit that on the
 balance I generally don't save any keystrokes using the static opCall
instrument.
 
 btw.  My thinking for getting rid of new keyword came from some experience
 with Scala case classes and companion classes (Object in Scala parlance).
 From what I understand/remember, "Object" is Scala's way of getting rid of
"static" in
 relation to class member variables and methods.  In some ways, D opCall some
analogy
 with these Scala idioms.
 
 What do others think?
 


I neglected to say also that my usage of static opCall for classes is mostly in
relation
to immutable "value classes".  If there's already a precomputed instance of the
same
class with the same constructor parameters my static opCall returns the
precomputed
instance and not a new instance.  *In this case*, it's not a matter of saving
keystrokes
but a reflection of my design so I guess that makes my usage of static opCall
more
of a necessity.

Justin

xx <xx xx.com> writes:

 In Go (from what I understand), a struct is stack allocated with
    x := Struct();
 and heap allocated with
    x := &Struct();


It's a nice trick, but I don't find it intuitive. Getting address of an object
(re)allocates it? Literal that has different address each time?

Bill Baxter <wbaxter gmail.com> writes:

On Thu, Nov 12, 2009 at 5:32 PM, xx <xx xx.com> wrote:
 In Go (from what I understand), a struct is stack allocated with
 =A0 =A0x :=3D Struct();
 and heap allocated with
 =A0 =A0x :=3D &Struct();


 It's a nice trick, but I don't find it intuitive. Getting address of an o=



I look at it more as taking the address of the type, which is
currently meaningless, then passing that some constructor args.

But good point... the syntax is ambiguous with taking the address of
the constructed value literal.
I guess that would force you to add a new precendence rule.  So to
actually take the address you'd need &(Struct()).

I like it less now.

--bb