> > 50% of statically linked perl consists of Encode!
>
> Side note: I still think, Encode should have used the encoding tables
> that are already provided by the operating system where available. For
In an ideal world, yes, maybe. When the same tables would be
available for all (well, 90% is good enough) platforms Perl runs on,
then, maybe.
> example on Linux, the iconv() function with glibc 2.2 or newer does
> already provide access to all the necessary tables. I observe at the
> moment, that almost a dozen different programming language communities
> reinvent the recoding wheel simultaneously and independently, even
This is true, sad, but I think still unavoidable at this point in
time. In five years I would expect something to be widely accepted
and used, such as libiconv (which does look really promising). But it
is not enough for Perl's Unicode/encoding support to work in Linux and
Solaris only... just as a reminder, here is the list of "common"
(read as: at least somewhat actively supported) Perl platforms:
AIX AmigaOS BeOS Darwin DG/UX DOS DJGPP DYNIX/ptx
EPOC R5 FreeBSD HP-UX IRIX Linux MachTen MacOS Classic
NonStop-UX ReliantUNIX OpenBSD OpenVMS OS/2 OS X QNX
Solaris Tru64 UNIX UNICOS UNICOS/mk VOS Win32/NT/2K
(and there's about the same number of less common ones)
When libiconv works (so that Perl could can just include it) and/or
comes standard with the majority of the above, then we can consider
it. Saying: "oh, your platform does not support encoding
transformations because you do not have glibc 2.2" is not an option.
> though portable C libraries such as libiconv are already available for
> exactly the same purpose.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
