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 phon
Kirrily Robert wrote:
>
> 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
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 deve
Pardon me for butting in at this late stage :-)
Since the purpose of coding conventions and guidelines is to make code more
readable to the majority of developers, wouldn't it make sence to settle on
something that can be processed by a utility like gnu indent ??? This way
developers could use a
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 t
On Sat, Aug 11, 2001 at 03:51:22PM -0400, Kirrily Robert wrote:
> [ moving to perl6-stdlib only; -meta doesn't need this. ]
>
> Jarkko wrote:
> >> Sys:: should be declared redundant and silly. Sys::Syslog simply
> >> hurts my teeth.
> >
> >Text:: is another silliness, though from for slightly di
On Sat, Aug 11, 2001 at 07:20:11PM -0400, [EMAIL PROTECTED] wrote:
> On Sat, Aug 11, 2001 at 02:16:49PM -0500, Jarkko Hietaniemi wrote:
> > One silliness is that the implementation "style" of the module
> > seems to creep to the naming:
> >
> > (1) Foo vs Foo_XS
>
> Well then, how do you name it
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> BTW, I am not sure it has been mentioned already. We should enfore
>> {} even for single line block. Since we use plenty of macros that
>> may be expanded to multi lines, it is much safer and consistent
>> to always use {}.
DS>
At 11:58 AM 8/13/2001 -0700, Hong Zhang wrote:
>This style is not very consistent,
> > if (...) {
> > ...
> > }
> > else
> > {
> > ...
> > }
>
>I believe it would better be
>
>/* comment */
>if (...) {
> ...
>}
>/* comment */
>else {
> ...
>}
Yes, absolutely. Being able to put meaningfull
I believe the advantage of
> if (...) {
> ...
> } else {
> ...
> }
is to write very dense code, especially when the block itself is single
line.
This style may not be readable to some people.
This style is not very consistent,
> if (...) {
> ...
> }
> else
> {
> ...
> }
I believe it w
On Mon, 13 Aug 2001, Dave Mitchell wrote:
> Nicholas Clark <[EMAIL PROTECTED]> wrote:
> > Does this mean avoid:
> >
> > if (...) {
> > ...
> > } else {
> > ...
> > }
> >
> > and instead use:
> >
> > if (...) {
> > ...
> > }
> > else
> > {
> > ...
> > }
> >
> > If my interpretation of what
On Mon, Aug 13, 2001 at 09:46:13AM -0500, Garrett Goebel wrote:
> From: Jarkko Hietaniemi [mailto:[EMAIL PROTECTED]]
> >
> > Remember, the goal for Perl 6 is to allow several modules sharing
> > the same name.
>
> Don't you mean several modules sharing a common named interface?
For now, module
From: Jarkko Hietaniemi [mailto:[EMAIL PROTECTED]]
>
> Remember, the goal for Perl 6 is to allow several modules sharing
> the same name.
Don't you mean several modules sharing a common named interface?
Or are you refering to module, version, and author? Or something else?
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> > =item *
> >
> > Uncuddled elses: ie avoid C<} else {>
>
> Does this mean avoid:
>
> if (...) {
> ...
> } else {
> ...
> }
>
> and instead use:
>
> if (...) {
> ...
> }
> else
> {
> ...
> }
>
> If my interpretation of what it means is cor
14 matches
Mail list logo
