Re: Perl 6 modules plan
In perl.perl6.stdlib, you wrote: Er, okay, well scratch that example then :) But my point still stands: I think Perl 6 should have some sort of guidelines in this area, even if they're only a codification of what the majority of Perl authors do. Yes. See also perldoc perlstyle and the perlmodstyle which I recently posted to p5p. K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ You should see the ones we don't let out in public.
Re: Perl 6 modules plan
On Sat, Aug 25, 2001 at 09:40:05AM -0400, John Siracusa wrote: On 8/25/01 5:12 AM, Johan Vromans wrote: John Siracusa [EMAIL PROTECTED] writes: If you ask any Java programmer which is correct, myJavaMethod() or My_Java_Method(), I think you'll get a straight answer. From experience I can assure you this is not the case. There are a couple of (independent and mutual inconsistent) style guides on the web (e.g. Sun, Netscape). Each have their own followers. Er, okay, well scratch that example then :) But my point still stands: I I'd actually scratch the others too. That one was probably the best :-) think Perl 6 should have some sort of guidelines in this area, even if they're only a codification of what the majority of Perl authors do. Something like perlstyle and perlmodstyle for perl 5 then? -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
RE: Perl 6 modules plan
From: Graham Barr [mailto:[EMAIL PROTECTED]] On Mon, Aug 13, 2001 at 04:38:43PM -0700, Nathan Wiger wrote: And allow flexible calling styles. For example, you might say: # import args() for argument validation use Module::Interface qw/args/; sub my_func (@) { my %args = args({ positional = [qw/name email phone/] }, @_); } Which would allow you to call your function two different ways: my_func($name, $email, $phone); my_func(name = $name, email = $email, phone = $phone); This is the king of thing that CGI does, and IMO is exactly what we don't want. There should be ONE calling style for each sub/method. Allowing this _will_ cause different people to use different calling styles and also possible confusion. TOW of Perl? What about RFC128? http://dev.perl.org/rfc/128.html Subroutines: Extend subroutine contexts to include name parameters and lazy arguments It gives us a cleaner way to mix and match order dependant and named parameter lists. Not to mention the potential for optimization hints, parameter type checking and constraints (no auto-vivication), lazy evaluation, etc. I don't have the experience to make well balanced judgements in language and library design, but I would hope that RFC128 style function signatures would be required. I'm sure modules which prioritize on performance would chose ordered parameter lists, but higher level ones would benefit from a heavier reliance on named parameters. And if people'd RTFM on RFC128, perhaps calling style confusion would be minimal.
RE: Perl 6 modules plan
From: Michael G Schwern [mailto:[EMAIL PROTECTED]] On Tue, Aug 14, 2001 at 09:55:37AM -0500, Garrett Goebel wrote: There should be ONE calling style for each sub/method. Allowing this _will_ cause different people to use different calling styles and also possible confusion. It gives us a cleaner way to mix and match order dependant and named parameter lists. Not to mention the potential for optimization hints, parameter type checking and constraints (no auto-vivication), lazy evaluation, etc. I think you misunderstand. This isn't named parameters vs prototyped parameters vs args as list. The problem is the idea that functions should accept *multiple styles by default* which the proposed Module::Interface does. I don't think I'm misunderstanding. -There's a first! Why do we need a Module::Interface when RFC128 covers all this ground and more? It provides for required, optional, and type-checking of positional and named parameters. (and more). foo($this, $that, $whatever); foo( this = $this, that = $that, whatever = $whatever ); Or per RFC128, sub foo (INTEGER $this, STRING $that, FLOAT $whatever) { printf TMT %d %s, just my \$%.2f\n, $this, $that, $whatever } foo(1, 'way', 0.02); foo(whatever: 0.02, this: 1, that: 'way'); Saying that most core functions should be callable both ways is overkill. I didn't say that. What I did say is that I hoped RFC128 style function signatures would be required. That doesn't mean you have to use named parameters. Just that a function signature would be required. Graham stated that multiple calling styles are confusing... And I'd agree that Module::Interface and existing modules like CGI.pm could easily lead to confusion. But I don't see how that applies to the syntax proposed in RFC128. I suppose whether or not it is overkill to allow for both, will depend on the overhead involved in how it is implemented. According to RFC128, named parameters can be optionally specified. Either way, positional parameters will always work. So per Perl6 w/ RFC128, it'll be positional parameters or positional-and-named parameters. This is what CGI.pm does (for historical reasons, I believe, and not by design). It's unnecessarily confusing and requires a not insignificant amount of life-support to make work. CGI.pm does a lot of things for the convenience of its users. Like Tk and File::Spec, CGI's functions can be called procedurally or as methods. But lets not go there. If RFC128 flies... I don't see why this would be confusing or require any significant life-support. It'll be a language detail instead of an implementation nightmare. Just because it is an issue now doesn't mean it has to be one in Perl6. Having Module::Interface around to do this sort of thing when desired is nice, but please don't cannonize it. No. I've kludged together similar things when I thought I need it. -But RFC128 isn't a kludge. Though I'd so hoped that it would create world peace ;)
Re: Perl 6 modules plan
On Sat, Aug 11, 2001 at 02:31:47PM -0400, Kirrily Robert wrote: Ask wrote: On Thu, 9 Aug 2001, Kirrily Robert wrote: [...] =head2 The role of CPAN Will CPAN's role remain unchanged? Will there be a separate space for Perl 6 modules (6PAN)? If we do want to make changes to CPAN then Perl 6 gives us an opportunity for a flag day if we need one. OK, not an actually flag *day*, but at least a point where we can say Things are different for Perl 6 and to hell with backwards compatibility ;) No. Larry has said quite clearly that backwards compatibility is very important. There will be no flag day. Eh, that doesn't sound like something we want to do for quite a few years. What makes you say that? I can imagine a number of scenarios in which we decide to do things differently for Perl 6, which could mean that lots of Perl 5 modules don't come across cleanly and must be rewritten. If it's must then Perl 6 has not met it's self-declared goals. I doubt very much that'll happen. One very simple example is if we required each module to have $VERSION. There will be ways round that, and most if not all other issues. Tim.
Re: Perl 6 modules plan
In perl.perl6.stdlib, you wrote: While we're at it, I think that ExtUtils:: really needs renaming. Nobody talks about Perl extensions, they talk about modules. Or possibly just about Perl. I actually think the stuff in ExtUtils would be better off in Devel:: with the other developer tools. While you are at it you should consider redoing the APIs etc. so that they match. ie some consistency between method names and variable names, calling conventions etc... Also the PODs should be all written in the same style. Yes, yes and yes. Very early on in the perl6 process I did some analysis of the current standard library and it is surprising how inconsistent it is. Did you write anything down, and if so, can I have a copy please? I've browsed through it but not written anything much. IMO with a more consistent library more companies are likely to give perl a closer look. The way things are now I think perl suffers because it does not present itself as a single product, but an app with a lot of libraries thrown around it. Yup. I also think there's too much overhead in learning (and remembering) each library's quirks. My most common mistakes when using CPAN or core modules occur when the modules have inconsistent interfaces and I forget which ones take hashes and which take hashrefs, etc. Sure a quick RTFM sorts it out, but it's still annoying. K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ What I really need to put on the deed poll form is [EMAIL PROTECTED] -- Morgan (from the Netizen quotes file)