Dan Kogai <[EMAIL PROTECTED]> writes:
>On Wednesday, Oct 9, 2002, at 16:15 Asia/Tokyo, Nick Ing-Simmons wrote:
>> But given that Encode::MIME::Header exists and is "cluttering up" my
>> machine's memory it is a pity it does not do a _little_ more.
>
>
>Patches welcome -- so long as it passes ext/Encode/t/mime.t (which test
>strings I shamelessly copied and pasted from very RFC except for a very
>longish Japanese).
Right ho.
>
>As I said, the problem is encode()ing since decode()ing is fine already
>(tell me if it is not so).
Decoding is fine. Indeed I recently replaced my version with Encode::MIME::Header
because yours did a better job. The only thing I might add to decode
is to allow the closing ?= to be missing (which seems to be a common
non-compliance in some of SPAM I get). But as it is SPAM I don't really
care.
>To allow more granular control you need to
>feed more args but that breaks the API.... wait! the Encoding thingy
>under the food is just a blessed hashref we boldly call an object!
It _is_ an object. :encoding knows it is an object and uses it that way.
I think the object API should be documented.
One reason for making it an object is to allow derived classes and extra
hooks.
>Counter-intuitive it may be, you can pass extra 'tips' to that thingy
>like....
>
> my $e = find_encoding('MIME-Header');
> $e->{charset} = ISO-8859-1; # or $e->charset('ISO-8859-1') if we
>define a method
> my $encoded = $e->encode($str); # now uses =?ISO-8859-1?B?...
Despite Nick C's speed comments it may make sense to allow optional args
to encode as well.
--
Nick Ing-Simmons
http://www.ni-s.u-net.com/
