division of objects into classes and structures is bad

[Weed]

Don пишет:

>>>> It is possible to think up other example where there is no overload:
>>>>
>>>> space_ship_1.calculatePathTo("Moon").getCheckpoint(3).getCoords;
>>>>
>>>> In this example we create a temporary class "path", create temporary
>>>> class "checkpoint" and we take coords of checkpoint of this path. It is
>>>> not expedient to us to store all this path and checkpoint because it is
>>>> vary.
>>> I fail to see how D's distinction between classes and structs has any
>>> bearing on this. The optimisations you're talking about are only
>>> possible in the presence of polymorphism, in cases where you can prove
>>> that polymorphism is not being used! I suspect that if you're
>>> encountering this issue in speed-critical code, there's a problem with
>>> your design.
>>>
>>
>> Quite right, if polymorphism I would not be necessary to me did not use
>> classes, it is obvious. All the rest that you have told it the common
>> words so experts in marketing speak. :)
>>
>> I give concrete examples from a life where D is bad. You see a design
>> problem in the code resulted above?
> 
> If the overhead caused by using classes is unacceptable, then yes. I'd
> want to see the definition of "checkpoint". If it's really polymorphic,
> how can it be stored on the stack? This doesn't make sense to me.

Where a problem?

> 
>> By the way, one of serious problem: if necessary it is difficult enough
>> to alter a class in structure and vice versa. Insufficiently simply to
>> change the keyword. And it is serious, it is not necessary to me to tell
>> about planning.
>>