On Tue, Jan 6, 2009 at 1:41 PM, Christopher Wright <dhase...@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
