division of objects into classes and structures is bad

[Bill Baxter]

On Tue, Jan 6, 2009 at 1:41 PM, Christopher Wright <dhasenan at gmail.com> wrote:
> Weed wrote:
>>
>> Who agrees with me? There are still ideas as it is possible to solve
>> this problem and not to destroy language?
>
> When you reply to your reply to your reply to your post and nobody else
> replies to any of your posts, you might start thinking that nobody agrees
> with you, or cares enough to respond.
>
> As to your suggestion that there be compile-time checks for object
> slicing... well, you'd end up with almost everything with any polymorphism
> being done by reference for safety. In the remaining situations, scope will
> usually suffice.
>
> I don't think anyone sees sufficient reason to give Walter as much work as
> you suggest. When would you use this?
>  - In place of the current scope keyword.
>  - For more efficiency with object composition (though scope could be used
> for this, potentially).
>  - Implementing value semantics with runtime polymorphism.
>
> The only interesting thing there is value semantics with polymorphism. If
> you really care, you can implement polymorphism with structs.
>

My problem is more that I just can't understand the guy so I don't
know if I agree with him or not.

I think the choice between  just

   value semantics / POD / no polymorphism / heap or stack    and
   reference semantics / non-POD / polymorphism / heap only

Are not quite sufficent.  I find myself often wanting things that are
mixes of these two attribute sets, and it's often difficult for me to
decide up front which is more appropriate for a given case.  For
instance reference-semantics POD.     And other times it's out of my
hands writing a library -- the more appropriate one depends on the
person using the library not me.  So I've played around with things
like implementing the guts of something entirely as a mixin that gets
mixed in to both a struct and a class shell.  It sorta works but it's
a lot more work than the unified model in C++ where I just write one
class and the user decides how to use it.  And scope has a lot of
holes.   You can't create a scope member of a class.   I don't think
you can create an array of scope objects, either.

So I'm not really convinced that D got the distinction right.  It's
never really felt right to me and it still doesn't today.  But I don't
have any better suggestions at the moment.  It just feels very
un-orthogonal to me.  Different unrelated choices are all bundled
under the same big toggle switch rather than being able to toggle the
different attributes the way I want them.

--bb