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
c
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
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 a
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
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 conventio
* 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
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 whe
* 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.
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?
>
> How often do CPAN ids really change? I doubt that an extablished author
> would extend his
* 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
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
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 ide
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 h
--As off Monday, January 19, 2004 11:03 AM -0600, Chris Josephes is
alleged to have said:
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.
Why would that be? I mean, the odds are if you're d
On Mon, 19 Jan 2004, Orton, Yves wrote:
> Also, the author namespaces issue is problematic in that how would you
> determine whose version is the latest, or correct or whatever.
>
Version numbering is an authorship issue. If I took over module Widget
from author XYZ, I'd probably use higher vers
On Mon, 19 Jan 2004, Mark Stosberg wrote:
> 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.
>
The namespaces don't have to change overnight.
> And what happens when module aut
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 ther
Title: RE: cpan name spaces (was: Re: Re3: Re: How about class Foo {...} definition for Perl? )
> > 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, disap
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, whe
19 matches
Mail list logo
