> -----Original Message-----
> From: Stas Bekman [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, October 04, 2001 5:18 AM
> To: modperl-2.0 dev-list
> Subject: why header_(in|out) are deprecated in 2.x?
> 
> 
> I know that gozer has implemented the deprecated 
> header_(in|out), but why
> do we deprecate the two? reducing the number of ways to do 
> the same thing?
> 
> In any case the documented new syntax for:
>  $r->header_out(foo => 'bar'),
> now should be:
>  $r->headers_out->{foo} = 'bar';
> right?

personally, I think the Apache::Table interface is one of the coolest things
about mod_perl, which is why I latch on to these :)  the other thing is that
after writing the book and finding myself having to explain the idioms of
the API, things like this began to bother me.  so, if you are interested in
my $0.02 and don't mind some rather opinionated discourse, read on.  please
keep in mind that I'm trying to be constructive here and not come down on
anything/anyone :)

ok, in 1.3 you get

$r->header_out(foo => 'bar');
$r->headers_out(foo => 'bar');
$r->headers_out->set(foo => 'bar');
$r->headers_out->{foo} = 'bar';  #apparently - never used it.

the first issue is that headers_out is the name of the table in the
request_rec, not header_out.  the parallel is an important aspect of the
method I think - a person ought to be able to access the request_rec using
$r and the name of the field they want to access.  you probably don't need
or want two methods that go to the same place in the request_rec.

next, there is the style of the whole bunch.  to me, $r->headers_out->{foo}
looks like something you should never do - I consider headers_out() to be a
method that returns an object.  while the underlying object may be
implemented as a hash, it seems wrong to access its data directly (in
principle, at least).  fun and convenient, though.

$r->header_out() is kinda the same thing for me - it removes the object-ness
of the call.  you can never get the Apache::Table object from header_out(),
so you can't use its properties (like getting an array or iterating through
the headers with do()).  

it may be confusions over issues like these that make mod_perl a harder sell
(although it produces better and more understanding Perl programmers): if
you were to deprecate the non-Apache::Table interface, you might get more
people understanding Apache tables, and then more developers quickly seeing
how the table interface can be used across all the other methods
(subprocess_env, notes, etc) which is what makes mod_perl powerful.
dir_config->set is a favorite of mine and I've used it more than once, but
it isn't obvious with dir_config('foo') in all the examples (which is
convenient but not illustrative of what is really going on).  I'm not saying
we ought to get rid of dir_config('foo'), but at least you can get an
Apache::Table object back - with header_out() you can't.

as mod_perl goes into 2.0, which is already considerably different and makes
many old programs un-portable anyway, now is the time you can think about
the style, features, and idioms of the language - sculpting the "official"
API based upon 5+ years of experience with it...

anyway, now that I'm through playing the opinionated tag-along, y'all can
tell me to keep quiet...

--Geoff




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to