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
;)
Will subroutine signatures apply to methods in Perl6
Any word from on high whether subroutine signatures will apply to methods in Perl6? There's RFC128 and RFC97... but they both mostly dodge the issue of methods. The absense of method signatures for specifying required, optional, and named parameters... not to mention type-checking for validation and dispatch are why we've ended up with an assortment of parameter handling modules with conflicting styles.
RE: RFC 260 (v1) More modules
From: Michael G Schwern [mailto:[EMAIL PROTECTED]] Doh! Don't read email for two days and look what happens. Its like going on vacation and leaving the iron on. Speaking of which, I just re-read my previous email, and I want apologize for contributing to the flamebait. Sorry. Hopefully this post will be more constructive... On Tue, Sep 19, 2000 at 04:08:21PM -0400, Adam Turoff wrote: Are you proposing something like this: Standard distribution: 1: Everything (core, docs, standard modules) Alternative Distribution: 2a: core language (+ pragmatic modules) 2b: standard modules 2c: docs (possibly split into tutorials and reference) #1 would be the primary distribution. Definately #1. #2a..2c would be made available, but in a slightly less obvious way. When you go to download perl-current.tar.gz, you get #1. #2a..c wouldn't even be in the same directory. I share Tom's view here. I think it would be a bad idea to distribute the source tarball for the Core Perl Distribution without documentation. Has anyone made a case for the size of download issue? I was under the possibly mistaken impression that this was a size of install thing. the simplest way to do this is to make the default distribution contain the docs and let the user hunt a bit for the tarball without docs. If you're talking binary distributions I'd agree. If you're talking source... I'd differ. I'd rather see everyone start with the same package, and enable them to strip it down as they need. This goes back to whether its a size of install or download issue. Another is to provide several different install options. "make install" installs everything, as usual. "make small_install" installs just the current set of modules. "make tiny_install" installs a bare minimum, not even docs. Hmm. Might want to be a bit more fine grained. How about the heretical option to strip pod and comments from the standard library? How much of the problem is the size of the install vs. the size of the download? It would be nice if I could have one or two be full installs and the rest minimalist. Size of install is my issue. But, to bring this back to a Standard Library discussion... When does the need arise to draw a distinction between "The Standard Library" and "Standard Libraries"? The size of the standard library seems to be ever expanding... Garrett
