A. Pagaltzis writes:
> ... a fulltext search is never as coherent as a good keyword search.
> A problem with fulltext search is ranking; you don't have that with
> well-chosen name/keyword searches. Something's called HTML::Template
> or XML::Parser is obviously worth a look when I'm looking for a
On Sun, Jan 18, 2004 at 12:02:43PM +, Simon Cozens wrote:
> [EMAIL PROTECTED] (David Manura) writes:
> > Since Text::Balanced is a core module, distributed with
> > Perl, I'm not sure what the best way to report these are. E-mail the
> > author? rt.cpan.org? http://rt.perl.org (perlbug)?
>
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
In the beginning, we could just do this:
Hello World!
Then, they wanted us to do this:
http://www.w3.org/TR/html4/strict.dtd";>
Hello World!
Now, who can remember
"http://www.w3.org/TR/html4/strict.dtd";> ? It's irrelevant!
"html-4.01-en" would suffice, assuming a "st
--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
* Chris Josephes <[EMAIL PROTECTED]> [2004-01-19 15:46]:
> Searching doesn't have to be limited to the name of the module
> itself. Almost everything in CPAN has POD documentation, which
> could be parsed, or there could be extensions to Makefile.PL
> (or maybe META.yml files, for people that go i
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, A. Pagaltzis wrote:
> * Chris Josephes <[EMAIL PROTECTED]> [2004-01-19 14:39]:
> > I think sooner or later, we're all going to have to bite the
> > bullet and go with Java class naming conventions, like
>
> IMO, it is of the essence that modules have descriptive names.
> Other
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
* Chris Josephes <[EMAIL PROTECTED]> [2004-01-19 14:39]:
> I think sooner or later, we're all going to have to bite the
> bullet and go with Java class naming conventions, like
IMO, it is of the essence that modules have descriptive names.
Otherwise, searching for something specific becomes nigh
i
* Terrence Brannon <[EMAIL PROTECTED]> [2004-01-19 10:54]:
> There is also PApp::* by Marc Lehmann, short for [P]erl
> [App]lication
My understanding is that "PApp" is actually a proper name for his
framework, not a generic TLNS.
--
Regards,
Aristotle
"If you can't laugh at yourself, you don't
[EMAIL PROTECTED] (Chris Josephes) writes:
> Otherwise, CPAN will continue to grow wide at the top level.
I used to think that mattered. But then, we now have search.cpan.org, and
there's not really much requirement for CPAN to be hierarchical any more. As
I've written in the past (http://blog.sim
On Mon, Jan 19, 2004 at 07:14:19AM -0600, Chris Josephes wrote:
>
> I think sooner or later, we're all going to have to bite the bullet and go
> with Java class naming conventions, like
>
> org::simon-cozens::MVC
>
> or maybe Larry's recommendation of using CPAN id as a top level.
>
> simon::MV
On Sun, 18 Jan 2004, Lincoln A. Baxter wrote:
> In my case, it is a Server/Integration platform for framework. In that
> discussion (to be posted later this week maybe), I will suggest that
> instead of creating a new TLNS for the application, perhaps all such
> applications should eventually be
Lincoln A. Baxter wrote:
Perhaps we should have a discussion about what these should be, and
start to encourage folks to use them. Perhaps Application:: should be
added to this list. I see we have App:: but it has not be used for
this.
There is also PApp::* by Marc Lehmann, short for [P]erl
On Sun, 2004-01-18 at 17:34, Simon Cozens wrote:
> [EMAIL PROTECTED] (Terrence Brannon) writes:
[snip]
> > Does it not belong to the CGI::* namespace?
>
> I don't think it belongs in any namespace once it's finally abstracted, since
> it's sufficiently high level that it's more of an "application"
[EMAIL PROTECTED] (Terrence Brannon) writes:
> I'm sorry, but I must take the bait: is the framework
> Apache-dependant?
At the moment, yes. It's also tied to Class::DBI. And Template Toolkit. At the
moment. Once it's written and it works, I'll then abstract it.
> Does it not belong to the CGI::*
Simon Cozens wrote:
initiated them. I'm about to release a generic framework for web applications
that I wrote to help me keep track of beer tasting notes, but I plan to
call it Apache::MVC instead of BeerDB::MVC. :)
I'm sorry, but I must take the bait: is the framework Apache-dependant?
Does
[EMAIL PROTECTED] (Graciliano M. P.) writes:
> Well, this is why I made Class::HPLOO not dependent of HPL source.
Then it should not be called HPL. It's nothing to do with it. Please call
modules after what they do, rather than random unrelated projects that
initiated them. I'm about to release a
[EMAIL PROTECTED] (David Manura) writes:
> Text::Balanced and Filter::Simple indeed have quite a few bugs, which
> means that basically means any module that does source filtering is
> buggy.
Yes. The idea of using source filtered code in production worries me.
With source filtering in place, it's
> I don't see how HPL (an HTML templating system) is related to class
> syntax in Perl. Modules should be modular and each do one thing, one
> thing well. This module is widely applicable, including to many non-web
> applications. It seems, to me at least, that Class::HPLOO can be split
> into t
Graciliano M. P. wrote:
The first question I have...What is "HPL"? That puzzled me the most,
and I don't believe it is at all obvious.
HPL is another Perl embeded in HTML, where some resources, like the HTML
block, that exists in Class::HPLOO, were ported (simplier), to Class::HPLOO.
...
> The i
> The first question I have...What is "HPL"? That puzzled me the most,
> and I don't believe it is at all obvious.
HPL is another Perl embeded in HTML, where some resources, like the HTML
block, that exists in Class::HPLOO, were ported (simplier), to Class::HPLOO.
Also the arguments definition:
Graciliano,
I like it. I could offer a few suggestions, as source filtering has
been my recent interest.
The first question I have...What is "HPL"? That puzzled me the most,
and I don't believe it is at all obvious.
Second, the POD might include a section on the rationale for the syntax
cho
39 matches
Mail list logo
