I'm aware that Dave doesn't think it sane to apply his variable naming patch
to maint as is:

http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2004-04/msg007...

and I now agree with his reasoning. I'm not convinced that if we made it
optional (but not default) that no-one would use it - the comment of people
at the Austrian Perl Workshop was that this would be a really useful feature,
and that they'd use it, if it were available.

However, the thread died out without any suggestions on how to do this.
I don't fully understand the warnings pragma, but as far as I can tell

1: use warnings; turns on all classes of warnings that warnings.pm holds,
   and is documented as doing exactly this

therefore

2: if we were to make named uninit a class of warnings, even if it were not
   turned on by -w, it would have to be turned on by use warnings; and in
   turn that could break existing code

so it seems that

3: we need another way of specifying that we'd like uninit warnings to be
   reported in the new format.

which sort of comes down to should the change be lexical, or global.
I'd actually be quite happy with global (so please suggest arguments
against this) as I'm assuming that this would only be used by main programs,
and existing test suites are main programs that don't turn this on.

(ie programmers would have to turn this on by themselves, so they'd be
aware that they needed to take precautions to ensure that their foot was
safely elsewhere before pulling this trigger, and any module writer who
turns this on for the rest of the program is as anti-social as anyone
modifying an existing global)

What do people think?

Nicholas Clark

On Mon 24 May 2004 18:19, Nicholas Clark <n...@ccl4.org> wrote:

I'm totally against breakage, but i've heared the calls for this feature also,
and I wouldn't mind going through my modules to update them to match either
warning, but than again, I don't have that many modules on CPAN.

If it were included, I'd build all the modules I usually include, and report
to the authors what fails.

So, I'm absolutely not against it, but we should be prepared to catch a lot of
complaints to p5p where they don't belong. Nicholas knows *_all_* about it :)

--
H.Merijn Brand        Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.3, & 5.9.x, and 809 on  HP-UX 10.20 & 11.00, 11i,
   AIX 4.3, SuSE 9.0, and Win2k.           http://www.cmve.net/~merijn/
http://archives.develooper.com/daily-bu...@perl.org/   perl...@perl.org
send smoke reports to: smokers-repo...@perl.org, QA: http://qa.perl.org

This also needs to be somethiong that makes it clear that it's a temporary
expedient for 5.8.x only and that it's on in 5.10.x automatically;

ie if we introduce the general public to (say)

    use warnings 'undef_var_names';

then in 5.10.0 they'll have to do this instead to maintain the status quo:

    no warnings 'undef_var_names';

which leads one to wonder whether the name needs to be more like:

    use warnings 'undef_var_names_in_58x_only';

which leads one to wonder whether there should be a more general
mechanism for early enabling of new features - then we could include
the // operator say; so maybe something like

    use feature qw(undef_var_names defined_or);

where it's clearly documented that at some point in a future release
a particular feature will become enabled by default.

Of course this runs into the lexical scoping of hints problem, which
I've never been sure whether its been fixed yet.

One final Cassanda-ism - the uninit warnings code is still bound
to tuen up some false positives - eg printing the wrong variable name.
These will gradually be ironed out over time, but it needs time...

Dave.

--
The warp engines start playing up a bit, but seem to sort themselves out
after a while without any intervention from boy genius Wesley Crusher.
    -- Things That Never Happen in "Star Trek" #17

Quoting Dave Mitchell <da...@iabyn.com>:

I'd rather have an option globally settable, non-intrusive,
forward-compatible; with a clear note, "this will be the default
in 5.10 and onwards". I think yet another environment variable
can do. PERL_5_10_ISH for example. Detailed warnings will be
wanted by developers, so they could set this variable while they
are debugging, and leave it off in production. The main
advantage of this approach is that it will not be necessary
to modify the code to get the detailed warnings.

And beta testing. I'm happy enough to have this not-the-default and
not-quite-obvious, as it will take some degree of clue to enable this
feature. It's probably better to have the moderately clueful trying this
out now, knowing that it may be wrong, and giving it more exposure, than
having the great unwashed hit it in a release 5.10.

The disadvantage of PERL_5_10_ISH is that we then have to invent PERL_5_12_ISH
and so on.

  use more 'future';

So some sort of name that isn't version specific but does suggest sneak
preview beta would be my (current) preferred choice.

Nicholas Clark

Quoting Nicholas Clark <n...@ccl4.org>:

In my mind, being version specific was a "feature" :
it will ease migration of a script from 5.8 to 5.10
without having unwanted side-effects it one forgot
to remove "use more 'future'". (*)

(*) or maybe "use more 'features'" :)

I like this.  This is the same mechanism the Python guys invented as
'from __future__ import ...' [1].  I even think we could spell it 'use
future qw/foo bar/'.

Even if I like this mechanism I'm not really sure I like it in
perl-5.8.  As time go by I think the 5.8 track should grow more and
more conservative.  It should not end up experimenting with new
features just because 5.10 fails to arrive.

Regards,
Gisle

[1] http://python.binarycompass.org/peps/pep-0236.html

There's a specific reason why I would like this new feature in a maintenance
release, independent of the timescale of 5.10. If 5.10 had shipped 12 months
ago I'd still want this:

Many organisations continue to run older versions of perl. For example, I
did some work for an organisation using 5.004_04 on its website servers.
The only sane way to develop for this target was to install and use 5.004_xx
on the development systems, rather than a later perl. The named
uninitialised variables are principally of use while developing (or
debugging), not while in production, hence saying "you need to upgrade to
5.10 to see this" is no use when your debugging system has to stay on 5.8.x
to closely emulate production.

(Sure your integration and staging systems have to stay on the identical
version to your production system, but your development system can have more
than one 5.8.x installed, and 5.8.5 to 5.8.3 is more likely to show the same
behaviour/long term bugs than 5.10.2 to 5.8.3)

Nicholas Clark