Martin Hosken <[EMAIL PROTECTED]> 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/
