> Hm. This makes it difficult to construct a header incrementally -- for
> example, @HEADERS=(); push @HEADERS, header(content_type=>'a',
> author=>'b'); # 75 lines later; push @HEADERS, header(last_modified=>'c',
> accept=>'d');
>
> Since in this case, there would be two "blank" head lines instead of just
> one.
Yeah, Ziggy already mentioned that offlist.
> > The C<header> function would simply:
> >
> > 1. uc the first letter of each tag token and lc the rest
>
> Du you want to use the word "ucfirst" here?
Probably; that's what the Text::Header module I wrote as a prototype
does. ;-)
> > Should result in C<@out> being exactly equivalent to C<@in>.
>
> It cannot, of course, since the order of hash keys obtained by flattening
> the hash is not necessarily the same as when you built the hash.
Actually, it does. Remember, a hash is just a list. unheader just
returns an ordered list of the headers. So this:
@out = header unheader @in;
Will always result in identity because it's actually the same as:
@temp = unheader @in;
@out = header @temp;
It's only once you assign to a hash explicitly that everything gets out
of whack.
-Nate
