new principle of division between structures and classes

[Denis Koroskin]

On Sun, 11 Jan 2009 05:04:11 +0300, Weed <resume755 at mail.ru> wrote:

> Bill Baxter пишет:
>> 2009/1/11 Weed <resume755 at 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.