Martin Hosken <Martin_Hosken(_at_)sil(_dot_)org> writes:
Dear Jarkko,
I would like to think that Perl 5.8 is going to deliver the Unicode
promise for Perl.
Well for that it would need to be able to do normalisation and Unicode
based sorting as well. But hey, this is comming together nicely.
I have not had a chance to really hammer this thing, but some comments on
the really nice Encoding stuff:
1. Any chance of exposing the powerful Encoding::XS stuff so that other
mappings can use it from binary config files?
That has always been the plan. It is exposed at XS level, and
ext/Encode/compile script can write Foo.xs given a .enc or .ucm file so
that one can add new compiled encodings.
What is less clear is how best to write "binary" files without
using C compiler to build the data structures. The issues being endian
and pointer size related - it would be nice if the binary encodings
could be shared between architectures.
This is really just a tuit shortage problem
2. It looks to me like Encoding::Tcl is re-reading the .enc file every time
one calls encode() or decode().
It may look like it, but it isn't ;-) (or doesn't for me - there is a left
over carp which shows me it isn't).
What happens is that initialy the object is an Encoding::Tcl so 1st time
you call ->encode it calls Encode::Tcl::encode which does ->loadEncoding.
BUT loadEncoding re-blesses the object so that subsequent calls to ->encode
call (say) Encode::Tcl::Table::encode directly.
Any chance of caching the
Encoding::Tcl::Table (perhaps replacing the Encoding::Tcl object with it)
instead?
It does (or should).
Counter example welcome.
--
Nick Ing-Simmons
who is looking for a new job see http://www.ni-s.u-net.com/
