new principle of division between structures and classes

[Weed]

Weed пишет:
> 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.
>>
> 
> (I have incorrectly expressed)
> 
> If dereferencing was not used in lvalue or rvalue and is both a classes
> by value it is possible to assignment, except cases when the base type
> to the derivative is assigned.
> 
> Example:
> 
> class C {}
> class C2 : C {}
> 
> C c();
> C2 c2();
> 
> C* c_p = &c;
> C2* c2_p = &c2;
> 
> c = c2; // ok
> c2 = c; // err
> *c_p = *c2_p; // err
> *c2_p = *c_p; // err
> c2 = *c2_p; // err
> 
> and:
> c = c2 + *c2_p; // ok
> 
>>>>>> 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.
> 
> So I offer: the inheritance of structures this one of offers, which in
> itself it seems insignificant, but useful if to make classes by value.
> 
>>> 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.
> 
> Oh!:) but I suspect such classes scheme somehow correspond with
> JIT-compilation.
> 
>>> 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.
> 
> Yes, I know.
> I hint at that that it seems this scheme have copied because it is
> popular but have not considered characteristic for C++-like compiled
> language nuances.


So? Revising of objects is necessary? We agree at least with it?