When is using the toplevel constant namespace justified? (Other then
for creating your own namespace obviously) Should it essentially NEVER
be used? Or is there some cases where it is reasonable? For instance
some classes seem so basic they feel like they belong there, like a
Tuple class. But perhaps the space should be reserved for Ruby built-in
stuff only, PERIOD?
On the otherhand perhaps it should be FREELY usable and a way should be
provided to mitigate if neccessary, for example:
module SafePlace
import 'somebodies/toplovel/stuff'
end
Or is this approach problematic? I should point out we don't have a
selective #include either, so for example:
module MySpace
class X ; end
class Y ; end
end
How could one pull X up to toplevel if they wanted w/o bringing Y?
Perhaps:
X = MySpace::X
but there is a caution here b/c poorly written classes would have
problems with this. Okay, I'm starting to get off on a tagent, but the
original question remains: how should we handle the toplevel space a
cooperative community?
It is good practice to keep all of your junk inside your own namespace,
especially if you are making anything for others to use. Otherwise, no
matter how lucky you think you are, eventually there is going to be a
namespace collision with someone else's code.
The only times that I can see an exception is when one is working within the
context of a core class, or when one is writing something that is not
intended for public consumption.
It a problem that I have wrestld with in my head, as I have a few classes
internal to IOWA that could be general purpose libs. I don't want to offer
them for inclusion in Facets because *I* don't want to have to have a
dependency on such a large collection when I'm only using a few bits of it,
but that's another subject.... Anyway, what I have decided on is modifying
the classes so that they, by default, stay in the the Iowa namespace when
required, but so that one can tell the class to pollute the toplevel
namespace and make itself available through there, too, if desired.
So, people who want to use Iowa::Webcache, but don't want the Iowa:: part
hanging out there can have it as just Webcache, even though that is much more
likely to collide with someone else.
So yeah, in general, keep the toplevel as unencumbered as possible.
Kirk Haines
···
On Tuesday 15 November 2005 1:07 pm, Trans wrote:
When is using the toplevel constant namespace justified? (Other then
for creating your own namespace obviously) Should it essentially NEVER
be used? Or is there some cases where it is reasonable? For instance
some classes seem so basic they feel like they belong there, like a
Tuple class. But perhaps the space should be reserved for Ruby built-in
stuff only, PERIOD?
When is using the toplevel constant namespace justified?
I think the general rule should be as Kirk says, "keep all of your
junk inside your own namespace".
How could one pull X up to toplevel if they wanted w/o bringing Y?
Perhaps:
X = MySpace::X
but there is a caution here b/c poorly written classes would have
problems with this.
I guess one of the reasons people pollute the toplevel namespace
is because they don't know how to write well-behaved classes
that can be pulled up in this manner when required. Perhaps
documenting how to do that correctly would be a start.
Some good points. And while I am inclinded to agree Kirk's comment:
"I don't want to offer them for inclusion in Facets
because *I* don't want to have to have a
dependency on such a large collection when I'm
only using a few bits of it"
raises an interesting conundrum. If I were to address this by splitting
out most of the class/modules of Facets into indivdual projects, then
many of those very same toplevel namespaces would get used up anyway.
B/c of issues like this I get the feeling that there might be a better
way than the present convention (which appears to be basically an
adaptation from Perl).
Split them up into separate mini projects. Have them all live under Facets::
Then, if you want, provide a simple mechanism to promote them to being
accessible from the top level, so that the user can decide whether to use
them in the nice, safe Facets namespace, or whether they see enough benefit
to having the class at the top level.
Might be an interesting discussion to talk about this aspect. For example,
let's say my Webcache were in Facets as Facets::Webcache.
If someone wants to use it at the top level, they can do:
Webcache = Facets::Webcache
Does there need to be anything more sophisticated than that? I haven't
conclusively convinced myself, but right now I am thinking that not doing
anything special and thus keeping it transparent and simple.
Kirk Haines
···
On Tuesday 15 November 2005 2:57 pm, Trans wrote:
raises an interesting conundrum. If I were to address this by splitting
out most of the class/modules of Facets into indivdual projects, then
many of those very same toplevel namespaces would get used up anyway.
B/c of issues like this I get the feeling that there might be a better
way than the present convention (which appears to be basically an
adaptation from Perl).
Might be an interesting discussion to talk about this aspect.
For example, let's say my Webcache were in Facets as
Facets::Webcache.
If someone wants to use it at the top level, they can do:
Webcache = Facets::Webcache
Sure. But waht if you decided to release Webcache as an independent
project...not out of the question, certainly. Then it would end up in
the toplevel namespace anyway. Others have done. Instead of
participating in a larger collection they've just released their single
class/module as a project in and of itself.
I think we may be dealing with name clash issues b/c we are
uneccessarily depending on absolutes defined by other users, and thus
outside the realm of our control when putting them to use. Of course
some will say it's too rare to worry about. But as Ruby grows the less
that argument holds up --there's already been some notable occurances.
So what about the alternate possibility of "requiring into" an
arbitrary namespace?