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
Mark Stosberg wrote: I tend to look for new modules by keyword search anyway. I've been wanting to do something for the CPAN system. I often find the SEE ALSO section of modules to be incomplete. I was hoping that it would be possible to make RELATED MODULES a basic part of the webpage that is displayed when you browse for a certain module.
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
On Tue, Jan 20, 2004 at 12:23:09PM +, 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,
This is addressed to some degree in the Module::Build system, which allows you
to specify required module versions like this:
Ken::Module = '= 1.2, != 1.5, 2.0',
So there /is/ currently way to specify exactly which versions you expect
to be compatible. Unfortunately, unless the author of the required module
has made clear version numbers like you suggest...it make take some
digging to figure out exactly which versions should be required.
Mark
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: [Class::MultiList] Need feedback for first distribution
On Tue, 2004-01-20 at 01:55, khemir nadim wrote: I don't understand what the autoloading mechanism has to do with inheritance! (Something for me to learn I guess) I think its that as soon as you have AUTOLOAD defined, you can't inherit past that point, at least by the ISA mechanism: the AUTOLOAD function needs to know how to punt. -- 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.)
