diff options
author | Karl Williamson <public@khwilliamson.com> | 2011-09-03 13:47:19 -0600 |
---|---|---|
committer | Karl Williamson <public@khwilliamson.com> | 2011-09-03 17:01:15 -0600 |
commit | 807807b755f89001385a00934f7e5fd6c42ec6ea (patch) | |
tree | 0e33fc2f02650b21e1c79134f898558b49664e3a /lib/Unicode | |
parent | 046cc26cf77f76bc63fd4d206fef560054f5d298 (diff) | |
download | perl-807807b755f89001385a00934f7e5fd6c42ec6ea.tar.gz |
mktables: make_Heavy.pl smaller
During the time that mktables was being heavily revamped, Unicode
proposed a number of new properties whose names began with 'Is'. Perl
since 5.6 has alllowed properties to have an optional 'Is' prefix. Thus
there was the possibility that a new property name from Unicode would
conflict with one of Perl's name extensions. Thus, the code was written
to individually suppress such an extension when there was a conflict;
though this would be an undesirable state of affairs, where previously
working code would have to be changed due to a new Unicode release.
However, it turns out that other Unicode implementors had done the same
thing Perl had done, and the protests forced the new Unicode standard to
remove the 'Is' from the new properties; and apparently they won't try
to do this again.
However, the more general case code was still in mktables, doing no
harm, except enlarging significantly several of the hashes in Heavy.pl
to have essentially double the entries; one for the 'Is', and one
without. There have been some murmurings that Heavy.pl takes up too
much memory. Further, future commits are planned that would take up
space as well, and that could be made much smaller by not having the
individual basis for having Is/non-Is.
So, this commit takes away the individual property Is/non-Is and
replaces it with a blanket approach that has it for all Unicode
properties. This requires a single extra statement in utf8_heavy.
This has already been added mistakenly, but harmlessly, in commit
45376db692c38e06f27b8331d036652ec5fbb3d1
Note that perl extensions still have the individual Is/non-Is. This is
because the blanket approach won't work for them, as some of the 'Is'
synonyms do routinely get approaced in the case of the Block property.
It is documented that one shouldn't use the 'Is' prefix for the Block
property, because future Unicode versions could break your code.
Diffstat (limited to 'lib/Unicode')
0 files changed, 0 insertions, 0 deletions