Michel Fortin wrote:
On 2010-05-21 22:55:16 -0400, Walter Bright <[email protected]>
said:
Walter Bright wrote:
If we can get anywhere close to that level of success with ranges and
containers, we should all be well pleased.
Mike Taylor has a phrase for that I think is well-coined: "impedance
matching",
defined as the work necessary to get one library module to work with
another
library module.
This makes me think about something.
In principle, I like the idea of containers being reference type. It
works well when passing a container to functions. But at the same time,
I despite it. By-reference containers forces you to have extra
indirections even when you don't need them, and you have to worry about
null. Sometime a value-type would be better, when creating more complex
data structures for instance:
class Channel {
private {
Array!Message inbound;
Array!Message outbound;
}
...
}
What's the point of having extra indirection here?
Good question. I think the answer is:
1. When do you ever want to copy a collection? I almost never do, because
copying one is an inherently expensive operation.
2. When you copy a collection, do you copy the container or the elements in the
container or both? One would have to carefully read the documentation to see
which it is. That increases substantially the "cognitive load" of using them.
3. Going to lengths to make them value types, but then disabling copying them
because you want people to use them as reference types, seems like a failure of
design somewhere.
4. That silly extra level of indirection actually isn't there. Consider that
even value locals are accessed via indirection: offset[ESP]. For a reference
collection we have: offset[EBX]. No difference (yes, EBX has to be loaded, but
if it is done more than once it gets cached in a register by the compiler).
5. Just making them all reference types means the documentation and use become a
lot simpler.
