Re: Re: Extra strict subs

[Elian]

Point 3 means that if I have to go and modify toke.c, perly.y, and various bits of gv.c (for example) to make this work reasonably well, thus making it work only for versions of perl with the mods (likely 5.8.1 and up) that's OK. I'd rather not have to, if for no other reason than to avoid messing around in toke.c, but...

Point 2 means that the pragma must be lexically scoped. It should only complain about uses of undefined subs in the blocks that it is in force for, so it doesn't complain about modules and whatnot that might otherwise trigger the warnings. Much of the perl library uses subs that only exist on particular platforms, with $^O conditional tests to make sure they don't get tripped over otherwise. We don't want to yell about those, nor modify the standard modules to be completely sub-safe.

[Abigail-II]

Modifying toke.c, and perly.y for a feature in a maintenance release? I sure hope Jarkko won't put that in. New development belongs in the development track - not the maintenance one.

And I'd expect strong opposition from p5p if this extra strictness gets turned on by use strict;.

Abigail

[Elian]

You need to read a bit more carefully before going all freaky, Abigail.

I said it wouldn't affect use strict, and it won't.

I also said I'd like it backwards-compatible if possible, which makes toke.c alterations one of the very last resorts--I don't particularly care to mess around in there if I don't have to. If I have to I will, though, at which case it's Jarkko's call on whether it goes in or not. It certainly wouldn't be the first, or the thousandth, feature to go into a maintenance release of perl.

[Louis_Wu]

Thanks. I hadn't thought about restricting the check to certain blocks, that makes sense. Not breaking CPAN is a Good Thing®.

About modifying the compiler (which is what I assume you meant, refering to toke.c, etc), when strict was originally introduced, were compiler mods needed?

BTW, what is the current behavior of strict in regard to nonexistant subs?

[Elian]

Strict came in with perl 5.000, so it's been there from the beginning. (Well, beginning of perl 5, at least) It does interact with the compiler, setting bits that get put in the flag bits of parts of the optree, and the compilation code does pay attention to it.

At the moment, strict doesn't care about nonexistant subs.