This is an omnibus response to those who've commented on RFC17 (v1). The version I'm about to submit to the librarian is now available as html at <https://www.nnaf.net/~scs/Perl6/RFC17.html>. General note -- please look over the abstract. Some folks have made really good suggestions to change things which are (IMHO) outside of the scope of this effort. RFC focuses on a suggestion to the developers that a naming scheme be adopted which is more mnemonic and which makes it immediately visible which variables are related. Ted Ashton <[EMAIL PROTECTED]> kindly provided the formal objection to: > An at least %800 increase in the characters used to make up these names. > For quick hacks, this is a pain and from my experience with English.pm, > I had to spend just as much time looking up which word I have to use as > I ever did looking up which punctuation. Not to disagree with Teds claim of what he spends his time on, but *this* programmer is far less likely to turn to the manual when he sees $WARNING = 0; than when he sees $^W = 0; And $^W is one of the more mnemonic ones (shudder). But regardless of *my* opinion, his comments are now incorporated into the about-to-be submitted new version of the RFC. "J. David Blackstone" <[EMAIL PROTECTED]> wrote: > ...Larry implied that there might not be much left when all these > variables are cleaned up... Yes. Renaming is only proposed for what's left. If not much is left, that's a Good Thing. > I suggest that the most productive thing to do right now is go > through the special variables manpage and make a list of how the > *feature* provided by each variable should be re-implemented to > avoid action-at-a-distance problems. Any volunteers? I'm of two minds on this. On one hand, it would be useful for us to set some sort of direction for the language developers to follow. On the other, they're the ones who are going to have to decide what lives and dies, and how the remaining ones should be grouped. IMHO the proposal as it stands describes the policy sufficiently; the the developers are the ones Bart Lateur <[EMAIL PROTECTED]> asks responsed to a suggestion by David Blackstone: > > As another example, at work we are in love with the $/ variable, > > since we often deal in multi-line records delimited with control-Y's. > > However, changing this variable affects _everything_, meaning modules > > you want to use might not work unless you only modify $/ with local() > > within a subroutine. The solution is for the concept of $/ to become > > a per-filehandle value, as in, encapsulation and object-orientation. > I have only one problem with this solution, and that is with the <> > magic file handle. Would it's private $/ stick across files? Well, er, > yes... This RFC is on the reorganization and potential renaming of these variables, not on changing their function. IMHO this suggestion (while interesting) belongs elsewhere. It's a suggestion on modifying the scope of modified settings in perl. Each of those needs to be discussed in some topic relative to the feature which is modified by the variable, not in their renaming and potential removal. Tom Christiansen <[EMAIL PROTECTED]> writes: > If we were selecting dubious features to shoot (and I think we are), > then the fact that $^F and $^F are the same is one I'd kill--by zapping > the latter, too. Again, grist for the mill for the folks who work on those particular features. William Setzer <[EMAIL PROTECTED]> made a comment on loss of distinctiveness which I have taken almost in its entirety into the new document. Mark-Jason Dominus <[EMAIL PROTECTED]> kicked off an excellent discussion on the general wisdom of having these variables at all. I tend to agree with his core points, and have added a small section on the topic to the RFC. It concludes with ``Notwithstanding, should the core team continue to allow global variables for these purposes, the names and categorization should be improved.'' Many thanks to all.
