http://www.onlamp.com/pub/wlg/2225
enjoy,
-pate
Pat Eyler pate@eylerfamily.org writes:
Yeah, I wrote that after the RAA.succ thread. 
···
–
Testing can show the presense of bugs, but not their absence.
– Dijkstra
Hi –
Interesting. Simon (hi Simon!) is probably right that “Definitive
[library module] names discourage wheel reinvention.” The problem,
though, is that such an approach means that whoever writes the first
module called “XML::Parser” or “Text::Soundex” (or whatever) ends up
having written the definitive one, whether it’s any good or not.
(I guess one could then write and contribute “XML::Parser::Good”, but
somehow that doesn’t entirely address the difficulty
David
···
On Wed, 30 Oct 2002, Pat Eyler wrote:
–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav
In article Pine.LNX.4.44.0210291331210.10883-100000@candle.superlink.net,
Hi –
Interesting. Simon (hi Simon!) is probably right that “Definitive
[library module] names discourage wheel reinvention.” The problem,
though, is that such an approach means that whoever writes the first
module called “XML::Parser” or “Text::Soundex” (or whatever) ends up
having written the definitive one, whether it’s any good or not.(I guess one could then write and contribute “XML::Parser::Good”, but
somehow that doesn’t entirely address the difficulty
Well, perhaps the original writer of XML::Parser can be convined to
replace his parser with the new one if the new one offers significant
advantages… But then again, the new one should adhere to (or at least
provide a compatibility) the old one’s API.
Something that I don’t think Simon (hi Simon!) said explicitly in the
article but was implied: Wise use of namespaces is important. I think
this is something that we’re not always doing well.
Every library should be wrapped in a module(s) to narrow the namespace
used by the library, like:
module ::<minor-catagor(y|ies)>*::<lib_name>
But I think we’ve tended not to do this.
So, should we make it a requirement that every module under the Library
catagory use a namespace like, for example:
module Library::Datastructure::BitSet
?
Or perhaps, the ‘Library’ part is just implied, so maybe it should be:
module Datastructure::BitSet
?
Of course if the user doesn’t want to type ‘Datastructure’ all over the
place, the module can be mixed-in.
Phil
dblack@candle.superlink.net wrote:
Hi –
Interesting. Simon (hi Simon!) is probably right that “Definitive
[library module] names discourage wheel reinvention.” The problem,
though, is that such an approach means that whoever writes the first
module called “XML::Parser” or “Text::Soundex” (or whatever) ends up
having written the definitive one, whether it’s any good or not.(I guess one could then write and contribute “XML::Parser::Good”, but
somehow that doesn’t entirely address the difficultyDavid
David,
I think you’ll find that people are rather good at policing themselves in
this regard. It rarely happens that a definitive name gets used by some
newbie who doesn’t put out quality code. Even if that situation does
occur, it can be resolved in a few different ways:
- A more experienced author requests the name from the original author
(or offers lots of, uh, “patches”) - A similar name is used, or the name is changed and/or slightly to get
the point across- e.g. Net::SSH (worthless) and Net::SSH::Perl (awesome) - The author has an “accident” and someone else takes over the namespace
- JUST KIDDING!
Sometimes it’s hard to come up with a good name. I used “Sys/ProcTable”
because it was based on Dan Urist’s Proc::ProcessTable module. I wanted
a similar name for those coming from Perl. I also didn’t want to use
“PS”, because that can be confused with PostScript. Maybe I should have
called it ProcessTable, but my carpal tunnel was kicking in when I
decided on the name.
My main gripe, personally, hasn’t been with naming schemes so much as a
lack of documentation for what are probably some potentially very useful
modules.
Regards,
Dan
···
On Wed, 30 Oct 2002, Pat Eyler wrote:
Interesting. Simon (hi Simon!) is probably right that “Definitive
[library module] names discourage wheel reinvention.” The problem,
though, is that such an approach means that whoever writes the first
module called “XML::Parser” or “Text::Soundex” (or whatever) ends up
having written the definitive one, whether it’s any good or not.
That’s what popped into my mind, too. A definitive name is great if there is
but one definitive module.
Things may have many names, and as long as there are ways to search on these
names, then there’s hope. Things can have a description, too, which we might
simply consider the rest of a really long name; it may be asking too much to
require a formal module name to serve as both as unique identifier as well as a
suitable description.
I happen to like “cutesy” names if they manage to convey some reasonable aspect
of the module. Distinctive names make it easier to search Google, for example.
(Compare searching Google for ‘Perl’, and then ‘Python’ or ‘Ruby’, on the
assumption that in both cases you want pages related to a programming language.)
Simon wrote, "If I’m writing C code to deal with Unicode, I’d look for a
libunicode. "
I find that odd; it presumes there would be only one such library, or that the
best/most suitable library would have that name. Why not look for “C Unicode
library”, and see what you find? It makes me think of the common observation
that nice, descriptive URLS are no longer important, because people either click
a link (where the descriptive text masks a difficult or unintuitive URL), or
they just use Google. Likewise, if I want some code, I would go to the RAA and
do a search. It won’t occur to me to get a lost of module names and scan them
fro something that seemed to have the appropriate name.
That’s not to say names aren’t important, but that names may not be the primary
way people locate things. If you go to RAA and search on “XML parser”, sure
enough, you get a list of parsers. (Almost. The list includes Rimport, which is
not a parser. The list excludes libxml. In both cases I think the descriptive
text plays a key role.)
And besides, I doesn’t Perl claim There’s More Than One Way To Name It?
James
See y’all (or some, anyways) in a few days!
···
David
–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav
Hi –
Hi –
Interesting. Simon (hi Simon!) is probably right that “Definitive
[library module] names discourage wheel reinvention.” The problem,
though, is that such an approach means that whoever writes the first
module called “XML::Parser” or “Text::Soundex” (or whatever) ends up
having written the definitive one, whether it’s any good or not.(I guess one could then write and contribute “XML::Parser::Good”, but
somehow that doesn’t entirely address the difficultyDavid
David,
I think you’ll find that people are rather good at policing themselves in
this regard. It rarely happens that a definitive name gets used by some
newbie who doesn’t put out quality code. Even if that situation does
occur, it can be resolved in a few different ways:
- A more experienced author requests the name from the original author
(or offers lots of, uh, “patches”)- A similar name is used, or the name is changed and/or slightly to get
the point across- e.g. Net::SSH (worthless) and Net::SSH::Perl (awesome)
OK… but these seem like solutions and workarounds to a problem which
I’m (abstractly, indefensibly) convinced shouldn’t have to arise in
the first place. Now, if only I could come up with the grand
alternative…
It may be that I draw the line differently from Simon. Meaning: as
Simon points out, no one would release something called
“Web::Browser”, because Web browser-ness is not a singular thing. It
then becomes a question of where one draws the line between singular
and non-singular things. I tend to think of XML parsers, for example,
as proliferating, and I tend to think of it as OK that they
proliferate. And I don’t even terribly object to having two or more
text-wrapping/formatting packages written in Ruby.
One sort of meta-question here is the question of categorization. One
thing I don’t like about CPAN and similar archives is the top-level
categories, which divide things into String, Web, Text, Math,
Database, etc. etc… It may be that this is a necessary evil (well,
“evil” is a bit strong but the divisions are very artificial and I
sometimes wonder whether they have an influence on how people think
about solving programming problems.
David
···
On Wed, 30 Oct 2002, Daniel Berger wrote:
dblack@candle.superlink.net wrote:
On Wed, 30 Oct 2002, Pat Eyler wrote:
–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav
ptkwt@shell1.aracnet.com (Phil Tomson) writes:
Every library should be wrapped in a module(s) to narrow the namespace
used by the library, like:module ::<minor-catagor(y|ies)>*::<lib_name>
One thing that has confused me (and continues to confuse me) about Ruby
libraries is that the library name isn’t necessarily related to the
namespace. For instance,
require ‘ruth/mri’
gets you the Ruby::Interpreter class. This is unexpected. Indeed,
when you require a library, you have no idea what classes you’re going
to get.
I would have mentioned that in my weblog but it seemed too Ruby-specific.
···
–
Overall there is a smell of fried onions. (fnord)
" JamesBritt" james@jamesbritt.com writes:
That’s what popped into my mind, too. A definitive name is great if
there is but one definitive module.
But as I mentioned, if there’s a definitive name, you have to think
more carefully about why you’re writing a different module, and your
name should reflect what’s distinctive about it. Consider
HTML::Parser, HTML::TokeParser and HTML::TreeBuilder. You can easily tell
that they’re all HTML parsing libraries but they have distinctive styles.
···
–
The Blit is a nice terminal, but it runs emacs.
Well, sometimes it’s not “bad” code, just a difference in philosophy.
For example, weren’t there two fairly good XML parsers before REXML?
And isn’t REXML the definitive one now?
Hal
···
----- Original Message -----
From: “Daniel Berger” djberge@qwest.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Tuesday, October 29, 2002 1:58 PM
Subject: Re: good link to read as we contemplate RAA, RAA.succ, et al
dblack@candle.superlink.net wrote:
Hi –
On Wed, 30 Oct 2002, Pat Eyler wrote:
Interesting. Simon (hi Simon!) is probably right that “Definitive
[library module] names discourage wheel reinvention.” The problem,
though, is that such an approach means that whoever writes the first
module called “XML::Parser” or “Text::Soundex” (or whatever) ends up
having written the definitive one, whether it’s any good or not.(I guess one could then write and contribute “XML::Parser::Good”, but
somehow that doesn’t entirely address the difficultyDavid
David,
I think you’ll find that people are rather good at policing themselves in
this regard. It rarely happens that a definitive name gets used by some
newbie who doesn’t put out quality code. Even if that situation does
occur, it can be resolved in a few different ways:
- A more experienced author requests the name from the original author
(or offers lots of, uh, “patches”)- A similar name is used, or the name is changed and/or slightly to get
the point across- e.g. Net::SSH (worthless) and Net::SSH::Perl (awesome)- The author has an “accident” and someone else takes over the namespace
- JUST KIDDING!
I would find it rather natural to reserve the “definitive” names for those
included in the Ruby standard library.
– Nikodemus
···
On Wed, 30 Oct 2002 dblack@candle.superlink.net wrote:
then becomes a question of where one draws the line between singular
and non-singular things. I tend to think of XML parsers, for example,
I missed the original mails that explained this.
And even if it is being rebuilt in a new way, why are we not
retaining the existing name?
After all, CPAN doesn’t change it’s name every year - and with
good reason. Continuity is important in the name for a language’s
central code repository.
Sorry if this is recovering old ground.
Cheers,
Euan
xlucid@users(.remove this).sf.(antispam.)net
Hi –
···
On Wed, 30 Oct 2002, Simon Cozens wrote:
" JamesBritt" james@jamesbritt.com writes:
That’s what popped into my mind, too. A definitive name is great if
there is but one definitive module.But as I mentioned, if there’s a definitive name, you have to think
more carefully about why you’re writing a different module, and your
name should reflect what’s distinctive about it. Consider
HTML::Parser, HTML::TokeParser and HTML::TreeBuilder. You can easily tell
that they’re all HTML parsing libraries but they have distinctive styles.
Then again, if you’re writing an HTML parser that does what
HTML::Parser does, but does it (in your opinion) better, or faster, or
whatever, then it’s potentially a pain to have to find a synonym or
near-synonym to use as a name.
David
–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav
I agree with David. Module names are not the place to describe what a module
does. To be included in an archive like RAA, a module should be associated
with a set of keywords defined by the archive maintainer for use in
catagorizing and searching. Or have I completely misunderstood what this
thread is about?
···
–
Best essay I’ve read in years:
http://www.spack.org/words/commandline.html
Simon Cozens simon@ermine.ox.ac.uk writes:
" JamesBritt" james@jamesbritt.com writes:
That’s what popped into my mind, too. A definitive name is great if
there is but one definitive module.But as I mentioned, if there’s a definitive name, you have to think
more carefully about why you’re writing a different module, and your
name should reflect what’s distinctive about it. Consider
HTML::Parser, HTML::TokeParser and HTML::TreeBuilder. You can easily tell
that they’re all HTML parsing libraries but they have distinctive styles.
Then what would you call NQXML, REXML, and expat? Each is an XML parser.
Each supplies a SAX-like and DOM-like parser (I think). Sure, they have
different features and different implementations. They’re essentially the
same thing at the core, though.
Which one gets the name XML::Parser?
Jim
···
–
Jim Menard, jimm@io.com, http://www.io.com/~jimm/
“I’ve memorized all the digits of pi. Just not the order they go in.”
– Charles A. Lieberman, in rec.humor.oracle.d
Hi,
···
In message “Why is RAA being replaced?” on 02/10/30, “Euan Mee” xlucid@users.sourceforge.net writes:
And even if it is being rebuilt in a new way, why are we not
retaining the existing name?After all, CPAN doesn’t change it’s name every year - and with
good reason. Continuity is important in the name for a language’s
central code repository.
We didn’t change the name of the central repository (RAA). During the
discussion about versions of RAA, we named each version different
name, just for convenience.
matz.
But isn’t this what version numbers are for? If the existing HTML::Parser
were unmaintained you’d just up the major version number and post – the
older one sit out there and get moldy. If I’m not mistaken that’s how CPAN
handles it (whereas the current RAA does not handle name collisions,
except to reject the new entry). If it is less than optimal to have
multiple entries with the same number but different version numbers… RAA
is a central database/repository, there is still a final authority who can
decide that an existing module should be deprecated in favor of a new one.
I’m a big fan of the way CPAN handles a lot of stuff… in fact, the only
thing that ever concerns me is that I have no clue about quality with some
modules. A good archive should probably include some way for users to
indicate feedback in terms of a rating and perhaps comments to other
users.
-michael
Michael C. Libby x@ichimunki.com http://www.ichimunki.com/ http://www.ichimunki.com/public_key.txt···
On Tuesday 29 October 2002 20:13, dblack@candle.superlink.net wrote:
Then again, if you’re writing an HTML parser that does what
HTML::Parser does, but does it (in your opinion) better, or faster, or
whatever, then it’s potentially a pain to have to find a synonym or
near-synonym to use as a name.
In article 3DBF3A58.3566.24C625@localhost,
I missed the original mails that explained this.
And even if it is being rebuilt in a new way, why are we not
retaining the existing name?After all, CPAN doesn’t change it’s name every year - and with
good reason. Continuity is important in the name for a language’s
central code repository.Sorry if this is recovering old ground.
I think it’s still being called RAA. You’re probably thinking of the
message that went out last week that said something like “RAA replaced”.
Basically that just meant that the interface to the RAA has been replaced
and improved. You can now do searches and there is catagorization.
Also perhaps you’ve heard talk about RAA.succ or RAA.next - that just
means the next version of the RAA.
AFIK the RAA is still going to be called RAA.
Phil
···
Euan Mee xlucid@users.sourceforge.net wrote:
In article Pine.LNX.4.44.0210292113380.11964-100000@candle.superlink.net,
dblack@candle.superlink.net wrote:
···
On Wed, 30 Oct 2002, Simon Cozens wrote:
But as I mentioned, if there’s a definitive name, you have to think
more carefully about why you’re writing a different module, and your
name should reflect what’s distinctive about it. Consider
HTML::Parser, HTML::TokeParser and HTML::TreeBuilder. You can easily tell
that they’re all HTML parsing libraries but they have distinctive styles.Then again, if you’re writing an HTML parser that does what
HTML::Parser does, but does it (in your opinion) better, or faster, or
whatever, then it’s potentially a pain to have to find a synonym or
near-synonym to use as a name.
Clearly HTML::MyBetterParser 
Using CPAN is much like using Perl, you get so used to the way it works
and the bits to avoid that it eventually seems perfectly natural and a
reasonable pain / gain tradeoff. ( 1/2
Mike
–
mike@stok.co.uk | The “`Stok’ disclaimers” apply.
http://www.stok.co.uk/~mike/ | GPG PGP Key 1024D/059913DA
mike@exegenix.com | Fingerprint 0570 71CD 6790 7C28 3D60
http://www.exegenix.com/ | 75D2 9EC4 C1C0 0599 13DA
In this case? None of them, IMO. They would become, under Simon’s
scheme (and I mostly of agree with it), XML::Parser::REXML,
XML::Parser::NQXML, XML::Parser::libxml. What I’d like to see to
really make this work and be powerful is to slightly change how
“include”/“append_features” works, particularly from the perspective
of including into the top-level. What would be nice is the ability
to do:
include XML::Parser::REXML as XML::Parser
Allowing me, in my code, to alias REXML as XML::Parser.
-austin
– Austin Ziegler, austin@halostatue.ca on 2002.10.29 at 22.29.21
···
On Wed, 30 Oct 2002 12:16:29 +0900, Jim Menard wrote:
Simon Cozens simon@ermine.ox.ac.uk writes:
" JamesBritt" james@jamesbritt.com writes:
That’s what popped into my mind, too. A definitive name is great
if there is but one definitive module.
But as I mentioned, if there’s a definitive name, you have to
think more carefully about why you’re writing a different module,
and your name should reflect what’s distinctive about it.
Consider HTML::Parser, HTML::TokeParser and HTML::TreeBuilder.
You can easily tell that they’re all HTML parsing libraries but
they have distinctive styles.
Then what would you call NQXML, REXML, and expat? Each is an XML
parser. Each supplies a SAX-like and DOM-like parser (I think).
Sure, they have different features and different implementations.
They’re essentially the same thing at the core, though.Which one gets the name XML::Parser?