On 2010-05-21 22:55:16 -0400, Walter Bright <newshou...@digitalmars.com> 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?

I've been thinking about having both by-value and by-reference containers. The first-class name would be given to the by-reference container to give it more visibility, but that by-reference container would be a simple wrapper for a by-value container "part" implemented in a struct:

        struct ArrayPart(T) { ... } // by value array container.

        class Array(T) {
                ArrayPart!T part;
                alias part this;
        }

So now, if you want to reuse a container "part" to build some kind of more complex data structure, you can do it like this:

        class Channel {
                private {
                        ArrayPart!Message inbound;
                        ArrayPart!Message outbound;
                }

                ...
        }

No silly extra indirection.

That said, all this gives me a feeling of an overcomplicated design. After all, the problem is that you want to pass the container by reference in function arguments, but it's __too easy to forget the ref__. Perhaps that's the problem that should be fixed.

Couldn't we just make a struct that cannot be implicitly copied? Perhaps something like this:

        @explicitdup struct Array {  }

        void testVal(Array array);
        void testRef(ref Array array);

        unittest {
                Array array;
                testVal(array);     // error, cannot copy array implicitly
                testVal(array.dup); // ok, array is copied
                testRef(array);     // ok, array is passed by reference
        }

If there's already a way to achieve this, I couldn't find it.

--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Reply via email to