I vote for Convert::yEnc.
Arthur
On torsdag, nov 7, 2002, at 21:11 Europe/Stockholm, Philip Newton wrote:
On Thu, 7 Nov 2002 17:38:18 +0100, [EMAIL PROTECTED] (Perl
Authors Upload Server) wrote:
The yEnc format was developed for encoding usenet binaries, and
that is currently its most common use. This suggests a module name
of
News::yEnc.
An alternative would be to make yEnc:: a top-level name, like
MIME:: but... - yEnc isn't as big as MIME - The yEnc format will
likely stay confined to usenet
Also, a top-level yEnc:: module namespace violates CPAN
capitalization conventions, while a YEnc:: namespace is
unaesthetic.
I thought of Convert::yEnc when I had a go at fiddling with it (I think
there's still a module in my CPAN directory, but it's pretty
broken[*]).
First in with Convert::RACE, for example (for internationalised domain
names).
OTOH, a top-level yEnc:: namespace allows for both yEnc::Decoder
and yEnc::Encoder, when someone gets around to writing one.
Same with Convert::yEnc::Decoder and Convert::yEnc::Encoder, though
I'd've thought it'd make more sense to stick both into one module.
After
all, we have Compress::Zlib and not Compress::Zlib::Deflate and
Compress::Zlib::Inflate, and MIME::Base64 not ::Encode and ::Decode...
you get the idea.
If we
put them all under News::, then we either have 3-level names, like
News::yEnc::Decode News::yEnc::Encode
(a) I don't see why that's a problem
(b) I think Whatever::yEnc should be able to encode *and* decode
Cheers,
Philip
[*] The fact that it's a bit of a shambles -- I think it kind-of does
encoding but doesn't do decoding at all yet -- is why I didn't apply
for
namespace registration. In case someone else did a proper job, they
were
welcome to the namespace.
OTOH, if you want to use part or all of my code, you're also more than
welcome to do so.
