On Sun, 11 Jan 2009 05:04:11 +0300, Weed <resume...@mail.ru> wrote:
Bill Baxter пишет:
2009/1/11 Weed <resume...@mail.ru>:
Bill Baxter пишет:
But since classes can be polymorphic, value copying gets you into
slicing problems. That's why value copying is disabled to begin with.
So disabling value copies is a good thing.
It is not always a good thing.
Yeh, I just mean there is some merit in disabling value copies. But I
don't rule out the possibility that there may be an even better way
that banning them altogether.
I propose to prohibit only the copying by value of the base type to
derivative type
Ok, this is key. How do you propose to do this? In general it
requires a runtime check, I think.
And I think you need to say that you prohibit copying unless
typeA==typeB exactly. If you allow copying either way between base
and derived you are asking for trouble.
But still given
Base x = get_one();
Base y = get_another();
*x = *y; // presumed value copy syntax
you have no way in general to know that x and y are really both a Base
at compile time. So you must have a run-time check there. Perhaps it
could be omitted for -release builds, though.
It can lead to a difficult and non-reproduceable errors than old
C++-style splitting.
It is possible to try to prohibit assignment of the dereferenced
pointers? Simply to prohibit assignment too it is possible, essentially
it changes nothing.
Err.. I don't get what you say. The *x = *y is just one of the possible
syntaxes, nothing else.
And that's also the problem with putting scope'd things inside another
class or an array. Since they don't have value semantics,
Yes, this is what I mean
So assuming you had this, the important question is what would you do
with it?
The most difficult. My arguments:
1. Problem of a choice of correct type for the object. A mathematical
matrix - a classical example. A class it should be or structure?
My offer without serious consequences allows to move solution of this
problem from a design stage to a programming stage - is it will be
simple by replacement keyword class to struct.
Having the same syntax for both classes and struct is a nice goal, I agree.
But it should be taken as a different issue and solved separately, too.
2. Performance increases. It is not necessary to allocate at the
slightest pretext memory in a heap.
3. I offer syntax which presumably does not break an existing code.
+ On how many I understand, in the existing compiler all necessary for
implementation already is, a problem only in syntax addition.
4. Java and C# also uses objects by reference? But both these of
language are interpreted. I assume that the interpreter generally with
identical speed allocates memory in a heap and in a stack, therefore
authors of these languages and used reference model.
Neither of these languages are interpreted, they both are compiled into native
code at runtime.
D is compiled language and to borrow reference model incorrectly. In D
the programmer should have possibility most to decide where to place
object.
You still have the problem that the current system works pretty well.
And has a lot of history. So you need a very compelling use case to
convince Walter that something should change.
Thus, actually Java and C# systems works pretty well. And they has a lot
of history. But not D.
DMD 0.001 was released 7 years ago. Long enough, I think.
This situation reminds me history with the Hungarian notation:
Many years ago many developers have started to deliver interfaces and to
sell books where it was used. This very correct invention affirmed as
many books that and only in ~5 years there were articles with the
materials specifying in groundlessness of usage of this notation. Till
this time many entered it into corporate standards and suffered, though,
I am sure, they were visited by thoughts about irrelevance of the
given notation except for special cases.
