Re: RFC 357 (v1) Perl should use XML for documentation instead ofPOD
XML, on the other hand, uses as the escaping mechanism, helping a reader sort-out deeply-nested escapings. ... POD has a good advantage in that it's design allows for it to embed well into code. If documentation is to be alongside code, a direction to consider is to have the Perl program be an XML document itself, with the code inside of it, between designated tags. This would allow for the entire Perl program/document to be rendered in a unified manner, using one tool, and conforming to one meta-language, XML. By making a Perl program an XML document, the programmer is forced to read the XML. It should be noted that XML isn't supposed to be read by a person - it is meant to be read by a computer. The W3C document "XML in 10 points" states this as point three. From http://www.w3.org/XML/1999/XML-in-10-points : XML files are text files, as I said above, but even less than HTML are they meant to be read by humans. They are text files, because that allows experts (such as programmers) to more easily debug applications, and in emergencies, they can use a simple text editor to fix a broken XML file. .greg -- Greg Williams| If you wish to live a life free from sorrow, Cnation | think of what is going to happen as if it had [EMAIL PROTECTED] | already happened.
Re: RFC 339 (v1) caller-eval BLOCK
On Sep 30 2000 22:38:58, Perl6 RFC Librarian [EMAIL PROTECTED] wrote:
=head1 ABSTRACT
Ccaller is extended to allow complete access to the "call frame" of
the current subroutine call.
would this be better suited by the previously proposed (i'm not sure for perl6 though)
Cno scope; pragma? Looks like Nathan Wiger has already proposed a 'scope' pragma in
RFC 64, but it does not cover this functionality as far as I know...
as I remember, the Cno scope; pragma, when used, would simply act as if the
enclosing scope were not in place, enabling such things as:
if ($ints) {
no scope;
use integer;
}
Tom Christiansen brought up the idea on p5p at:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-11/msg00863.html
.greg
Re: RFC 254 (v1) Class Collections: Provide the ability tooverload classes
The DBI has this very problem! DBI-connect() returns DBI::db objects, DBI-prepare() returns DBI::st. If you want to override the behavior for statement handles and connections, its not enough to just subclass DBI::st and DBI::db, you must also subclass DBI and override connect() and prepare() (and hope DBI doesn't use DBI::st or DBI::db anywhere else.) Yes, I hadn't even considered that such a prominent class would have this problem ;) It works, but to quote Tim Bunce there... *sigh*. So anyhow, yes, this is a big, icky problem. Quite. By the absence of many responses to this RFC, I take it that there are no strong objections to the proposal. Likewise, there hasn't been much talk in support of it. I take it from the silence of the list that there is indeed a problem that this RFC addresses, but is only sufficient to fix the problem, and not necessary. .greg -- Greg Williams, Cnation, (310) 228-6924 "Wow, no intel, no microsoft, sounds like a computer that might... dare I say it... work!" -LHB
