Re: RFC 333 (v1) Add Cheader and Cunheader funtions to coredistribution
On 28 Sep 2000, Perl6 RFC Librarian wrote: =head1 TITLE Add Cheader and Cunheader funtions to core distribution The Cheader function would simply: 1. uc the first letter of each tag token and lc the rest, also converting _'s to -'s automatically 2. Add a colon separating each tag and its value, and exactly one newline after each one 3. Combine list elements into a comma-delimited string 4. Append a singular newline as the last element of the list CGI.pm can do this: print header(expires = '+1M'); # Expire in one month. Seems like the header function described above cannot. Oh well, one can always: use CGI; Alan Gutierrez
Re: RFC 333 (v1) Add Cheader and Cunheader funtions to coredistribution
On 28 Sep 2000, Perl6 RFC Librarian wrote: =head1 TITLE Add Cheader and Cunheader funtions to core distribution The Cheader function would simply: 1. uc the first letter of each tag token and lc the rest, also converting _'s to -'s automatically 2. Add a colon separating each tag and its value, and exactly one newline after each one 3. Combine list elements into a comma-delimited string 4. Append a singular newline as the last element of the list This just in from RFC 2068 HTTP/1.1 - 4.2 Message Headers: The field value may be preceded by any amount of LWS, though a single SP is preferred. Header fields can be extended over multiple lines by preceding each extra line with at least one SP or HT. Alan Gutierrez
Re: RFC 303 (v1) Keep Cuse less, but make it work.
On 27 Sep 2000, Piers Cawley wrote: Simon Cozens [EMAIL PROTECTED] writes: On Wed, Sep 27, 2000 at 03:49:10PM +0100, Tom Christiansen wrote: Don't change "use less" to "use optimize". We don't need to ruin the cuteness. "use less 'rolled_loops';" sounds really weird. We obviously need to introduce a synonymous Cuse fewer 'rolled_loops' for when we want to be grammatically correct. Or am I just being silly now? C use less 'recursion' sounds just find to me. The negation of C use less 'rolled_loops' , C use more 'unrolled_loops' , does not sound very weird at all. Weren't we planning on haveing a use more as an opposite of use less? If so, let cuteness prevail! Alan Gutierrez
Re: RFC 288 (v2) First-Class CGI Support
On Fri, 29 Sep 2000, Robert Mathews wrote: Alan Gutierrez wrote: HTML::Embperl stuffs form input into a hash just as proposed here. For multiple values it creates a tab-delimited string. This will not present the above trouble with commas, since when the user, for some odd reason, enters "Ann Arbor\tMI", in most browsers the input focus will jump to the next input on tab, and the tab does not get entered into a field. Netscape on Solaris has this tabbing behavior for text fields, but allows you to enter tabs in text areas. I guess your solution would be workable, though. Pity about Solaris. I wonder if Gerard Richter, HTML::Embperl mainter, has ideas about this? Another problem, regardless of array refs or tab-delim. A hash %CGI does not address keyword parameters: http://www.foo.com/cgi-bin/search?bar+baz Does this give us an array @CGI? Alan Gutierrez
Re: RFC 288 (v2) First-Class CGI Support
On Sat, 30 Sep 2000, iain truskett wrote: Or someone could split CGI.pm up so that there's CGI::FormValues and CGI::HTTPHeaders. By jove Mr. Truskett, that sounds like a smashing idea! Could we RFC this? Do you think Mr. Stien would think us pushy? IMHO this thread is discussing the implementation of a module, lets have an RFC that frames it that way. Alan Gutierrez
Re: RFC 333 (v1) Add Cheader and Cunheader funtions to coredistribution
On 28 Sep 2000, Perl6 RFC Librarian wrote: =head1 TITLE Add Cheader and Cunheader funtions to core distribution =head2 Location These are such lightweight functions that their impact on core would be negligible. As such, they could potentially be put directly into it, since they are just formatting functions compliant with open standards. They are lightweight functions so is there an enormous benifit to having them in the core implemented in C? Indeed they are just formatting functions, not primitives. There may be many applications for them, but there are many applications for Carp, Getopts::Long, File::Find, etc. It is an application specific function. This slope is slippery. Alan Gutierrez
Re: RFC 288 (v2) First-Class CGI Support
On Wed, 27 Sep 2000, Nathan Wiger wrote:
Robert Mathews wrote:
How are you going to handle multiple values for the same parameter?
With CGI.pm, you can say
@values = $q-param("foo");
2. make it a comma-delimited string:
$name = $CGI{name};
@name = split ',', $name;
The problem arises if your data has commas in it. Then you're hosed. So
door #1 might be the only solution.
Hosed indeed. One can control whether or not checkboxes, options, and radio
buttons have a comma in their value attribute. Method two fails when the
user enters "Ann Arbor, MI".
HTML::Embperl stuffs form input into a hash just as proposed here. For
multiple values it creates a tab-delimited string. This will not present
the above trouble with commas, since when the user, for some odd reason,
enters "Ann Arbor\tMI", in most browsers the input focus will jump to
the next input on tab, and the tab does not get entered into a field.
I've used HTML::Embperl a lot and I've not difficulty with series data,
and yes I've worked with checkboxes and selects. It will go a long way
for classic CGI. If the source is coming from other than a browser, or
from a scripting language within the browser it is possible to defeat
this scheme, but we are looking to keep it simple for the common case.
Re: RFC 288 (v2) First-Class CGI Support
On Wed, 27 Sep 2000, Adam Turoff wrote: On Wed, Sep 27, 2000 at 11:33:13AM -0700, Nathan Wiger wrote: Ziggy, are you interested in this idea enough (at all?) to stick a note about the 'header' function into the RFC? Or should I RFC it separately? Adding headers() to the core language (or a similar pragma that is automagically invoked by cgi) would make more sense to me. I'd be in favor of a new RFC. Adding it into cgi sounds like we're on the road to spontaneously reinventing CGI.pm... ^^^ You are probably finding that CGI.pm is huge for a reason. Because Frist-Class/easy-to-write CGI requires more than form posts and headers. This header functionality is application specific and does not belong in the core any more than the socket stuff which seems to be on its way out. I don't see why this has be implemented in the core in C. Once again, if core means core modules, and as a part of cgi.pm or headers.pm or some such I am not concerned. And a switch for tainting and inclusion of this module sounds peachy. No core. Alan Gutierrez
Re: RFC 279 (v1) my() syntax extensions and attribute declarations
On 24 Sep 2000, Perl6 RFC Librarian wrote:
I still hope that it doesn't get as complicated as all this. I know
there are arguments out there for specifying integer size and signedness
but I can't imagine that adding this stuff is a good thing.
Note that multiple types cannot be specified on the same line. To
declare variables of multiple types, you must use separate statements:
my int ($x, $y, $z) :64bit;
my string ($firstname, $lastname :long);
Not so bad if I don't have to worry about 64bit or long. I'd rather not
worry about integer versus string, but I assume there are some
performance gains in doing so.
$a[0] :32bit = get_val; # 32-bit
$r-{name} :private = "Nate"; # privatize single value
$s-{VAL} :laccess('data') = ""; # lvalue autoaccessor
Here I'd prefer to see private and laccess as functions.
private $r-{name} = 'Nate';
laccess $s-{VAL} = '';
And as far as the :shared modifier goes I much prefer the our keyword.
Alan Gutierrez
Re: RFC 288 (v1) First-Class CGI Support
On Tue, 26 Sep 2000, iain truskett wrote: * Adam Turoff ([EMAIL PROTECTED]) [26 Sep 2000 17:15]: On Tue, Sep 26, 2000 at 05:02:02PM +1100, iain truskett wrote: Is there much point having a lightweight CGI module? If you say 'I want it to load quickly', I say 'get mod_perl'. Agreed. The bottleneck in standard CGI is not parsing the query string or form post, it is the fork. There's more to it than just loading quickly. It should load quickly as in "load everything that's absolutely necessary but nothing more." Taint mode is necessary, and half the reason for this proposal. Make it so. Find a way to turn tainting on for CGI. But don't clutter the core with application specific functions. Doesn't everyone want to remove the sockets library from the core? But is anything else? I like what Nathan Wiger suggested --- that of the common headers function, but I also believe that belongs as a separate module. Hence: snip Nice code Mr. Truskett. Agreed. Split CGI into component parts. If all you want is headers, or cookies, then you can use those modules without incurring the penalty of loading all of CGI.pm. Robust input parsing: yes. General purpose output formatting: no, [...] Rudimentary HTTP header emission: probably. So this is the definition of first-class? As I've said before, first-class CGI to me means a language where I can focus on the HTML or XML I am creating. An example of a first-class CGI language is ASP or my beloved HTML::Embperl. I don't bother with CGI anymore, and when I did I was content with CGI.pm. I think it all belongs in the CGI module really. Then you're probably against this proposal. No biggie. Yeah. I contemplated saying that outright in the previous one but was having trouble phrasing it in a friendly sense =) It seems like we are talking about pulling some functions from a module to the core. And for no real good reason. Is query string parsing or header processing so time consuming that it must be implemented in C? For any sizeable application input and headers will not be enough. You'll need cookies and redirection certainly. At which point you will load CGI.pm anyway (if you are bothering to create this in classic CGI). Tainting sure. Functions no. Alan Gutierrez
Re: IDEA: my() extensions and attribute declarations
On Wed, 20 Sep 2000, Nathan Wiger wrote:
Camel-3 shows some interesting hints of what's been proposed for my
declarations:
my type $var :attribute = $value;
And we all know that you can use my to declare a group of variables:
my($x, $y, $z);
Here's the issues:
1. How do the two jive together?
They don't.
And, of course, the ultimate spaghetti:
my (int ($x :unsign, $y) :big, char $z :long) :64bit;
Meaning is left as an exercise for the reader. :-)
Show mercy Nate. What did the reader ever do to you?
I am hoping that I won't have to concern myself with signedness and size
of numerical values in perl6. It doesn't belong in a scripting language.
But there all sorts of modifications to my floating around that will
probably make the cut: the dubious laccess and raccess, public and
private, const, and shared.
Rather than loose the ability to say ($a, $b, $c) = (qw/a b c/) why not
just use some new keywords?
our ($count, $message) = (1, 'Mars needs coffee');
const (PI, HTTP_OK) = (3.14159, 200);
sub new {
my ($class) = @_;
my $self = bless ref $class || $class;
public (@$self{qw/ first_name last_name /}) = qw/Alan Gutierrez/;
private (@$self{qw/ weight salary /}) = qw/Err.. *Ahem*/;
laccess (@$self{qw/ age favorite_color /}) = qw/ 28 blue /;
raccess (@$self{qw/ gender eye_color /}) qw / male brown /;
}
As long as we don't have too many attributes (like int, 64bit, EBCDIC,
etc.) this is plausible.
Alan Gutierrez
Re: RFC 288 (v1) First-Class CGI Support
On 25 Sep 2000, Perl6 RFC Librarian wrote:
=head1 TITLE
First-Class CGI Support
First-class CGI to me means HTML::Embperl. It include a templating
lanaguage for creating HTML/XML pages and support for session management
via cookies.
Are we talking about having cookes close to the core? %COOKIE is there
just like %ENV?
$COOKIE{example} = ['Hello, ', 'World!'];
Could perl6 have features for embeded Perl in the tarball?
Could embedded perl become part of the perl langauge?
#!/usr/bin/perl -cgi
# Set defaults.
$FDAT{first_name} ||= 'Enter first name';
$FDAT{last_name} ||= 'Enter last name';
if ($FDAT{sent}) {
# Process form data.
}
while (EMBED) { print }
__EMBED__
html
body
form method="POST"
[+ 'Hello, World!' +]br
input name="first_name"br
input name="last_name"br
input name="sent" type="submit"
/form
/body
/html
In the above the hash FDAT is the form data form the POST. The embedding
language does neat things like add value attributes to inputs based on
the contents of %FDAT.
HTML::Embperl is my favorite embedded perl language, but maybe this
could be pluggable.
Alan Gutierrez
