Please take this discussion to the -strict mailing list.
K.
--
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source development, consulting and solutions
Level 10, 500 Collins St, Melbourne VIC 3000
Phone: +61 3 9614 0949 Fax: +61 3 9614 0948 Mobile: +61 410 664 994
You would need two (or more) perl executables.
The downloaded CPAN (or other source) scripts/modules that don't follow
the conventions would either have to be ported to the local environment.
Or they would need their own executable that doesn't follow the standard.
One or more groups will suffer
On Fri, Aug 04, 2000 at 11:37:30AM -0700, Peter Scott wrote:
> It would not be "you need to rebuild your perl", but "the administrator of
> this site does not allow unstrict programming by default."
The original poster said "a compile-time option to be decided by the
administrator of each site".
At 10:59 AM 8/4/00 +0200, Johan Vromans wrote:
> > What if the default strictness of vars was a compile-time option to
> > be decided by the administrator of each site?
>
>Good grief, no! Perl should be perl, and not depend on site issues.
>And, in anticipation: yes, there _is_ a difference betw
> IME, I find it more dangerous to do behind-the-scenes hand holding than
> to simply teach them the hows and whys of the "right way."
Exactly.
> The key word above is "encourage". You're not really encouraging
> anything - you're now having the language mandate particular constructs,
> withou
On Fri, Aug 04, 2000 at 09:02:50AM -0400, Tad McClellan wrote:
>
>Me too!
>
>I am amazed that I tell them to use both about *20 times* during the
>course of the course :-), yet I get email questions later that
>don't have them (which I just bounce and tell them to send it
>back when it is "clean"
On Thu, Aug 03, 2000 at 10:33:21PM -0700, Peter Scott wrote:
> A constant topic
> of discussion is how to make Perl more accessible and friendly to the the
> newcomer,
And we will get a chance to discuss that very thing right here,
(I already think we 're going to need a sub-list for that o
On Fri, 04 Aug 2000, Jeremy Howard wrote:
> OK, so maybe I'm taking up an unwinnable cause, but I
> un{fourth,third,second,nominate} this. Maybe it's my mod_perl bias
> speaking--the CGI scripts people post to the mod_perl list and say 'will
> this work under mod_perl?' sometimes make me need a c
> What if the default strictness of vars was a compile-time option to
>be decided by the administrator of each site?
That would hamper portability.
Then again, the right PERLOPTIONS=-M... set in /etc/profile might
work, too, but that -M is forbidden in file-based scripts.
--tom
"J. David Blackstone" <[EMAIL PROTECTED]> writes:
> Notice that the $x in one_x refers either to the global $x if called
> from the main program, or to the "local" $x in two_x when called
> from there.
Wrong. It always refers to the global $x. But that global $x has
sometimes a localized value.
"J. David Blackstone" <[EMAIL PROTECTED]> writes:
> How many of those large projects have you participated in? How many
> people do you work with that you have to constantly cajole and prod to
> "use strict;"? It is indeed an issue, in several ways.
I've done several large projects and it ha
I eighth this (or whatever). Perhaps, though, in addition to adding a
zillion new command-line switches, Perl could check the name of the
executable?
funperl -pe 's/foo/bar/'
- vs. -
#!/usr/local/bin/bdperl # (-w, `use strict', etc. implied)
Rationale: The one thing a one-liner doesn
Bryan C.Warnock wrote:
> On Thu, 03 Aug 2000, Simon Cozens wrote:
> > On Thu, Aug 03, 2000 at 08:36:01PM -0700, Nathan Wiger wrote:
> > > > Keep default Perl free of constraints such as warnings and strict.
> > >
> > > I second this.
> >
> > I third this. Perl is not, nor do I believe it ever shou
Nathan Wiger wrote:
>
> > =head1 TITLE
> >
> > Keep default Perl free of constraints such as warnings and strict.
>
> I second this. If the current definition of "lexical" remains unchanged
> (which I strongly suspect it will),
Lexical scope has a standard non-Perl definition. It means you c
At 11:04 PM 8/3/00 -0500, J. David Blackstone wrote:
> As the initial proponent of the opposing RFC, I feel I should make a
>response. Let the will of the Perl6 community and Larry Wall prevail.
> I'm sure we'll all be mostly happy, no matter where that takes us.
I will hitch my wagon to your
On Thu, 03 Aug 2000, Simon Cozens wrote:
> On Thu, Aug 03, 2000 at 08:36:01PM -0700, Nathan Wiger wrote:
> > > Keep default Perl free of constraints such as warnings and strict.
> >
> > I second this.
>
> I third this. Perl is not, nor do I believe it ever should become, a B&D
> language by defa
As the initial proponent of the opposing RFC, I feel I should make a
response. Let the will of the Perl6 community and Larry Wall prevail.
I'm sure we'll all be mostly happy, no matter where that takes us.
Daniel Chetlin <[EMAIL PROTECTED]> wrote:
> Perl5 is usable with no hassle as a quick-a
On Thu, Aug 03, 2000 at 08:36:01PM -0700, Nathan Wiger wrote:
> > Keep default Perl free of constraints such as warnings and strict.
>
> I second this.
I third this. Perl is not, nor do I believe it ever should become, a B&D
language by default. "Making easy things easy", remember that?
--
> =head1 TITLE
>
> Keep default Perl free of constraints such as warnings and strict.
I second this. If the current definition of "lexical" remains unchanged
(which I strongly suspect it will), I think Perl should remain loosely
typed by default. Make people add
use strict;
use warnings;
=head1 TITLE
Keep default Perl free of constraints such as warnings and strict.
=head1 VERSION
Maintainer: Daniel Chetlin <[EMAIL PROTECTED]>
Date: 3 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 16
=head1 ABSTRACT
Perl5 is usable with no hassle as a quick-and-dirty pr
20 matches
Mail list logo
