[Catalyst] Alternatives to Catalyst ?

[J. Shirley]

On Mon, Apr 26, 2010 at 1:51 PM, Zbigniew Lukasiak <zzbbyy at gmail.com> wrote:
> On Mon, Apr 26, 2010 at 1:26 PM, Ben van Staveren
> <benvanstaveren at gmail.com> wrote:
>>
>> Because if you are working with, say, 10 people on a team, and you will have
>> everyone merrily doing direct hash accesses, sooner or later, someone's
>> going to fuck it up and something will break in a spectacular > fashion.
>>
>>
>> I take your point even though I am not in a team.
>>
>>
>>
>> Even if you're not, direct hash accessing is basically akin to juggling
>> grenades. It might go right for a long time, but eventually the pin's going
>> to come out and there will be a very messy BLAM.
>>
>> Even if it is code you just write for yourself, still doesn't hurt to make
>> sure you avoid the BLAM bit :)
>
> If using  ->params->{name} (i.e. the direct hash approach) is like
> juggling grenades - then what is like using the ->param( 'name' ) way
> of doing it?
> I am asking this because your grenades analogy gives the impression
> that you you are against doing direct hash access for every price -
> but I think the general advice is that in this particular case using
> the ->param( 'name' ) is worse than using the direct hash access.
>
>

I believe the discussion is about $c->req->{parameters}->{name}, not
about using ->params->{name}, isn't it?

Analogies to grenades, gas pumps and whatever else are just silly.  We
all understand software development sufficiently well enough to simply
talk at the matter at hand.

Violating encapsulation in a local, protected scope for purposes of
efficiency is ok.
Violating encapsulation on a global scope is not, for a variety of
reasons, the most obvious of which is you have no contract for data
access.

I don't believe that $c->req->params violates any ideas, since the
parameters is nothing more than a hashref.  How you get that hashref,
though, is a binding contract to the request.  Calling
$c->req->{params} is an evil, naughty thing.

-J