Re: cpan name spaces (was: Re: Re3: Re: How about class Foo {...} definition for Perl? )
david nicol wrote: Here's a controversial assertion: Just because Damian Conway does something that doesn't make it right. I reccommend changing the name of the module when the interface changes, for instance I published Net::SMTP::Server::Client2 instead of hijacking Net::SMTP::Server::Client and producing incompatible higher-numbred versions. (internally I've got a Client3 as well, but it's not going to get published) In my opinion as soon as he broke compatability with something that people were actually using, he should have changed the name. http://search.cpan.org/~tbone/Parse-RecDescent-FAQ-3.25/FAQ.pm does not contain a section on version compatibility, maybe you could submit one? I am author maintainer of the Parse::RecDescent::FAQ - what happened vis-a-vis version compatibility? I have been far away from the mechanics of Parse::RecDescent for quite awhile. And yes, please email me something that you want put in there.
Re: cpan name spaces (was: Re: Re3: Re: How about class Foo {...} definition for Perl? )
On Wed, Jan 21, 2004 at 03:53:34AM -0500, Terrence Brannon wrote:
I am author maintainer of the Parse::RecDescent::FAQ - what happened
vis-a-vis version compatibility? I have been far away from the mechanics
of Parse::RecDescent for quite awhile.
And yes, please email me something that you want put in there.
From the Changes file:
1.90Tue Mar 25 01:17:38 2003
- BACKWARDS INCOMPATIBLE CHANGE: The key of an %item entry for
a repeated subrule now includes the repetition specifier.
For example, in:
sentence: subject verb word(s)
the various matched items will be stored in $item{'subject'},
$item{'verb'}, and $item{'word(s)'} (i.e. *not* in $item{'word'},
as it would have been in previous versions of the module).
(thanks Anthony)
F
Re: cpan name spaces (was: Re: Re3: Re: How about class Foo {...} definition for Perl? )
On Tue, Jan 20, 2004 at 11:12:25PM -0600, david nicol wrote: Here's a controversial assertion: Just because Damian Conway does something that doesn't make it right. It certainly doesn't but he's not alone in doing it. Just to come clean, I was never really bitten by the Parse::RecDescent change, it actually hit me very early on in development of my module so I just switched to using 1.9x style without any hassle but it was over 2 years between 1.80 and 1.90 so I could have been and I'd guess a lot of people were bitten. I reccommend changing the name of the module when the interface changes, for instance I published Net::SMTP::Server::Client2 instead of hijacking Net::SMTP::Server::Client and producing incompatible higher-numbred versions. (internally I've got a Client3 as well, but it's not going to get published) In my opinion as soon as he broke compatability with something that people were actually using, he should have changed the name. That's what's necessary in the current scheme but good names are in short supply so you end up with Client2, Client3, Client3_5 etc which is not so nice and especially for things like Net::POP3. Again, the result of gluing 2 strings together without a delimiter. This also makes it hard for say search.cpan.org to make you aware that there is a Client3 when you're looking at the Client2 page. A better (IMHO) alternative is to make the interface part of the version number as important as the name. This is equivalent to including it in the name except you don't lose information like you do when you just glue a number on the end of the name. You also get to use '.'s in the version number because you're not try to make a valid Perl module name. Then CPAN and other tools could understand the relationship between different versions of modules. Unfortunately, this is the bit I think will never happen, I don't think it would be possible to convince people that this is worthwhile, possibly because it's not worthwhile at this late stage. So in the absence of the full solution perhaps we should urge people towards sticking interface version numbers in the names of the modules. I've done it privately too but I'm not convinced that CPAN should be littered with My::Module, My::Module2, My::Module3 etc, F
Re: cpan name spaces (was: Re: Re3: Re: How about class Foo {...} definition for Perl? )
On Mon, Jan 19, 2004 at 11:03:05AM -0600, Chris Josephes wrote: Why would that be? I mean, the odds are if you're dealing with a non-core Perl module, you're going to need to know the name if you want to download it in the first place. If you use a module long enough, you'll get used to how it's called. It's not those I use every day that are the issue; it's those I use bi-monthly. I can easily remember to look up Net::FTP for an ftp client, but com::bluesville::smegma:algenon::net::ftp? It'd take me three goes to type it right even if i could remember the name. Mx.
Re: cpan name spaces (was: Re: Re3: Re: How about class Foo {...} definition for Perl? )
On Mon, Jan 19, 2004 at 11:05:31AM -0600, Chris Josephes wrote: Version numbering is an authorship issue. If I took over module Widget from author XYZ, I'd probably use higher version numbers than author X used to signify a newer release. To be sure, I'd also include POD documentation identifying my version of Widget to be a replacement for the version from author XYZ. If I'm looking for a module to do a job, I use search.cpan, and check by name; then, for likely candidates, I check out the README. I don't have time to read the POD too; I've got a job to do. Version numbering works great for linear systems, which generally occur only with single authorship. If you do your own version of Term::ProgressBar, and call it 3.00, and someone else does too, they will probably call it... 3.00. Boom! Mx.
Re: cpan name spaces (was: Re: Re3: Re: How about class Foo {...} definition for Perl? )
On Mon, 19 Jan 2004, Daniel Staal wrote: Basically, adding the author's name into the name of the module just trades an illusion of a 'clean' TLD for my headspace. I would rather have a messy TLD: there are tools that can help me search and sort that. Perl is *supposed* to help me clean my headspace, by not making me think about the inconsequential and irrelevant. Daniel T. Staal It's not really a perl issue as much as it's a CPAN issue. In most module cases, we're only talking about 1 or 2 lines of code. use au::author::Blah qw(func1 func2); ...or... use au::author::Blah; $b=au::author::Blah-new(); ...or if you used perl6... use au::author::Blah as Blah; In most cases, you'll only refer to the full name of the module once. The idea of organizing namespaces is to resolve the issues CPAN maintainers have had with naming conflicts, or namespace ownership issues. Christopher Josephes [EMAIL PROTECTED]
Re: cpan name spaces (was: Re: Re3: Re: How about class Foo {...} definition for Perl? )
* Chris Josephes [EMAIL PROTECTED] [2004-01-20 12:02]: In most cases, you'll only refer to the full name of the module once. Then why would it even matter that much? The idea of organizing namespaces is to resolve the issues CPAN maintainers have had with naming conflicts, or namespace ownership issues. I don't understand how changing the naming scheme is going to help at all with that. The problem you're describing is one of infrastructure, not a social one. How is a societal solution supposed to solve technical problems? -- Regards, Aristotle If you can't laugh at yourself, you don't take life seriously enough.
Re: cpan name spaces (was: Re: Re3: Re: How about class Foo {...} definition for Perl? )
On Mon, 19 Jan 2004 11:03:05 -0600 (CST), Chris Josephes wrote: On Mon, 19 Jan 2004, Mark Stosberg wrote: And what happens when module author gets married and get a new hyphenated last name? /sarcasm How often do CPAN ids really change? I doubt that an extablished author would extend his given name change to his CPAN id. Twice that I can remember: JAPHY - JPINYAN CTWETEN - CWEST -- Peter Haworth [EMAIL PROTECTED] Jarkko suggested throwing out [the unicode directory] (with a caution that attempting to use Unicode stuff would make demons fly out of your nose.) -- Simon Cozens
Re: cpan name spaces (was: Re: Re3: Re: How about class Foo {...} definition for Perl? )
* Martyn J. Pearce [EMAIL PROTECTED] [2004-01-20 12:02]: Version numbering works great for linear systems, which generally occur only with single authorship. If you do your own version of Term::ProgressBar, and call it 3.00, and someone else does too, they will probably call it... 3.00. Boom! Yes, that's what the module name is for -- one of the two should call it something other than Term::ProgressBar and if it's only to add ::NewAndImproved. Perl does not provide for keeping around same-named modules that differ in some other way. -- Regards, Aristotle If you can't laugh at yourself, you don't take life seriously enough.
Re: cpan name spaces (was: Re: Re3: Re: How about class Foo {...} definition for Perl? )
* Fergal Daly [EMAIL PROTECTED] [2004-01-20 14:34]: On Tue, Jan 20, 2004 at 12:17:51PM +0100, A. Pagaltzis wrote: Perl does not provide for keeping around same-named modules that differ in some other way. That's not true. There are many modules where for example version 1.xx has one interface and 2.xx has a different interface and then 2.xx where xx 37 is a slightly different to 2.xx for xx = 37 and so on. I was unclear. What I am talking about is that there is no provision to have Foo::Bar 0.11, Foo::Bar 0.42 and Foo::Bar 1.23 all available in the same installation of Perl. There are some modules like only.pm that impose their own conventions to allow this, but vanilla Perl does not account for such a situation. -- Regards, Aristotle If you can't laugh at yourself, you don't take life seriously enough.
Re: cpan name spaces (was: Re: Re3: Re: How about class Foo {...} definition for Perl? )
On Tue, 2004-01-20 at 07:41, A. Pagaltzis wrote: I was unclear. What I am talking about is that there is no provision to have Foo::Bar 0.11, Foo::Bar 0.42 and Foo::Bar 1.23 all available in the same installation of Perl. There are some modules like only.pm that impose their own conventions to allow this, but vanilla Perl does not account for such a situation. Sure there is: You can edit the include search path. -- david nicol In order to understand what another person is saying, you must assume that it is true and try to imagine what it could be true of. (George Miller; 1980.)
Re: cpan name spaces (was: Re: Re3: Re: How about class Foo {...} definition for Perl? )
On Tue, 2004-01-20 at 06:23, Fergal Daly wrote:
Not that this would ever be agreed upon, the old way is ingrained. Modules
will continue to do for example
PREREQ_PM = { Parse::RecDescent = 1.80 }
then fall over because 1.90 satisfies this requirement but is not actually
compatible,
F
Here's a controversial assertion:
Just because Damian Conway does something that doesn't make it right.
I reccommend changing the name of the module when the interface
changes, for instance I published Net::SMTP::Server::Client2
instead of hijacking Net::SMTP::Server::Client and producing
incompatible higher-numbred versions. (internally I've got a Client3
as well, but it's not going to get published)
In my opinion as soon as he broke compatability with something that
people were actually using, he should have changed the name.
http://search.cpan.org/~tbone/Parse-RecDescent-FAQ-3.25/FAQ.pm
does not contain a section on version compatibility, maybe you could
submit one?
--
david nicol
In order to understand what another person is saying, you must assume that it
is true and try to imagine what it could be true of. (George Miller; 1980.)
Re: cpan name spaces (was: Re: Re3: Re: How about class Foo {...} definition for Perl? )
On Mon, Jan 19, 2004 at 08:42:09AM -0600, Chris Josephes wrote: On Mon, 19 Jan 2004, Mark Stosberg wrote: I would rather CPAN be wide at the top level than have un-intuitive names. The author based system will also become more difficult when authors change hands, disappear, or there are multiple authors. There's kind of a trade-off here. Right now, when module authors disappear, it's very difficult for a new author to take over that namespace because it's registered to an author/email address that may not be active anymore. With author namespaces, they can just create a new namespace under their CPAN id. And then the 1000 people who use their module can all do a find and replace on all places where they have referenced the the module name with the other authors ids. And what happens when module author gets married and get a new hyphenated last name? /sarcasm I have enough trouble remembering APIs without trying to remember whether I need to load something in namespace of William, Will, Bill, Willie, or Willy. I can't say I'm a fan of this idea. Mark
