carnold said:
It doesn't say *exactly* that; I summarized. Dangerous thing to do
when asking a programming question, I know ... talking to (some)
computer programmers is second only to talking to computers with
regard to the level of detail necessary to keep from causing a core
dump (or the equivalent
If the variable is created as a member of another, it's created in the
context of the other ... obviously? Maybe not. I guess it's worth
mentioning ...
Unfortunately it's not obvious to some. When people use the shorthand
of "structs are created on the stack, classes are created on the heap"
some people get confused - understandably, I guess.
It's a well understood design principal that you shouldn't change the
meaning of familiar constructs. "new" has specific implications in
both C++ and Java that don't hold in C# ... I guarantee you I'm not
the first one to think changing those implications a bad idea. But I
guess when you balance it against the introduction of a separate
construct to differentiate "create an auto variable" vs. "create and
zero an auto variable" (a differentiation which seems to me to be of
very little use, but I'm probably overlooking an important use-case or
two), it's probably the lesser evil.
Well, it's not a case of doing something with an "auto variable" (not
that such a term exists in C#) - it's a case of calling a constructor.
How do you call a constructor? With "new TypeName(...)". That's true
whether you're using the result as a parameter, as a local variable, as
a member variable, or anything else.
While I take your point about not changing familiar constructs, there
are plenty of far more subtle changes. Overloading doesn't work exactly
the same way in C# as in Java or C++, for example - but I suspect
you'll find that's far less well-understood than the simple
"new ...(...) calls a constructor" change. It's a reasonably simple
change which makes things very consistent.
Another change from C++ and Java: you can't fall through from one
switch case to another (although you can have multiple labels for the
same case). Is that a bad idea too? It removes a common source of
errors.
Heck, the whole type system in C# is different from unmanaged C++, so
there's already a lot of adjustment required. In the grand scheme of
things, I think this is a very minor thing to get your head round,
compared with the bigger mindset changes. I'm very keen on trying to
use the idioms of the language I'm using, rather than writing code with
an accent from another language - if you try to write C# as if it's C++
or Java, you *will* end up with bugs and/or inelegant code.
I'm sure the decision wasn't taken lightly - and I'd rather have a
language which takes an extra few minutes to understand while learning,
but which is then consistent, than one which decides to live with an
inconsistent or inappropriate approach just because a previous language
took a particular path.
If you base the design of your language on another (as C# is based on C
++ and Java), differing from those languages is Bad (as you're going
against your "we should be the same" design principal). It may be the
lesser of two evils (different semantics vs. introducing Yet Another
C#-exclusive construct), but taking an attitude of "just because it's
different doesn't mean it's bad" is Only valid when "we should be the
same" isn't an Obvious and Key goal in the design.
The *overall* look and feel of C# is like Java, but I certainly don't
begrudge the designers for making changes. There's a difference betweem
"familiar style" and "exact copy". Should they have used "import"
instead of "using"? "extends/implements" instead of ":"? I really have
no problem switching between the two, and the time taken to learn
differences like this is very small indeed.
...