Re: Perl 6 modules plan

2001-08-25 Thread Kirrily Robert

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

2001-08-25 Thread Paul Johnson

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

2001-08-14 Thread Garrett Goebel

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

2001-08-14 Thread Garrett Goebel

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

2001-08-13 Thread Tim Bunce

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

2001-08-13 Thread Kirrily Robert

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)