Front page | perl.perl5.porters |
Postings from August 2017
Father Chrysostomos wrote: >I do not quite understand the logic for reversing the flag here: It's to follow the reversed state of the existing use of that flag. The original call checkers, from the pre-_flags days, only understand namegv being a GV. When the flag was introduced, one would normally expect the flag being on to indicate that the caller understands the new possibility, for namegv to be something else. But instead the flag was introduced in the opposite sense, where the flag being on indicates a caller that doesn't understand the new possibility. I can see why it was done. (At least I think I can; it was done by you, so maybe you can say better.) As you say, any caller new enough to know about the _flags API is new enough to know about the new freedom for namegv. And more than that, any new call checker ought to be written to be called in the new way. So the flag state specified through direct use of the _flags APIs should almost always indicate accepting the greater latitude of namegv. It would be a hassle if one always had to explicitly set a flag bit to indicate that. More convenient to invert the flag's sense and have the recommended flags parameter value be zero. Calls with the bit set then arise mainly from using the pre-_flags APIs. >indicate that future flags will also be in reverse? No. This trick can only be applied to flags that exist in the very first version of the _flags API. (It's also only good for flags that it's recommended to nearly always have in the opposite state from the pre-_flags API.) Future flags will have to be in the sense where the bit being set indicates a deviation from the meaning of the first version of the _flags API (and so a further deviation from the pre-_flags arrangement). -zeframThread Previous | Thread Next