January 14, 2004
"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:bu357d$b60$1@digitaldaemon.com...
> Walter wrote:
> > "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:bt0gqk$ion$1@digitaldaemon.com...
> >
> >>Walter
> >>
> >>A while back I mentioned that it would be nice to allow auto instances
to
> >
> > be
> >
> >>constructed without the (syntactically consistent but semantically misleading) new syntax. In other words
> >>
> >>            auto ExeModule xmod =   new ExeModule(moduleName);
> >>
> >>could be written as the more accurate
> >>
> >>            ExeModule xmod(moduleName);
> >>
> >>If memory serves, you liked this, but it's not yet implemented. Are
there
> >>plans to do this? Is it as simple as it seems to be to implement?
> >
> >
> > As the other respondents pointed out, there are many parsing issues to
be
> > worked out to make this work. I think we'll leave it as is for the time being.
>
> What about this one?
>
> auto ExeModule xmod(moduleName);

That's good. Can we have that Walter?


January 14, 2004
Honestly I kind of like the current syntax.  I think one of the gotchas moving from C++ is forgetting to new everything , if we require the same syntax it will drive home that everything must be new'ed.

C


"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:bu35b2$bii$1@digitaldaemon.com...
>
> "Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:bu357d$b60$1@digitaldaemon.com...
> > Walter wrote:
> > > "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:bt0gqk$ion$1@digitaldaemon.com...
> > >
> > >>Walter
> > >>
> > >>A while back I mentioned that it would be nice to allow auto instances
> to
> > >
> > > be
> > >
> > >>constructed without the (syntactically consistent but semantically misleading) new syntax. In other words
> > >>
> > >>            auto ExeModule xmod =   new ExeModule(moduleName);
> > >>
> > >>could be written as the more accurate
> > >>
> > >>            ExeModule xmod(moduleName);
> > >>
> > >>If memory serves, you liked this, but it's not yet implemented. Are
> there
> > >>plans to do this? Is it as simple as it seems to be to implement?
> > >
> > >
> > > As the other respondents pointed out, there are many parsing issues to
> be
> > > worked out to make this work. I think we'll leave it as is for the
time
> > > being.
> >
> > What about this one?
> >
> > auto ExeModule xmod(moduleName);
>
> That's good. Can we have that Walter?
>
>


January 15, 2004
But auto instances do not exist on the heap and, for me at least, new says "create one of these on the heap".

I grant you, or anyone else, that new actually has two functions, and my focus on the heap side (as opposed to the construction side) is undoubtedly from my C++ thinking


"C" <dont@respond.com> wrote in message news:bu4fqf$2guo$1@digitaldaemon.com...
> Honestly I kind of like the current syntax.  I think one of the gotchas moving from C++ is forgetting to new everything , if we require the same syntax it will drive home that everything must be new'ed.
>
> C
>
>
> "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:bu35b2$bii$1@digitaldaemon.com...
> >
> > "Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:bu357d$b60$1@digitaldaemon.com...
> > > Walter wrote:
> > > > "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:bt0gqk$ion$1@digitaldaemon.com...
> > > >
> > > >>Walter
> > > >>
> > > >>A while back I mentioned that it would be nice to allow auto
instances
> > to
> > > >
> > > > be
> > > >
> > > >>constructed without the (syntactically consistent but semantically misleading) new syntax. In other words
> > > >>
> > > >>            auto ExeModule xmod =   new ExeModule(moduleName);
> > > >>
> > > >>could be written as the more accurate
> > > >>
> > > >>            ExeModule xmod(moduleName);
> > > >>
> > > >>If memory serves, you liked this, but it's not yet implemented. Are
> > there
> > > >>plans to do this? Is it as simple as it seems to be to implement?
> > > >
> > > >
> > > > As the other respondents pointed out, there are many parsing issues
to
> > be
> > > > worked out to make this work. I think we'll leave it as is for the
> time
> > > > being.
> > >
> > > What about this one?
> > >
> > > auto ExeModule xmod(moduleName);
> >
> > That's good. Can we have that Walter?
> >
> >
>
>


January 15, 2004
Matthew wrote:

>But auto instances do not exist on the heap and, for me at least, new says
>"create one of these on the heap".
>
>I grant you, or anyone else, that new actually has two functions, and my
>focus on the heap side (as opposed to the construction side) is undoubtedly
>from my C++ thinking
>
>  
>

What about:

ExeModule xmod = auto ExeModule(moduleName);

then?


>"C" <dont@respond.com> wrote in message
>news:bu4fqf$2guo$1@digitaldaemon.com...
>  
>
>>Honestly I kind of like the current syntax.  I think one of the gotchas
>>moving from C++ is forgetting to new everything , if we require the same
>>syntax it will drive home that everything must be new'ed.
>>
>>C
>>
>>    
>>

January 15, 2004
"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:bu51da$ah3$1@digitaldaemon.com...


> >"C" <dont@respond.com> wrote in message news:bu4fqf$2guo$1@digitaldaemon.com...
> >
> >
> >>Honestly I kind of like the current syntax.  I think one of the gotchas moving from C++ is forgetting to new everything , if we require the same syntax it will drive home that everything must be new'ed.
> >>
> >>C
> >>
> >>
> >>
>
> Matthew wrote:
>
> >But auto instances do not exist on the heap and, for me at least, new
says
> >"create one of these on the heap".
> >
> >I grant you, or anyone else, that new actually has two functions, and my focus on the heap side (as opposed to the construction side) is
undoubtedly
> >from my C++ thinking
> >
> >
> >
>
> What about:
>
> ExeModule xmod = auto ExeModule(moduleName);
>
> then?

That's almost as verbose as it already is

    auto ExeModule xmod = new ExeModule(moduleName);

I really think

    auto ExeModule xmod(moduleName);

is the best compromise. It's not ambiguous wrt local function declarations, and it's pretty clear what's going on.

Walter?





January 15, 2004
I admit that I haven't really thought about it, but the way D reuses the 'this' keyword gave me an idea...

ExeModule xmod = auto(moduleName);

how does that do?
I don't realy like it my self, but I think the statement *needs* to have an equals in it, so that non D-adepts can look at it and know it is declaring a variable.

If it were unambiguous, I suspect that the following would also be possible for non-auto instances...

SomeClass obj = new(parameters);

which has the same non-replication.

Like I said I don't actually like this form myself, but I felt I had to share.

Alix...


Matthew wrote:

>>What about:
>>
>>ExeModule xmod = auto ExeModule(moduleName);
>>
>>then?
>>    
>>
>
>That's almost as verbose as it already is
>
>    auto ExeModule xmod = new ExeModule(moduleName);
>
>I really think
>
>    auto ExeModule xmod(moduleName);
>
>is the best compromise. It's not ambiguous wrt local function declarations,
>and it's pretty clear what's going on.
>
>Walter?
>
>
>
>
>
>  
>


-- 
           Alix Pexton
Webmaster - http://www.theDjournal.com

           Alix@theDjournal.com

January 15, 2004
>>auto ExeModule xmod(moduleName);

I'd prefer

ExeModule xmod = auto(moduleName);

somehow.. i don't like the constructor parameters bound to the object.. looks like an opCall for me, dunno how nice to parse..

or

ExeModule(moduleName) xmod;

that would be best possibly. not even an auto needed.

why is that best? because constructor gets called the very same way, just not on
a new-ed object ( = new ExeModule(moduleName); ), but directly on the stack
(just as int x, the int will be on the stack)..

i think the last proposial of me is the most logical one. more logical than the c++ way at least.

its the same as

int[] x;

instead of

int x[];

and

Type(params) name; would be unambiguous to parse. and short. and understandable. doesn't even require the auto keyword then anymore. wich is a good thing imho..

oh, and.. if the constructor has no parameters, you still have to call it with
Type() name;

this could even be standard. instanciate an object of some type has to be done
with Type(...). if you want it on the gc-heap, you new it. else, you just use it
(and then, it will behave stackbased..)

Type(); unnamed object on the stack

new Type(); unnamed object on the heap

Type; unnamed reference

Type name; named reference

Type name = new Type(); named reference to an unnamed object on the heap

Type name = Type(); named reference to an unnamed object on the stack

Type() name; named object on the stack

new Type() name; named object on the heap :D

hehe, fun:D


January 16, 2004
I like this!!

This way the language makes it very clear that we are doing two different kinds of things. Even newbies would spot this easily.

"Simplicity, clarity, generality." Kernighan & Pike


In article <bu73om$o91$1@digitaldaemon.com>, davepermen says... ..
>i think the last proposial of me is the most logical one. more logical than the c++ way at least.
>
>its the same as
>
>int[] x;
..
>and
>
>Type(params) name; would be unambiguous to parse. and short. and understandable. Doesn't even require the auto keyword then anymore. wich is a good thing imho..
>
>oh, and.. if the constructor has no parameters, you still have to
>call it with Type() name;
>
>this could even be standard. instanciate an object of some type has
>to be done with Type(...). if you want it on the gc-heap, you new it.
>Else, you just use it (and then, it will behave stackbased..)
>
>Type(); unnamed object on the stack
>new Type(); unnamed object on the heap
>Type; unnamed reference
>Type name; named reference
>Type name = new Type(); named reference to an unnamed object on the heap
>Type name = Type(); named reference to an unnamed object on the stack
>Type() name; named object on the stack
>new Type() name; named object on the heap :D


January 16, 2004
auto, as written in the D doc, is independent of where the object is
allocated. In fact I can't find anything in the dmd source that indicates it
is on the stack. I think it would be tricky to allocate on the stack
currently because the compiler would have to know from a statement like
 auto Class x = new Subclass();
to ignore the size of Class and use the size of Subclass. Also what about
 auto Class x = something_that_returns_an_object();

I agree the C/C++ programmer would see auto and think "stack" but that is a different problem.

-Ben

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:bu4uou$6bv$1@digitaldaemon.com...
> But auto instances do not exist on the heap and, for me at least, new says "create one of these on the heap".
>
> I grant you, or anyone else, that new actually has two functions, and my focus on the heap side (as opposed to the construction side) is
undoubtedly
> from my C++ thinking
>
>
> "C" <dont@respond.com> wrote in message news:bu4fqf$2guo$1@digitaldaemon.com...
> > Honestly I kind of like the current syntax.  I think one of the gotchas moving from C++ is forgetting to new everything , if we require the same syntax it will drive home that everything must be new'ed.
> >
> > C
> >
> >
> > "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:bu35b2$bii$1@digitaldaemon.com...
> > >
> > > "Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:bu357d$b60$1@digitaldaemon.com...
> > > > Walter wrote:
> > > > > "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:bt0gqk$ion$1@digitaldaemon.com...
> > > > >
> > > > >>Walter
> > > > >>
> > > > >>A while back I mentioned that it would be nice to allow auto
> instances
> > > to
> > > > >
> > > > > be
> > > > >
> > > > >>constructed without the (syntactically consistent but semantically misleading) new syntax. In other words
> > > > >>
> > > > >>            auto ExeModule xmod =   new ExeModule(moduleName);
> > > > >>
> > > > >>could be written as the more accurate
> > > > >>
> > > > >>            ExeModule xmod(moduleName);
> > > > >>
> > > > >>If memory serves, you liked this, but it's not yet implemented.
Are
> > > there
> > > > >>plans to do this? Is it as simple as it seems to be to implement?
> > > > >
> > > > >
> > > > > As the other respondents pointed out, there are many parsing
issues
> to
> > > be
> > > > > worked out to make this work. I think we'll leave it as is for the
> > time
> > > > > being.
> > > >
> > > > What about this one?
> > > >
> > > > auto ExeModule xmod(moduleName);
> > >
> > > That's good. Can we have that Walter?
> > >
> > >
> >
> >
>
>


January 19, 2004
In article <bu73om$o91$1@digitaldaemon.com>, davepermen wrote:
>>>auto ExeModule xmod(moduleName);
> 
> I'd prefer
> 
> ExeModule xmod = auto(moduleName);
> 
> somehow.. i don't like the constructor parameters bound to the object.. looks like an opCall for me, dunno how nice to parse..
> 
> or
> 
> ExeModule(moduleName) xmod;

For some reason, this one actually seems an incredibly good. It just seems as if it's the one syntax everybody's been hunting down all the time.

It might have small but solvable parsing issues (the part before "xmod" first looks like a function call) and it just might not be the perfect one, but I like the terseness and consistency with "new ExeModule(moduleName)"

Yet I think that the following should mean the same:

ExeModule() xmod; // instantiate ExeModule with no args ExeModule xmod;   // instantiate ExeModule with no args

You know, "do as the ints do". And if there's no need to sprinkle superfluous parentheses around, I'd rather not.

-Antti