On 2008-09-01 22:13:15 David MacIver wrote:
> >> In general, when creating classes to work around deficiencies in
> >> standard library implementations they should probably go in some
> >> central place for such classes and share the name of the class they
> >> replace.
> >
> > Disagree. FastArrayBuffer and ArrayBuffer may do the same thing, but
> > they are not interchangeable because, well, they aren't the same
> > class. Giving them the same name would just be confusing.
> > (java.{util,sql}.Date really pisses me off.)
>
> Conveniently, things don't live in a global namespace. Particularly in
> Scala where you have hierarchical packages and imports and renaming of
> imports. The painfullness of doing such things in Java shouldn't
> prevent us from doing hem in Scala.
So you're suggesting that I should name two things the same, just so
that I can rename them to be different again...?
I /want/ a global namespace. I want to be able to look at a name and
know what it means without have to cross-reference against the imports.
I want a class to be named the same everywhere it's imported.
Packages and renaming give us ways to work around naming problems when
they occur, but that doesn't mean it's a good idea to introduce them
deliberately.
> I don't find it's a significant disadvantage in readability. When I
> need to distinguish between them I use one or both partially qualified
> (e.g. Map, immutable.Map and mutable.Map).
As a writer, you sometimes need to distinguish between them. As a
reader, you /always/ need to. So since the qualification is always
necessary, why not bake it into the name and avoid any doubt?
/J
