www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Three improvements for constructor syntax

reply arcanejill ramonsky.com writes:
Hi guys,
My first suggestions for this forum - three improvements for constructor syntax.



1. The reserved word "new" is superfluous. It should be made optional.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In C++, the following two statements are both legal, but do different things:

(i)     T * a = new T(parameters);  // C++
(ii)    T b = T(parameters);        // C++

In case (i), the object is constructed on the heap (as in D), and the variable a
is assigned a pointer to it. In case (ii), the object is constructed on the
stack, and the variable b is assigned a reference to it. This distinction is
apparent in the way that member variables are later accessed:

(i)     x = a->memberVariable;      // C++
(ii)    y = b.memberVariable;       // C++

Now, NEITHER of these distinctions are relevant in D. Class objects are ALWAYS
allocated on the heap, never on the stack, so there is no need for the "new"
keyword to be present to distinguish the two cases. Further, D does not
distinguish between the . operator and the -> operator, It would therefore be
both syntactically elegant, and reasonable, to allow the following syntax:

T a = T(parameters);        // my suggestion: should be exactly equivalent to T
a = new T(parameters);
x = a.memberVariable;       // member variable access

I suggest, therefore, that the keyword "new" is superfluous, and should be made
optional - required ONLY if some ambiguity I haven't thought of requires
disambiguation.




2. Construction declaration statements
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In C++, the following statement:

T a(parameters);

is equivalent to:

T a = T(parameters);

I suggest that this syntax should also be allowable in D. It is aesthetically
much more pleasing, as there is no needless duplication of the class name. To
give a real world example, you only have to compare:

(i)     MultiPrecisionDecimal z = new MultiPrecisionDecimal(5.2);       // as
now
(ii)    MultiPrecisionDecimal z(5.2);                                   // what
I'm suggesting

Observe how much neater and cleaner version (ii) is. Further, there is (so far
as I can tell) no possibility of ambiguity here. Syntactic elegance favors
allowing the simpler syntax.




3. Assignment by value
~~~~~~~~~~~~~~~~~~~~~~

Finally, I propose a new operator, := (that's a colon followed by an equals). It
should be used like this:

a := b;

Whenever it occurs, it should be rewritten by the compiler as:

a = new T(b);   // where T is the type of A

It could be declared in the obvious way, like this (and multiply overloaded for
different types of b):

class T
{
this(U b)
{
// do stuff
}
}

To make life easier, it should be a syntax error to use the assignment-by-value
operator on an auto class. Of course, it is ALREADY possible to assign structs
(but not classes) by value. In the case of a struct, I propose that the two
statements following shall have identical behavior:

a = b;      // as now
a := b;     // rewritten as a = b;

Thus, the existing syntax for both structs and classes is preserved, with its
current behaviour, but new, simpler syntaxes also exist to make code smaller,
neater, and cleaner.



Well, just my suggestions. Please feel free to consider, accept, or reject.
Jill
May 19 2004
next sibling parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
Currently

        T a = T(arguments);

would call a static opCall defined in the class T.



arcanejill ramonsky.com wrote:


 
 Hi guys,
 My first suggestions for this forum - three improvements for constructor
 syntax.
 
 
 
 1. The reserved word "new" is superfluous. It should be made optional.
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 In C++, the following two statements are both legal, but do different
 things:
 
 (i)     T * a = new T(parameters);  // C++
 (ii)    T b = T(parameters);        // C++
 
 In case (i), the object is constructed on the heap (as in D), and the
 variable a is assigned a pointer to it. In case (ii), the object is
 constructed on the stack, and the variable b is assigned a reference to
 it. This distinction is apparent in the way that member variables are
 later accessed:
 
 (i)     x = a->memberVariable;      // C++
 (ii)    y = b.memberVariable;       // C++
 
 Now, NEITHER of these distinctions are relevant in D. Class objects are
 ALWAYS allocated on the heap, never on the stack, so there is no need for
 the "new" keyword to be present to distinguish the two cases. Further, D
 does not distinguish between the . operator and the -> operator, It would
 therefore be both syntactically elegant, and reasonable, to allow the
 following syntax:
 
 T a = T(parameters);        // my suggestion: should be exactly equivalent
 to T a = new T(parameters);
 x = a.memberVariable;       // member variable access
 
 I suggest, therefore, that the keyword "new" is superfluous, and should be
 made optional - required ONLY if some ambiguity I haven't thought of
 requires disambiguation.
 
 
 
 
 2. Construction declaration statements
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 In C++, the following statement:
 
 T a(parameters);
 
 is equivalent to:
 
 T a = T(parameters);
 
 I suggest that this syntax should also be allowable in D. It is
 aesthetically much more pleasing, as there is no needless duplication of
 the class name. To give a real world example, you only have to compare:
 
 (i)     MultiPrecisionDecimal z = new MultiPrecisionDecimal(5.2);       //
 as now
 (ii)    MultiPrecisionDecimal z(5.2);                                   //
 what I'm suggesting
 
 Observe how much neater and cleaner version (ii) is. Further, there is (so
 far as I can tell) no possibility of ambiguity here. Syntactic elegance
 favors allowing the simpler syntax.
 
 
 
 
 3. Assignment by value
 ~~~~~~~~~~~~~~~~~~~~~~
 
 Finally, I propose a new operator, := (that's a colon followed by an
 equals). It should be used like this:
 
 a := b;
 
 Whenever it occurs, it should be rewritten by the compiler as:
 
 a = new T(b);   // where T is the type of A
 
 It could be declared in the obvious way, like this (and multiply
 overloaded for different types of b):
 
 class T
 {
 this(U b)
 {
 // do stuff
 }
 }
 
 To make life easier, it should be a syntax error to use the
 assignment-by-value operator on an auto class. Of course, it is ALREADY
 possible to assign structs (but not classes) by value. In the case of a
 struct, I propose that the two statements following shall have identical
 behavior:
 
 a = b;      // as now
 a := b;     // rewritten as a = b;
 
 Thus, the existing syntax for both structs and classes is preserved, with
 its current behaviour, but new, simpler syntaxes also exist to make code
 smaller, neater, and cleaner.
 
 
 
 Well, just my suggestions. Please feel free to consider, accept, or
 reject. Jill
May 19 2004
parent reply arcanejill ramonsky.com writes:
In article <c8f2rl$11af$1 digitaldaemon.com>, Norbert Nemec says...

Currently

        T a = T(arguments);

would call a static opCall defined in the class T.



Yes, it would. That's something I hadn't thought of. Well, here are my thoughts
on that, for what they're worth....

It occurs to me that the whole POINT of overloading operator () using opCall()
is to create an object which behaves like a function - kinda like a modern day
version of the old-fashioned callback routine you used to get in C. There's even
a word for them - "functors" - and they are very useful.

However, a STATIC functor? Surely a static functor is just a FUNCTION?

To put it another way, instead of declaring:

       class A
       {
           int opCall(int x, int y)
           {
                // function body
           }
       }

you could just as easily do this:

       int A(int x, int y)
       {
           // function body
       }

which would achieve exactly the same effect. The static functor version does
have the ability to access static members of A, which the function version
can't, but frankly there are other ways of achieving this effect.

Moreover, the static functor version violates the D style guide in that you now
have a function (or at least, a function-like-object) whose name starts with an
upper case letter.

If there is a real need for a CLASS (as opposed to an instance of a class) to be
callable, then I can't think of any circumstance where simply providing a named
member function won't do. That is, instead of calling:

       A(parameters);

we would have to call:

       A.namedFunction(parameters);

So - I can see NO NEED for static functors, and I humbly suggest that the
syntax:

       A a = A(parameters)

SHOULD call a constructor, and should NOT call static opCall(). In fact, I would
argue further that static opCall should be a compile error, as it is a
completely pointless thing to do, and yields code which looks ... unintuitive.

Now, I'm arguing in favor of removing  a feature, so I don't expect everyone to
agree with me. But this forum is for discussion, so let's discuss. I'd be really
interested to know what others think about this.
May 19 2004
parent reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
<arcanejill ramonsky.com> wrote in message
news:c8fk7j$1s6d$1 digitaldaemon.com...

 In article <c8f2rl$11af$1 digitaldaemon.com>, Norbert Nemec says...

Currently

        T a = T(arguments);

would call a static opCall defined in the class T.



 Yes, it would. That's something I hadn't thought of. Well, here are my


thoughts

 on that, for what they're worth....

 It occurs to me that the whole POINT of overloading operator () using


opCall()

 is to create an object which behaves like a function - kinda like a modern


day

 version of the old-fashioned callback routine you used to get in C.


There's even

 a word for them - "functors" - and they are very useful.

 However, a STATIC functor? Surely a static functor is just a FUNCTION?

 To put it another way, instead of declaring:

        class A
        {
            int opCall(int x, int y)
            {
                 // function body
            }
        }

 you could just as easily do this:

        int A(int x, int y)
        {
            // function body
        }

 which would achieve exactly the same effect. The static functor version


does

 have the ability to access static members of A, which the function version
 can't, but frankly there are other ways of achieving this effect.

 Moreover, the static functor version violates the D style guide in that


you now

 have a function (or at least, a function-like-object) whose name starts


with an

 upper case letter.

 If there is a real need for a CLASS (as opposed to an instance of a class)


to be

 callable, then I can't think of any circumstance where simply providing a


named

 member function won't do. That is, instead of calling:

        A(parameters);

 we would have to call:

        A.namedFunction(parameters);

 So - I can see NO NEED for static functors, and I humbly suggest that the
 syntax:

        A a = A(parameters)

 SHOULD call a constructor, and should NOT call static opCall(). In fact, I


would

 argue further that static opCall should be a compile error, as it is a
 completely pointless thing to do, and yields code which looks ...


unintuitive.

 Now, I'm arguing in favor of removing  a feature, so I don't expect


everyone to

 agree with me. But this forum is for discussion, so let's discuss. I'd be


really

 interested to know what others think about this.



But static opCall enables you to do exactly what you want!

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

and you can create class objects the in a c++ syntax
A a = A(5);
May 19 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
But static opCall enables you to do exactly what you want!

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

and you can create class objects the in a c++ syntax
A a = A(5);


I had thought of that, but in fact that isn't what I'm suggesting. I don't
merely want to be able to create classes which callers can call without "new". I
want to be able to construct ANY class without using "new". For example:

OutBuffer a = OutBuffer();

or, better still,

Outbuffer a();

To implement "don't need new" in some classes but not in others would be silly.
It would lead to less clarity, not more.

Please understand - this is purely an AESTHETIC consideration. There is no
deficiency in the language which needs a workaround. But ... the guys who wrote
D are very proud of the fact that D has a simple syntax - see the stuff about
complex numbers, for example. If they can implement a simple syntax for
something which is so common a task as constructing a class, then, why wouldn't
they? Unless it's a hard problem - but I suspect it isn't.

Arcane Jill
May 19 2004
next sibling parent reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:c8g72s$2pko$1 digitaldaemon.com...

But static opCall enables you to do exactly what you want!

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

and you can create class objects the in a c++ syntax
A a = A(5);


 I had thought of that, but in fact that isn't what I'm suggesting. I don't
 merely want to be able to create classes which callers can call without


"new". I

 want to be able to construct ANY class without using "new". For example:

 OutBuffer a = OutBuffer();

 or, better still,

 Outbuffer a();

 To implement "don't need new" in some classes but not in others would be


silly.

 It would lead to less clarity, not more.

 Please understand - this is purely an AESTHETIC consideration. There is no
 deficiency in the language which needs a workaround. But ... the guys who


wrote

 D are very proud of the fact that D has a simple syntax - see the stuff


about

 complex numbers, for example. If they can implement a simple syntax for
 something which is so common a task as constructing a class, then, why


wouldn't

 they? Unless it's a hard problem - but I suspect it isn't.


I think the way it is now is much clearer and it is very clear from the code
that
a "new" object is being instantiated. And in my opinion this synatx is very
simple
and those three letters "new" aren't that hard to type.



 Arcane Jill
May 19 2004
parent reply Ant <Ant_member pathlink.com> writes:
In article <c8g87d$2rht$1 digitaldaemon.com>, Ivan Senji says...

and those three letters "new" aren't that hard to type.


(I've said this before, I promisse it's the last time.)

It isn't the how hard is to type that matters
it's how easy is to read.

Ant
May 19 2004
next sibling parent reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Ant" <Ant_member pathlink.com> wrote in message
news:c8g9om$2toq$1 digitaldaemon.com...

 In article <c8g87d$2rht$1 digitaldaemon.com>, Ivan Senji says...

and those three letters "new" aren't that hard to type.


 (I've said this before, I promisse it's the last time.)

 It isn't the how hard is to type that matters
 it's how easy is to read.


What i wanted to write was:
A a = new A();
is much easier to read than
A a();

The first one just shouts "instantiating object here"
and the second one doesn't



 Ant
May 19 2004
next sibling parent Arcane Jill <Arcane_member pathlink.com> writes:
What i wanted to write was:
A a = new A();
is much easier to read than
A a();

The first one just shouts "instantiating object here"
and the second one doesn't


Fair point. I concede that. But what about the distinction between:
(a)     A a = new A(parameters);
(b)     A a = A(parameters);

..?

Regarding shouting: I've thought a bit about this, and after much contemplation,
I've come to the conclusion that such shouting (in this case) is pretty
meaningless.

Consider: Suppose we see this in source code:
May 20 2004
prev sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
WAAAAH! My posts got truncated. I'll try again. This is a resend...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


What i wanted to write was:
A a = new A();
is much easier to read than
A a();

The first one just shouts "instantiating object here"
and the second one doesn't


Fair point. I concede that. But what about the distinction between:
(a)     A a = new A(parameters);
(b)     A a = A(parameters);

..?

Regarding shouting: I've thought a bit about this, and after much contemplation,
I've come to the conclusion that such shouting (in this case) is pretty
meaningless.

Consider: Suppose we see this in source code:Regarding shouting: I've thought a
bit about this, and after much contemplation, I've come to the conclusion that
such shouting is pretty meaningless.

Consider: Suppose we see this in source code:

       b = a.f();
       c = a.g();


Now, what we can SEE at a glance from this is that f and g (both member
functions of typeof(a)) are both called, but we CAN'T see what goes on inside
those functions - not at THIS point in the source code, anyway. Without hunting
down the declarations, we can't know whether f() is a short one-liner and g() is
a thousand lines long, or whether it is the other way round, or neither. Now,
similarly, consider the following two statements:

       b = new A();
       c = f();


You are certainly correct in that the first of these shouts CONSTRUCTION IS
HAPPENING at you, but the truth is, that's not particularly important. After
all, A.this() might be only one line long, or might even be empty. The function
call in the second line might be so complicated that it takes half an hour to
execute. You just can't tell from looking at the code. A constructor, after all,
is just another function.

In fact, the only _real_ thing that "new" tells you is that, at some point,
MEMORY ALLOCATION IS HAPPENING. (A function call only tells you that memory
allocation MIGHT be happening). But is this really a piece of information you
want shouted at you? I would say not, since the mechanism of reserving a slice
of the heap and returning a pointer to it is really not that slow. Actually, in
D, it's very fast. It's the execution of the body of the constructor which takes
the time, and that will be true of _any_ function, not just a constructor.
(Reserving a slice of the stack is unlikely to be much faster if stack-checking
is enabled).

In other words, I don't think that the presence of the keyword "new" in the
statement:

       a = new A(parameters);


tells you ANYTHING useful at all. Yes, it does shout at you - but shouting is
only useful if it tells you something important, and that's really the point I'm
trying to make. It's not something important, and doesn't need to be shouted.
It's just another function call, so the word just adds unneccessary clutter to
the source code.

Observe that D _encourages_ the use of memory allocation. Its garbage collector
hides the delete process from your source code. (And it's worth pointing out
that, in C++, deletion is much slower than allocation. I don't know if this is
the case in D or not because I don't know how the garbage collector works).

In D, _all_ objects are constructed on the heap. *ALL* of them. Every single
one. I stress this, because it's not true in C++. In C++, the word "new" does
mean something - it tells you that the object is being constructed on the heap
rather than on the stack (and that's ALL it tells you). In D, this is not a
useful thing to know, because it's ALWAYS true. In fact, the only way to stop it
happening is to use a struct rather than a class. (And, interestingly, in C++
the words struct and class are interchangable). In other words, in C++, the word
"new" is important, but in D, the word "class" is important in an analogous way.

My apologies for this tediously long explanation, but I wanted to try to be
clear and avoid misunderstandings. In its present use, the word "new" serves
only to distinguish between a call to this() and a call to static opCall(). I
would prefer that static opCall() be a compile error (because, as I argued in a
previous post, a static functor is just a function - and we already have a
syntax for functions). This would leave the way open for removing the need for
"new" in a call to this().

Arcane Jill
May 20 2004
next sibling parent "Bent Rasmussen" <exo bent-rasmussen.info> writes:
Or use the same instantiation syntax for both templates and classtemplates
and classes, if that's possible; if it is then it seems that new is used to
make class instantiations familiar to outsiders. The template instantiation
syntax is quite neat.
May 20 2004
prev sibling next sibling parent vanh <vanh_member pathlink.com> writes:
After reading this thread for a while I'd to chime in.
I agree with Arcane Jill point. My motivation is this I'd like D to be a simple
language as possible. Easy to read, easy to write, easy to understand, easy to
maintain, and ofcourse, easy on the compiler. And every unnecessary rule should
be depricated away. Rule such as: new, brace as block of code, class, and
function, semicolon as end of statement. I'll could think of more.

vanh
May 21 2004
prev sibling parent reply vanh <vanh_member pathlink.com> writes:
After reading this thread for a while I'd to chime in.
I agree with Arcane Jill point. My motivation is this I'd like D to be a simple
language as possible. Easy to read, easy to write, easy to understand, easy to
maintain, and ofcourse, easy on the compiler. And every unnecessary rule should
be depricated away. Rule such as: new, brace as block of code, class, and
function, semicolon as end of statement. I'll could think of more.

vanh
May 21 2004
parent vanh <vanh_member pathlink.com> writes:
Oop! me bad. I double click on the postmessage. Sorry for that.
Vanh




After reading this thread for a while I'd to chime in.
I agree with Arcane Jill point. My motivation is this I'd like D to be a simple
language as possible. Easy to read, easy to write, easy to understand, easy to
maintain, and ofcourse, easy on the compiler. And every unnecessary rule should
be depricated away. Rule such as: new, brace as block of code, class, and
function, semicolon as end of statement. I'll could think of more.

vanh
May 21 2004
prev sibling parent reply Juan C <Juan_member pathlink.com> writes:
It isn't the how hard is to type that matters
it's how easy is to read.


Indeed, a major flaw of C is that it makes things _too_ easy to write (i.e.
using a minimum of keystrokes), but when written that way it's dang hard to
read.

I never understood the "fewer keystrokes is better" mentality.
May 19 2004
parent reply "Pablo Aguilar" <paguilarg hotmail.com> writes:
It isn't the how hard is to type that matters
it's how easy is to read.


 Indeed, a major flaw of C is that it makes things _too_ easy to write


(i.e.

 using a minimum of keystrokes), but when written that way it's dang hard


to

 read.

 I never understood the "fewer keystrokes is better" mentality.


Remember C is from the days of teletype terminals and few kb RAM and disk
units...
Fewer was definitely better back then!
May 19 2004
parent Juan C <Juan_member pathlink.com> writes:
Remember C is from the days of teletype terminals and few kb RAM and disk
units...
Fewer was definitely better back then!


Then explain COBOL... No, don't.
May 19 2004
prev sibling parent Ant <Ant_member pathlink.com> writes:
In article <c8g72s$2pko$1 digitaldaemon.com>, Arcane Jill says...

want to be able to construct ANY class without using "new". For example:

OutBuffer a = OutBuffer();

or, better still,

Outbuffer a();


but, isn't that an abstract function declaration
that returns an object of type Outbuffer?

Ant
May 19 2004
prev sibling next sibling parent "Harvey" <hstroud ntlworld.com> writes:
Hear, hear!  (see 'clumsy class instantiation quibble' thread).


<arcanejill ramonsky.com> wrote in message
news:c8f0sa$tqk$1 digitaldaemon.com...

 Hi guys,
 My first suggestions for this forum - three improvements for constructor


syntax.

 1. The reserved word "new" is superfluous. It should be made optional.
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 In C++, the following two statements are both legal, but do different


things:

 (i)     T * a = new T(parameters);  // C++
 (ii)    T b = T(parameters);        // C++

 In case (i), the object is constructed on the heap (as in D), and the


variable a

 is assigned a pointer to it. In case (ii), the object is constructed on


the

 stack, and the variable b is assigned a reference to it. This distinction


is

 apparent in the way that member variables are later accessed:

 (i)     x = a->memberVariable;      // C++
 (ii)    y = b.memberVariable;       // C++

 Now, NEITHER of these distinctions are relevant in D. Class objects are


ALWAYS

 allocated on the heap, never on the stack, so there is no need for the


"new"

 keyword to be present to distinguish the two cases. Further, D does not
 distinguish between the . operator and the -> operator, It would therefore


be

 both syntactically elegant, and reasonable, to allow the following syntax:

 T a = T(parameters);        // my suggestion: should be exactly equivalent


to T

 a = new T(parameters);
 x = a.memberVariable;       // member variable access

 I suggest, therefore, that the keyword "new" is superfluous, and should be


made

 optional - required ONLY if some ambiguity I haven't thought of requires
 disambiguation.




 2. Construction declaration statements
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 In C++, the following statement:

 T a(parameters);

 is equivalent to:

 T a = T(parameters);

 I suggest that this syntax should also be allowable in D. It is


aesthetically

 much more pleasing, as there is no needless duplication of the class name.


To

 give a real world example, you only have to compare:

 (i)     MultiPrecisionDecimal z = new MultiPrecisionDecimal(5.2);       //


as

 now
 (ii)    MultiPrecisionDecimal z(5.2);                                   //


what

 I'm suggesting

 Observe how much neater and cleaner version (ii) is. Further, there is (so


far

 as I can tell) no possibility of ambiguity here. Syntactic elegance favors
 allowing the simpler syntax.




 3. Assignment by value
 ~~~~~~~~~~~~~~~~~~~~~~

 Finally, I propose a new operator, := (that's a colon followed by an


equals). It

 should be used like this:

 a := b;

 Whenever it occurs, it should be rewritten by the compiler as:

 a = new T(b);   // where T is the type of A

 It could be declared in the obvious way, like this (and multiply


overloaded for

 different types of b):

 class T
 {
 this(U b)
 {
 // do stuff
 }
 }

 To make life easier, it should be a syntax error to use the


assignment-by-value

 operator on an auto class. Of course, it is ALREADY possible to assign


structs

 (but not classes) by value. In the case of a struct, I propose that the


two

 statements following shall have identical behavior:

 a = b;      // as now
 a := b;     // rewritten as a = b;

 Thus, the existing syntax for both structs and classes is preserved, with


its

 current behaviour, but new, simpler syntaxes also exist to make code


smaller,

 neater, and cleaner.



 Well, just my suggestions. Please feel free to consider, accept, or


reject.

 Jill
May 19 2004
prev sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
arcanejill ramonsky.com wrote:


Hi guys,
My first suggestions for this forum - three improvements for constructor syntax.



1. The reserved word "new" is superfluous. It should be made optional.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In C++, the following two statements are both legal, but do different things:

(i)     T * a = new T(parameters);  // C++
(ii)    T b = T(parameters);        // C++
  


I don't support this syntax form but I would like something like:

new b = T(parameters);

That way there is no repetition which means improved maintance.  The 
form could be changed, its the repetition reduction that is important. 
VB does something like that.

-- 
-Anderson: http://badmama.com.au/~anderson/
May 19 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <c8hhns$223p$1 digitaldaemon.com>, J Anderson says...

...but I would like something like:

new b = T(parameters);

That way there is no repetition which means improved maintance.  The 
form could be changed, its the repetition reduction that is important. 
VB does something like that.



Interesting syntax. But it LOOKS like an assignment, not a declaration, so it
probably wouldn't work.

Opinion on this thread has not endorsed the second of my suggestions, so I'd be
quite happy to drop it. After all - it's not like I have a PROBLEM - it's just
aesthetics after all. So if:
May 20 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
Arcane Jill wrote:


In article <c8hhns$223p$1 digitaldaemon.com>, J Anderson says...
  


...but I would like something like:

new b = T(parameters);

That way there is no repetition which means improved maintance.  The 
form could be changed, its the repetition reduction that is important. 
VB does something like that.
    



Interesting syntax. But it LOOKS like an assignment, not a declaration, so it
probably wouldn't work.

Opinion on this thread has not endorsed the second of my suggestions, so I'd be
quite happy to drop it. After all - it's not like I have a PROBLEM - it's just
aesthetics after all. So if:
  


Well I did say the syntax need work.  This was discussed before but I 
forget the syntax suggestion.  Parhaps something like:

A b = new();

-- 
-Anderson: http://badmama.com.au/~anderson/
May 20 2004