Good link to read as we contemplate RAA, RAA.succ, et al

Ah - so it’s about to be replaced, and there’s some sort of ‘beauty
parade’ under way between competing replacement designs?
Cheers,
Euan
xlucid@users(.remove this).sf.(antispam.)net

···

On 30 Oct 2002, at 11:20, Yukihiro Matsumoto wrote:

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.

Which one gets the name XML::Parser?

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.

I like that. (It presumes, though, that the APIs are the same.)

I was thinking about how namespaces and path names might be used to group
installed modules, such that an application could safely assume that all XML
parsers were installed under, say, site_dir/1.8/xml/parser/, and could then
decide what module to load based on what was found there.

James

···

-austin
– Austin Ziegler, austin@halostatue.ca on 2002.10.29 at 22.29.21

None of them, until (if ever) one of them becomes the canonical one,
included in the standard library.

– Nikodemus

···

On Wed, 30 Oct 2002, Austin Ziegler wrote:

Which one gets the name XML::Parser?

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

If them naming scheme is reversed,

NQXML::XML::Parser
REXML::XML::Parser
LibXML::XML::Parser

include XML::Parser::REXML as XML::Parser

This becomes

include REXML

Just a thought,

– Nikodemus

···

On Wed, 30 Oct 2002, Austin Ziegler wrote:

JamesBritt wrote:

Which one gets the name XML::Parser?

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.

I like that. (It presumes, though, that the APIs are the same.)

Aliasing classes is as easy as constant definition, so why not have
libraries organized like

XML::Parsers::REXML
XML::Parsers::NQXML
XML::Parsers::libxml

In your code you can just assign

module XML
Parser = Parsers::REXML
end

To the extent that the libraries are compatible, you can then write
generic code against the XML::Parser alias.

Which one gets the name XML::Parser?

None of them, until (if ever) one of them becomes the canonical one,
included in the standard library.

– Nikodemus

I second the idea that none be named that, and that they are all named

XML::Parser::REXML
XML::Parser::NQXML

And then just create your own shortcuts:

require “xml/parser/rexml”

Parser = XML::Parser::REXML

It doesn’t get any more Ruby-ish that that.

Gavin

···

From: “Nikodemus Siivola” tsiivola@cc.hut.fi

On Wed, 30 Oct 2002, Austin Ziegler wrote:

You’re right, but that reintroduces the normal namespace problem.
I’d still like to alias namespaces, although I’m not sure that it
would really work all that well (because of the way that namespaces
are actually modules).

-austin
– Austin Ziegler, austin@halostatue.ca on 2002.10.30 at 09.46.37

···

On Wed, 30 Oct 2002 20:25:35 +0900, Nikodemus Siivola wrote:

On Wed, 30 Oct 2002, Austin Ziegler wrote:

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
If them naming scheme is reversed,

NQXML::XML::Parser
REXML::XML::Parser
LibXML::XML::Parser

include XML::Parser::REXML as XML::Parser

This becomes

include REXML

But this is a name-space problem which could be solved by how the
modules are sorted & listed, in the “table of contents”.

···

At 11:51 PM +0900 10/30/02, Austin Ziegler wrote:

On Wed, 30 Oct 2002, Nikodemus Siivola wrote:

If them naming scheme is reversed,

NQXML::XML::Parser
REXML::XML::Parser
LibXML::XML::Parser

include XML::Parser::REXML as XML::Parser

This becomes

include REXML

You’re right, but that reintroduces the normal namespace problem.
I’d still like to alias namespaces, although I’m not sure that it
would really work all that well (because of the way that namespaces
are actually modules).


Garance Alistair Drosehn = gad@gilead.netel.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu