Review: std.uuid

[Jacob Carlborg]

On 2012-06-14 09:49, Jonathan M Davis wrote:

> It is and it isn't. It makes it much easier to end up with conflicts. It would
> be less of a problem if not all symbols were imported by default. We _do_ have
> some great tools for dealing with conflicts, but the fact that everything gets
> imported by default when you import a module means that it's very easy to
> create conflicts, and when that's coupled with the fact that D is very quick to
> declare ambiguities and conflicts with overload sets and whatnot rather than
> trying to determine which one you really meant (like C++ would) makes it that
> much worse. There are definite pros to the situation (e.g. being so picky with
> overload sets makes it much harder to call the wrong function without knowing
> it), but there's no question that conflicts happen quite easily. It's not as
> big a deal with introducing a new module, since the programmer will deal with
> it when they import it for the first time, but it tends to break code when
> adding new stuff to old modules.
>
> So, in general, if we can pick good names which don't conflict, we're better
> off. But if the best names are ones that are used in other modules, then that's
> what we'll end up going with. It has to be judged on a case-by-case basis.

I was referring to that it's good that a conflict will not occur just by 
importing modules with conflicting names. You also have to _use_ them.

> aliases are useless for dealing with conflicts as long as private aliases
> aren't hidden. At present, I'd argue that private aliases are bad practice
> unless you alias things to very esoteric names which aren't likely to conflict.
> It would really be nice to have that fixed though.

Right, but that's a bug.

-- 
/Jacob Carlborg