Front page | perl.perl5.porters |
Postings from October 2015
On 10/09/2015 06:08 AM, Abigail wrote: > On Fri, Oct 09, 2015 at 07:50:49AM -0400, Ricardo Signes wrote: >> * Karl Williamson <public@khwilliamson.com> [2015-10-08T10:58:23] >>> Currently it evaluates to the Unicode property 'Letter'. >>> >>> But I think that is the wrong thing to do. >>> >>> The pkg seems to me to want to force this into a user-defined property. >>> Recall that by defining a subroutine, a user can create their own >>> properties. The catch is that their names have to begin with 'In' or 'Is'. >>> Therefore, I think that this should be a compile- or run-time failure that >>> the property pkg::L is not found. >> >> I agree, but I wonder whether a "illegal name" wouldn't be better than "Can't >> find." The fix is for the user to rename their &L (if they made one) rather >> than to figure out why it can't be found. >> >> At any rate, acting like L is no good. > > > Is there actually a reason why user-defined properties must start > with 'In' or 'Is'? In 5.12, this requirement wasn't enforced, and > it "just worked". Considering there are predefined classes starting > with "In" and "Is", I can't imagine it's to prevent name clashes. I think there was a time when property names had to begin with 'In' and 'Is'. And perhaps this dates from then, and was never updated when the restriction was relaxed. In any event, I was really glad that these were the only legal names when we discovered a possible security hole. Dave Mitchell used this fact in his fix, but I don't remember the details. I would oppose relaxing the restriction, as there is now a better alternative that doesn't impose restrictions in doing logical operations on component properties, the regex sets feature: qr/(?[...])/. And I don't see the need to do work on a feature that has a better alternative. > > > > Abigail >Thread Previous | Thread Next