On Fri, Feb 16, 2001 at 08:41:02PM -0500, [EMAIL PROTECTED] wrote:
> On Fri, Feb 16, 2001 at 03:28:36PM -0800, Edward Peschko wrote:
> > Its because '-w' is a global switch.
>
> What about the new lexical warnings? "use warnings"?
umm... that's part of what this is all about. People don't have a policy
towards warnings, which makes '-w' useless.
I *want* a global switch. I want the ability to never have to forget to type
'use warnings' in a package and track it down for hour upon hour. Or 'use
strict'.
>
> > > I'm not sure what you mean by a policy. Do you mean you want people
> > > to have to say C<no strict; no warnings;> explicitly? Do you want to
> > > make it a conscious decision to shut off the safeguards?
> >
> > Yes!
>
> I thought this, too. In fact, its in that pseudo RFC I posted way
> back when as a rationale. After some observation of how people deal
> with strict, warnings, tests, etc... I really don't think there's any
> conscious decision there unless the person has already internalized
> the concepts.
and your point?
> In the same way that I unconsciously type '-wle' in all my one-liners,
> people will write '-q'.
Fine - let them do that.
> > People will get the point pretty quick.
>
> No, people will just shut it off pretty quick. This gains nothing.
Yes it does. It tells them about '-q' in a way that they don't have to
be searching through it in the manual.
> Trust me, having to type '-q' will not mean people will think about
> it. They'll just say "gee, that's annoying" and type it in. Lead a
> horse to water, etc...
Fine, let them think its annoying. They might think this for a while, and
then think *why* the '-q' is there, etc. etc. etc.
> > No, as far as I know we will be able to put 'use perl5' up on top of
> > their scripts, and they will convert over in their leisure.
>
> You'd be amazed at the sort of excuses people will use to avoid
> upgrading. The fairly innocent "[EMAIL PROTECTED]" to "foo\@bar.com"
> incompatibility has kept many companies down at perl4 even still
> today!
So what? perl5 isn't fundamentally broken is it? I'm assuming CPAN is still
going to work off of perl5...
Most likely, the way the upgrade is going to work is incrementally. RedHat,
ActiveState, Debian, etc. will silently upgrade their distributions to perl6.
There is lots more wriggling room than people think.
> Ok, saving ten characters of typing per file is not a valid reason to
> do anything, so nix that.
It isn't. Like I said, I want to have a global. I want to be able to
*boom* turn on warnings and strict and have it blanket cover my code. I can't
do that with the current situation. And this is fundamentally broken now.
> The upgrade path is made no easier by having to delete "-q" than
> having to type "use strict". That's totally swamped by the code sweep
> necessary when turning strict on in a formerly unstrict program.
no it isn't. again this is going to be pretty minor compared to the rest of the
changes that perl6 is going to have over perl5. There are two possibilities:
1) that perl6 is going to look so much like perl5 that it won't matter
2) that perl6 is going to have some fundamental improvements that
inherently break backwards compatibility.
Personally, I'm hoping for #2.
> There is no win here. People will shut it off without thinking.
I don't think so... Anyways,
> > Again, see up top. '-w' is a global flag, and hence you get thousands
> > of global warnings.
>
> I think this is covered by "use warnings".
No it isn't - '-w' is a global flag for a *reason*. If everybody had a
warnings policy, it would become useful again.
> > the point is that the notes would come at the bottom of every single
> > compilation. They would point out - by example - exactly where perl5
> > and perl6 differ.
> <snip>
> > WARNING: scalar assignment to a list. NOTE - this has changed since perl5
> > $a = $b, $d now parses as ($a = ($b, $d))!
>
> This would be a very useful feature to have, but its FAR too verbose
> for day-to-day usage. If you want to see a similar effect, try
> developing your code with "use diagnostics" on ALL THE TIME.
> Splitting the language is extremely dangerous, but we're covering that
> in a different thread.
> Here's something that came up in earlier discussions that stopped me
> dead. Many people like to shut off warnings when they ship code. I'm
> not going to argue the wisdom of this here, but there are valid
> business reasons to not want end-users to see warnings.
So what? let them do it. As it stands, they have to do this anyways - either
remove '-w' from their scripts, or remove 'use warnings' from their modules.
The only case where they would not have to do this is if they *never* used
warnings in the first place. In which case, they could add 'no warnings' to
the top of their scripts, although I don't vouch for the veracity of their
code.
> So if warnings are on by default, how do you shut them off? You
> either must edit the code as part of the build/distribution process or
> provide a wrapper program which runs it under -q. This assumes you
> even *have* a build process. Many (most?) places don't.
>
> In order to ship code with warnings off you must
>
> 1 - have a build process (not a simple task)
> 2 - edit the code automatically.
They have to do this anyways. This is a smoke and mirrors argument.
And in any case, I'm not very sympathetic. 'We can't provide people a
consistent, strong warning strategy because some people might find it harder
to release shoddy code.'
Ed
(ps -- as for the modules/scripts thingy... well, I guess I disagree with the
dichotomy part, but I could see where that would be a tough sell. ah well...)
