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?
T.
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?
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 H.
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).
T.
On 11/15/05, Trans [email protected] wrote:
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.
Regards,
Sean
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).
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 H.
Okay, I found this: RCR 289: Method to import a source file wrapped in a named module.
I’ve been working on related code so I know how to implement this
readily and will do so and make available soon.
T.
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?
T.