--nextPart2251829.cxrcRHvp1j
Content-Type: text/plain;
charset so-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Hello,
I didn't see a CC in the email Matz sent me, so I'm forwarding it on to the
group.
The context is that I'm contemplating some optimizations to REXML that will,
by necessity, cause some API changes which will break some code using REXML.
I emailed Matz and asked for his opinion on how to proceed, and asking him
whether he wanted to discuss it in private, or in Core. He responded that
he'd like to see it in Core, so here is his response to my email. My
response to him is after the forwarded part.
---------- Forwarded Message ----------
Subject: Re: Question about massive API changes
Date: Friday 27 January 2006 22:35
From: Yukihiro Matsumoto <matz / ruby-lang.org>
To: "Sean E. Russell" <ser / germane-software.com>
Hi,
On 1/27/06, Sean E. Russell <ser / germane-software.com> wrote:
> Hello Matz,
>
> If you think this is better discussed in core, let me know, and I'll repost
> it there.
Let us discuss there. I'd like to hear opinions from others.
> As I see it, I have three options:
>
> 0) Warn everybody, make the changes in 1.9, and have Ruby 2.0 break a lot
> of applications that use REXML. This will Piss People Off (tm).
>
> 1) Create a new package. REXML2, or something, and add it to the tree.
> This is, basically, a fork. People can migrate their apps to the new API as
> they see fit. This would mean:
> a) A duplicate REXML tree, which bloats the Ruby distribution,
> b) A semi-duplicate tree, containing only the files which have
> changed and which references the base REXML installation.
> c) Use a library versioning tool, like Thomas Sawyer's Roll
> (http://roll.rubyforge.org)
>
> 3) Don't do anything. Which sucks, because it means no optimizations.
How about option 4, replace REXML in 1.9? This means no duplication in
the distribution (1.8 with old REXML, 1.9 with new REXML). For
migration issues,
you can provide gems for each REXML that allows incompatible versions
co-exist. Or, rename new version to, say, XML.
matz.
-------------------------------------------------------
I was actually going to suggest renaming the package to, simply, XML, but I'd
want to get approval for that level of egotistical renaming. Of the
solutions that have occurred to me, this (2a or 2c) is the one I prefer,
although I don't particularly like any of them. (2) bloats the Ruby
distribution, especially if it becomes SOP (Standard Operating Procedure, for
the non-native-English speakers). At some point, you *have* to clean out the
cruft, so at some point, you're going to break old applications.
Personally, I think that breaking legacy code is the *worst* kind of breakage.
You'll have server apps that people installed ages ago running on servers
sitting in closets that have been walled over, that have for years quietly
been doing their jobs so well that people have forgetton that they existed,
except as an IP on the subnet. And they suddenly stop working... and I
guarantee that it won't be obvious to most people what caused the breakage,
because the people doing the upgrades aren't the ones responsible for the
apps. It will be an especially obscure problem for people who hired
contractors who secretly used Ruby for some part (or all) of an application,
and then left and moved to Albuquerque. Some consultants actually *like*
this sort of thing: the phone rings, an old client in a panic, and dollar
signs dancing like proverbial sugar plums... but I would be embarrassed by
it.
There's a discussion about library versioning that this issue is skirting.
can solve my specific problem, but I think that, as Ruby ages, you'll see
more and more issues like this cropping up in popular libraries like YAML,
for example, and it would be worthwhile discussing a broader solution.
However, while I think the topic of library versioning is one that the Ruby
community should really be putting more effort into, I'm selfishly concerned
about a specific solution about what to do with REXML. I have code that
halves the current memory usage, but I can only do it by breaking some -- and
what might be common -- idioms.
In addition to Matz, I'd most particularly like to hear from the various Daves
in the group. I find that the Daves' opinions are often worth paying
attention to. Any suggestions are greatly appreciated.
--
--- SER
"As democracy is perfected, the office of president represents,
more and more closely, the inner soul of the people. On some
great and glorious day the plain folks of the land will reach
their heart's desire at last and the White House will be adorned
by a downright moron." - H.L. Mencken (1880 - 1956)
--nextPart2251829.cxrcRHvp1j
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2-ecc0.1.6 (GNU/Linux)
iD8DBQBD2vy8P0KxygnleI8RAieSAKCV1kj3FUCgcoVADxWh7RuldvLV3wCgpEaH
BXSb/S1kf3Fjqb2VpWlOjB8
Gf
-----END PGP SIGNATURE-----
--nextPart2251829.cxrcRHvp1j--