Dan san, > a) if it uses 'Encode' as module name it needs to work both in 5.8 > and 5.6.1. Bottom line is that backported version will not breach > what it is now. If it ain't broke, don't fix it (and 5.6.1 was > broke Unicode-wise) b) if you just implemented Encode functionality > in perl 5.6.1 but incompatible w/ 5.8, give it a different name; > i.e) Encode::Compat
Incidentally I have just finished a skeleton of Encode::compat, named
after Apache::compat (lower case) since it's a 'pragma' for Encode
usage, instead of a subcomponent of Encode.
It is available on CPAN, or at:
http://www.autrijus.org/Encode-compat-0.01.tar.gz
All it does is translate whatever call it receives into Text::Iconv, or
(in the future) Unicode::MapUTF8 to perform the actual work.
The is_utf8(), _utf8_on() and _utf8_off() calls are performed by the
method native to the perl version -- 5.6.1 would use pack/unpack, 5.6.0
uses tr//CU, etc.
The usage is:
use Encode::compat; # a no-op for Perl v5.7.1+ use Encode qw(...);
# all constants and imports works transparently
# use Encode functions as normal
For now it only support perl v5.6.1, and merely provides the three
utility function above (encode(), decode() and from_to()), with a very
kludgy FB_HTMLCREF fallback against 'latin-1' in from_to.
Theoretically, it could be backported to 5.005 and earlier, with none of
the unicode-related semantics available, and serves only as a
abstraction layer above Text::Iconv, Unicode::MapUTF8 and possibly other
transcoding modules.
My own aim was to deploy applications that can work across Perl versions
with the same interface; what do you, and other people on -unicode, feel
about such an attempt?
Thanks,
/Autrijus/
msg01463/pgp00000.pgp
Description: PGP signature
