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

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

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