* Nathan Wiger ([EMAIL PROTECTED]) [28 Sep 2000 05:33]:
> Philip Newton wrote:
> > > Is order important for @HEADERS? Would it be better to have
> > > %HEADERS instead that does such auto-formatting?
> >
> > In my opinion, no, for the reasons given before. Hashes are
> > unordered, and if you want to order the keys, you need to know the
> > possibly keys and in which order they come. Then, if HTTP/4.2 comes
> > out with the Toast: light|medium|dark header, which has to come
> > after the new Breakfast: header
> Wait, you're both right! ;-)
More or less, yeah =)
> Personally, I'd like to see a simple version of CGI::header be
> embedded in core. HTTP-type headers are widely used in many
> applications. So you could have:
> @HEADERS = header(content-type => 'text/html',
> toast => 'medium', # not too crispy
> breakfast => 'yes');
> Under normal life, @HEADERS would just be some variable. But the "use
> cgi" pragma could simply flush @HEADERS out ahead of time before your
[insert "STDOUT"]
> output stream. If @HEADERS is empty, the "use cgi" pragma just prints
> out "Content-type: text/html\n\n";
Personally speaking, I'd prefer a headers object. Just so that things
could be extended more easily in the future (in case headers ever need
to get slightly more complicated than a simple order array). (Plus it
means things could be slightly more easily kept track of in the
implementation: it's quite probable that you won't want duplicate keys
in the array and this is best served by having a hash behind the scenes
(possibly with an ordered array of keys) but you can probably see where
I'm aiming at now? Extensibility.)
[...]
> Ziggy, are you interested in this idea enough (at all?) to stick a
> note about the 'header' function into the RFC? Or should I RFC it
> separately?
I'd say RFC it separately.
cheers,
--
iain truskett, aka Koschei. <http://eh.org/~koschei/>
The book to read is not the one which thinks for you, but the one
which makes you think. James McCosh
