>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.

> >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!

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/

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:

>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:

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

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.

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/

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