Re: Web Module (Was: Perl6 new features)
On Mon, 25 Jun 2007 09:57:18 +0200, Hakim Cassimally wrote: On 23/06/07, chromatic [EMAIL PROTECTED] wrote: On Friday 22 June 2007 11:07:35 Chas Owens wrote: Please, god, no. Or at least make two distributions: Bare Perl 6 and Perl 6. Many companies have a Only Core Perl policy. They refuse to install CPAN modules because We don't trust them. I think of this the same way I think of Do not drink even if you mix with beer labels on bleach bottles. Stupid people often remove their genes from the pool. We should not discourage stupid business practices from doing the same. Releasing a language without a useful, easily installable library bundle could quite reasonably be construed as a stupid business practice. I will just voice my support for putting best-of-breed modules for very common tasks (CGI, DBI for sure) in the core. It may not be elegant, but it is practical... and Perl has weighed in on that side of the dilemma before. I think part of Perl 4's success was the one stop shopping availability of numerous useful functions that would otherwise have required linking in a library, e.g. dbmopen, crypt, shmget, gethostbyaddr, math functions, etc. I think the synergistic effect of the combination of all these functions being so readily available helped Perl take off. Please continue the tradition of tending to err on the side of practical over elegant. It may not seem rational that avoiding the need to type cpan Foo::Bar makes a huge difference, but I believe it does, for certain modules. -- Peter Scott http://www.perlmedic.com/ http://www.perldebugged.com/
Re: Web Module (Was: Perl6 new features)
On 6/25/07, Peter Scott [EMAIL PROTECTED] wrote: I will just voice my support for putting best-of-breed modules for very common tasks (CGI, DBI for sure) in the core. Of course, then you get the disadvantage that most users will see new versions of those modules as often (or seldom, as it were) as perl itself. Luke
Re: Web Module (Was: Perl6 new features)
How about a Bundle::Common? Streamline both the core and the inclusion of the most commonly used modules? The core does include the CPAN module, right? Personally, I *prefer* grabbing what I need piecemeal, but I understand making it easy if possible --- Luke Palmer [EMAIL PROTECTED] wrote: On 6/25/07, Peter Scott [EMAIL PROTECTED] wrote: I will just voice my support for putting best-of-breed modules for very common tasks (CGI, DBI for sure) in the core. Of course, then you get the disadvantage that most users will see new versions of those modules as often (or seldom, as it were) as perl itself. Luke === Hodges' Rule of Thumb: Don't expect reasonable behavior from anything with a thumb. Choose the right car based on your needs. Check out Yahoo! Autos new Car Finder tool. http://autos.yahoo.com/carfinder/
Re: Web Module (Was: Perl6 new features)
Hakim Cassimally skribis 2007-06-25 9:57 (+0200): Releasing a language without a useful, easily installable library bundle could quite reasonably be construed as a stupid business practice. A useful, easily installable library bundle does not have to be in the core distribution. Debian already has its own split between perl and perl-modules. This is a great scheme that allows Debian to use Perl in the base system, without requiring the loads of unused modules that usually come with it. If you need those modules, though, you can easily install them. It would be great if Perl had this by default, because it would make it easier for vendors to choose to use Perl in their base system. It would also make Perl a more attractive choice for embedded systems. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: Referring to source code within Perldoc
David Green wrote:
(Unless I'm missing something, which is always possible; you can put
a piece of POD geographically next to a Perl declaration, but I'm not
sure that's unambiguous enough. Hm, why not? POD doesn't know
what's going on around it, but Perl does, and could say, I've just
declared $size, and the next line starts a chunk of POD, so I'll
simply copy it into $size's 'documented' trait... would that work??)
It is doable: say that any Pod section that appears within or after a
class definition is considered by perldoc to refer to that class.
The problem with this is that you're forcing the Pod author to
organize his documentation in a manner that precisely mirrors the
organization used by the Perl programmer, and to scatter it throughout
the module. This isn't necessarily a deal-breaker because the Pod
author is usually(?) going to _be_ the Perl programmer (thus letting
him reorganize the classes to match the preferred documentation
sequence or vice versa), and because the Pod author may _prefer_ to
place the documentation in close proximity to the source code being
documented. But it would be nice to have more freedom of placement of
documentation for those with other preferences.
There's the new 'A' tag, which specifically refers to a word or
phrase in the source code. But that's a single inline tag; so it's
questionable as to how useful it would be for the purpose of
associating an entire Pod section to a piece of source code. In
addition, the 'A' tag, as written, makes explicit use of exactly the
geographic positioning that we're trying to get around.
--
Then there's the suggestion that I made about providing a Pod rule (or
Pod rules) for the purpose of identifying points in or sections of the
source code for more robust referencing. In my proposal, I suggested
being able to say something like '=code Foo' to identify the start of
a section of source code that abstractly relates to the label 'Foo',
coupled with the ability to tell a Pod section elsewhere that it is
associated with the source code identified by 'Foo' (using something
like '=begin pod :AFoo' to do so).
At the time, I was thinking in terms of allowing more freedom of
placement of 'A' tags; but it also works for giving entire pod
sections freedom of placement while still maintaining ties to specific
source code: for example, perldoc could look for the '=code' rule that
precedes or encompasses a given class definition and then associate
any Pod sections that attach themselves to that rule with that class.
So while the '=code' rule would have to maintain a close geographic
relationship to the source code in question, the documentation itself
would not.
Ideally, this wouldn't replace the proximity-based bindings, but would
supplement it, with the idea that Pod sections with :A... traits
would be bound to whatever follows the associated '=code' rule, while
those without :A... traits would be bound to whatever they follow.
Best of all, none of these bindings would be Pod's responsibility. As
far as Pod is concerned, the only use that '=code' rules would have
would be in service to 'A' tags, and could maintain ignorance about
what the source code speaks of. Perldoc would have the final
responsibility of binding documentation to definitions.
--
The other way to go about it would be to have the source code refer to
Pod sections:
class Foo is documented(Bar) {
has $.x is documented(Baz);
}
...
=begin Bar
...
=begin Baz
...
This places the responsibility of bindings on the language (in this
case, Perl) - each of which would have to come up with its own syntax
for referencing documentation. This is fine as far as Perldoc is
concerned, but does raise issues if you decide that you want to do
something similar with, say, C++ or HTML.
--
Jonathan Dataweaver Lang
Re: Web Module (Was: Perl6 new features)
On Monday 25 June 2007 00:57:18 Hakim Cassimally wrote: Releasing a language without a useful, easily installable library bundle could quite reasonably be construed as a stupid business practice. Of course. Yet some dozen years later, the argument for keeping interfaces such as File::Find (because sysadmins should learn all about closures and callbacks but can only understand global variables) and code such as CGI.pm (it was SelfLoader before SelfLoader was cool and *that* was a while ago) in the Perl 5 core has absolutely nothing to do with quality, ease of use, or suitability for the problem domain and everything to do with incidentally having been first and, thus, immediate evolutionary dead ends. -- c
