From: David Alan Black <dblack@...>
Date: 2001-12-05T10:31:17+09:00
Subject: [ruby-talk:27504] Re: Package Naming

Hello --

On Wed, 5 Dec 2001, Bryan Murphy wrote:

> >I'm not sure what we should do, but I'm sure that RAA.succ should
> >enforce it :-)
> >
> >I can't think of a great alternative to module hierarchies, though
> >such hierarchies tend to have an element of arbitrariness to them.
> >Not through slopiness -- just because things don't always fall neatly
> >into categories or name paths.
> >
> >It may be, though, that this would not matter too much if there were
> >ways to index and search things that were orthogonal to the actual
> >names.  For example, if I'm looking for text processing modules, that
> >could include XML-related modules.  I could then just live with it if
> >what I found happened to be called XML::Something::Whatever instead of
> >Text::Something::Whatever.
> >
> I always wondered why something has to be part of a particular
> namespace.   I wrote a web application (currently in the slow process of
> updating it) that lets you take your bookmarks and categorize them
> (without having to make multiple copies of each bookmark).  You can take
> a look at my links here:  http://links.terralab.com/view/bryan/
>
> Now, I don't see why Modules and Namespaces have to behave exactly the
> way they do.  Why not something like this?
>
> module MyXMLConfigModule
>   module_alias Text::XML::MyXMLConfigModule
>   module_alias XML::Text::MyXMLConfigModule
>   module_alias Configuration::Tools::MyXMLConfigModule
> end
>
> require 'Text/XML/MyXMLConfigModule'
> works the same as
> require 'XML/Text/MyXMLConfigModule'

I dunno.  It seems to me that if one is using a path syntax, then one
ought to just use it.  A radically different alternative might be
better.  But, given this kind of path-like approach, having a lot of
aliases could just make it harder to find things, refer to things when
talking to other people, etc.

> ?  It would of course require some changes to Ruby, and some care would
> need to be taken on behalf of the module maintainers, but the module
> maintainers already do that anyway.  At least those modules that got
> into some sort of standard library could be guaranteed to be consistent.
>  You could also do something for your apps like uninstalling
> XML::Parsers::REXML, and replacing it with your own library that is
> interface compatible and aliases to XML::Parsers::REXML even though it
> isn't REXML.

Although... if a given application actually calls for REXML (as
opposed to letting one specify one's own parser -- which we're
probably a long way from, since we haven't decided on a general Ruby
XML API :-) then it's probably best to let it use REXML.  Wouldn't the
kind of replacement you're describing lead to all sorts of potential
annoyances if the application gets updated, the other parser gets out
of sync with REXML, etc.?


David

-- 
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web:  http://pirate.shu.edu/~blackdav