Part of the point, surely, is that we don't (want to) know what is
inside $c/$c->request (or any other Catalyst structure). The "direct
hash" could easily be a tied something-or-other inside, as is the case
with CGI when you use the Vars accessor. So just because it looks like a
direct hash, you can't from the outside assume it is more efficient. In
CGI, for example, the tied hash accessors (if you use Vars) are defined
in terms of the param method, so this mechanism is actually less
efficient than using param calls directly.
The point is: we can't/I wouldn't make assumptions about efficiency
based on the appearance of code, at least not in a language like Perl
where there can be so much magic behind the calling conventions.
If there is a recommended way of doing this, I'd certainly want to know
it. And it would probably help if that was efficient, but so long as it
doesn't leak or expose internal hackery, it shouldn't really matter. And
if it does, then it should probably be deprecated or documented so we
can avoid problems.
Perhaps it would have been better if the internal hash keys had been the
usual private-style "_parameters", etc., as that way everyone would know
direct access as a no-no, because the accessors would work but not the
direct access.
--S
--
Stuart Watt
ARM Product Developer
Information Balance
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
