multi subs with identical signatures: should be a warning ?
First, what's the recommended reference for learning how dispatching to
the right 'multi' sub is resolved. ?
I'd like to know the expected behavior in this case:
multi sub foo () { say b: }
multi sub foo () { say a: }
foo();
I would expect it would throw an error or at least a warning, since
there's no clear way to choose a correct sub to dispatch to.
Pugs currently dispatches to one anyway, without a warning.
A more insidious version of the same case is the following, which
I accidentally wrote more than once already...and then wondered why
my code wasn't working as expected...
multi sub foo (%names?) { say b: }
multi sub foo (@pos?) { say a: }
There, I have distinct arguments, but they are both optional, making
them the same as the case above.
Mark.
Re: the CGI.pm in Perl 6
Darren Duncan wrote: P.S. I originally sent this to just Mark Stosberg yesterday, and he suggested I sent it to perl6-users for more exposure, so here it is, slightly edited. And here is my reply to Darren, slightly edited. I'm only interested in CGI.pm so much as it holds up my work on CGI::Application. As far as I'm aware, adding cookie support is all that's left to do that to meet my needs. So for the most part, I don't intend to be making design decisions for or against your arguments. I do share your sentiment that CGI.pm shouldn't be a clone of how P5 works. I'd like the HTML building methods to stay out, which wasn't even one of the differences you cared about yourself. On the other hand, there is a real benefit to in being similar enough so that porting from Perl 5 is easy. Radical differences can forked into Web.pm or something. I'll provide some comments on your suggestions below. Note that I will make these changes myself if someone else doesn't. Great! 1. ALWAYS gather all GET/query-string variables that exist, regardless of whether this is a POST or GET query. The Perl 5 version currently discards any GET vars that are included in a POST request and doesn't provide any workaround save to uncomment a code line in CGI.pm itself. Eg, say you want to submit a POST form to this url: http://foo.com/bar/?screen=baz Stuff like that should just work, but for CGI.pm in Perl 5 it doesn't. I have to parse the query string myself if I get a POST request, to make that work, and its inane that Perl 5's CGI.pm doesn't just work with it. I see both sides to this and don't feel strongly about it. 2. Keep 2 distinct sets of query parameters, one each for GET (query string) and POST (HTTP body) variables, that are both initialized and can be appropriately read from and updated. They must be separate because it is legitimate to have variables with the same names in both places that must be kept distinct. Combining these is like combining cookie or session variable with either; all 4 are distinct things. I suggest that all accessors for these contain the words http get var(s) or http post var(s) in them respectively. For backwards computability, you could also keep param named functions which accesses a union of the above and the post ones take precedence in a name conflict. But the key thing is it must be possible+easy to use them separately. Practically every other web environment's basic built-ins, including ASP and PHP, correctly keep these separate, and its time for Perl's basics to join them. I agree here. 3. ALWAYS retain any multiple values for get and post vars. For ease of use, your accessors could look like http_post_var() and http_post_var_multi() etc, which fetch either just the first item as a scalar or an array ref having all the items (even if just one) respectively. I think this is already working. We always store values as arrays internally, and I think because of how Perl 6 works, it does the right thing if you expect a single value or an array returned. 4. Make UTF-8 the default HTTP response character encoding, and the default declared charset for text/* MIME types, and explicitly declare that this is what the charset is. The only time that output should be anything else, even Latin-1, is if the programmer specifies such. 5. Similarly, default to trying to treat the HTTP request as UTF-8 if it doesn't specify a character encoding; fall back to Latin-1 only if the text parts of the HTTP request don't look like valid UTF-8. I am not knowledgeable enough about this to haven an opinion. Currently CGI.pm-p6 defaults to Latin-1, apparently as a port for Perl 5. Since the related function was broken as recently as a few days ago, I know no one is depending on that default now, including me. 6. I suggest ditching the functional globals-storing CGI.pm interface and using the OO version only; much simpler. I made that change myself. It's OO-only now. I look forward to your commits! Once you start making changes, I'll let you know if you break anything CGI::Application depends on. It sounds like you probably won't. Mark -- http://mark.stosberg.com/
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
I agree completely. In that vein, I think that one thing a lot of web developers would like to have available more easily would be session management. In PHP it's as simple as $_SESSION['key'] = 'value'. I understand that CGI.pm is a fundemantally different concept from PHP and that this can't be completely taken care of by the module. Still, if something could be written in, I think it would make many people's lives simpler. In Perl 5, CGI::Session is one solution that feels this gap well. In frameworks like CGI::Application, sessions can be integrated so they are apart of the of the same object anyway: self.query -- CGI.pm object self.session -- CGI::Session object. As far as I'm aware, no work on CGI::Session for Perl 6 has started yet. I'm sure there will be some things that would be nice to change about it as well, as it currently has some features only for backwards compatibility. Mark
best practice for web form stickiness (was: Re: the CGI.pm in Perl 6)
Juerd wrote: Personally, I am *against* HTML generating for elements that are not form fields. And for form fields, I think the solution should be in the templating thing, not elsewhere. Stickiness makes sense on invalid data only anyway, and we need to put the error message and a pointer somewhere, and those are also templating things. Even the simple contact page is much better off with a nice templating tool, than with HTML generating methods. I think HTML::FillInForm is a much better way to handle form stickiness. It allows you to keep the form generation in HTML /and/ still support stickiness. So, it's fine with me if the sticky feature of CGI.pm doesn't re-appear. Mark
use perl5:CGI as a solution (was: Re: the CGI.pm in Perl 6)
Aankhen wrote: The major feeling was that there should be no CGI.pm (if someone was hellbent on using it, they could use the Perl 5 module). In theory, use perl5:CGI could be a fine solution. In practice, it hasn't worked out well for me. Even something that seems simple like passing a hashref to Perl 5 is not documented now. In summary, I found it easier to update CGI.pm p6 to meet my needs than to 'use perl5:CGI' to meet my needs. I think the reality it is yet to been seen now well calls to Perl 5 modules can work for the general case. Mark
use perl5:CGI as a solution (was: Re: the CGI.pm in Perl 6)
Aankhen wrote: The major feeling was that there should be no CGI.pm (if someone was hellbent on using it, they could use the Perl 5 module). In theory, use perl5:CGI could be a fine solution. In practice, it hasn't worked out well for me. Even something that seems simple like passing a hashref to Perl 5 is not documented now. In summary, I found it easier to update CGI.pm p6 to meet my needs than to 'use perl5:CGI' to meet my needs. I think the reality it is yet to been seen now well calls to Perl 5 modules can work for the general case. Mark
Re: the CGI.pm in Perl 6 (create a design on the wiki)
Juerd wrote: It does make sense to have a single toolkit that does all this. It does not make sense to have a single .pm that does all this. There's absolutely no need for having all these different tasks in one module. There's not even any benefit. You can just as well use a couple of nicely named, grouped, and reasonably standalone roles or classes, and then a single module to combine them all for the ease of use that you like. I suggest that those who have concrete ideas sketch out the API through a new page on the wiki. That could make it easier for someone else to pick up, if they have programming skill, but less API design experience. The result might be even multiple API designs (A more compatible CGI.pm and cleaner/newer/different Web.pm solution). http://rakudo.org/perl6/index.cgi Mark
Re: How to pass a ref from a language with no refs
Mark Stosberg wrote:
When Perl 5 has references and Perl 6 doesn't, I don't know what to
expect to when I need to pass a hash reference to a Perl 5 routine.
Such details make no appearance currently in the Perl 6 spec, but I'm
trying to gather them on the wiki if you have anything to add:
http://rakudo.org/perl6/index.cgi?using_perl_5_embedding
I saw there have been some commits lately to Perl5 embedding, so I tried
some experiments with pugs to figure out if I could determine reliable
ways pass hashes and arrays to Perl5, so that they are received as
hashes, hashrefs, arrays, or arrayrefs, as appropriate.
I came up with the following test. As you can see, with arrays I was
able to pass them as a reference or not. However, when attempting to
pass a hash, it always came through as a hash, never flattened. Have I
missed something?
my $p5_dumper =
eval('sub {use Data::Dumper; print Dumper(@_); }', :langperl5);
my @a = b c d;
$p5_dumper.(@a); # received as array
$p5_dumper.([EMAIL PROTECTED]); # received as arrayref
$p5_dumper.(VAR @a); # received as arrayref
my %h = ( a = 1 );
$p5_dumper.(@%h); # received as hashref
$p5_dumper.([,] %h); # received as hashref
$p5_dumper.(|%h); # received as hashref
$p5_dumper.(%h); # received as hashref
$p5_dumper.(\%h); # received as hashref
$p5_dumper.(VAR %h); # received as hashref
