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/
pgpbqp5DAAAbu.pgp
Description: PGP signature
