Re: [Catalyst] Re: Alternatives to Catalyst ?
On Mon, Apr 26, 2010 at 11:59 PM, Aristotle Pagaltzis pagalt...@gmx.de wrote:
* Zbigniew Lukasiak zzb...@gmail.com [2010-04-26 12:25]:
This is a fine advice - but unfortunately the -param method
call suffers from additional problem - which is described in
much detail in the documentation (go to the NOTE at:
http://search.cpan.org/~bobtfish/Catalyst-Runtime-5.80022/lib/Catalyst/Request.pm#$req-%3Eparam).
Yeah, but the -params hash has the converse problem: if you
write
$c-model-insert_person( name = $c-req-params-{'name'} )
then you may be surprised to find out there are people with name
like ARRAY(0xDEADBEEF). Of course that’s just a relatively minor
case of data corruption. Worse is if you legitimately expect
a parameter to have one or more values, eg. a pile of checkboxes.
Then you have to constantly check whether you’re getting a scalar
or an array reference.
So either you use the legacy method and have to protect against
getting more values than you wanted, or you use the suggested
method and have to protect against getting fewer values than you
expect in the general case.
I briefly tried to write something to stick Hash::MultiValue into
Catalyst to end the madness, but doing it properly would require
a plugin, plus HTTP::BodyParser (I think) was using a misdesigned
approach that made deep integration of H::MV impossible (with
properly preserved k/v pair order).
Could have written a Request role… but that seemed unsatisfying.
I wonder whether it would be possible to rip out the respective
bits from Cat and use just H::MV, and leave the current stuff to
a compat plugin or something like that…
Not a very concrete answer - but I remember that Miyagawa talked about
fixing that in Plack::Request (and I am not sure but I think it also
involved H::MV) - so there might be some occasion for reuse :)
Cheers,
Z.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Suggestions for iPhone version of app
On 26 Apr 2010, at 16:27, Steve Nolte wrote: HTTP::BrowserDetect gives you the detection, and you could setup a separate view for those templates with a fallback to the previous templates. You configure the secondary view with multiple paths (INCLUDE_PATH), so you can override any template (just by it existing in the first dir). Nice, I like this route. It looks like I can just put that detection logic in the default end() action, pretty simple. I'd recommend putting it in the request object via a trait. http://search.cpan.org/dist/Catalyst-TraitFor-Request-BrowserDetect/ should already do most or all of what you're looking for (and patches are welcome!). Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
On 26 Apr 2010, at 10:36, Dermot wrote: Obviously I'd rather use the faster method but if I'm breaking the encapsulation in some ways that's going to bite me later, I'd steer clear. Premature optimisation is the root of all evil. I really really wouldn't be worrying about method call overhead vs direct hash access until: 1) Your confident your code is using the correct algorithms (i.e. you can bogosort a lot faster with direct access than methods - that doesn't meant you're not still doing a bogosort!) 2) Optimising things that profile as slow in YOUR APPLICATION. The speedup (in developer time) you get from using the highest level interface / abstraction appropriate ALWAYS buys you enough extra time to have a round of optimisation once your code works, and fixing the _actual_ pain points is likely to give you many more gains than writing your code you in a way you think (due to trivial synthetic benchmarks) will be faster, but that takes longer. It should be noted that Catalyst _SPED UP_ (on perl 5.10) when it was ported to Moose. Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Pre-Moose version of Catalyst and all plugins?
On 26 Apr 2010, at 21:09, Kee Hinckley wrote:
I'm trying to get some old code running in a hurry. Unfortunately
Moose has completely fouled things up.First it broke my use of
Error.pm (conflict with with).
Erm, that'll only break things if you import the Moose helper
functions into the same package as you try with Error.pm.
You don't have to have a 'use Moose' in your package to use new
Catalyst - so everything should just work (i.e. I don't see why you're
crashing into this unless you're changing your application).
If you do want/need this to work, then just do something like this:
package Foo;
use Moose;
# Moose attribute and role declearations here
no Moose;
use Error :try; # Or whatever you're doing
# Put your methods here
Fortunately I didn't use with, and could just comment it out. But
what I did have was my own Error subclass that was the Catalyst
Exception class.
BEGIN {
$Catalyst::Exception::CATALYST_EXCEPTION_CLASS = 'Error::Throws';
};
I have no idea how to even get started on making that work. I made
Error a Moose inherited module from Catalyst::Exception (which is
the wrong level, but it got rid of:
Not inlining 'new' for Catalyst::Exception since it is not
inheriting the default Moose::Object::new
If you are certain you don't need to inline your constructor,
specify inline_constructor = 0 in your call to Catalyst::Exception-
meta-make_immutable
Erm, this is a warning and shouldn't cause any issues.
But then that left me with
Recursive inheritance detected while looking for method 'isa' in
package 'Catalyst::Exception' at /usr/local/lib/perl/5.8.8/Class/MOP/
Class.pm line 570.
If someone has a quick way of telling me how to make my code
compatible with Catalyst::Exception that would be great, but I'm
worried that I'm going to hit lots of other things like this.
More recent Catalyst releases have changed the way exceptions are
handled to be more compatible with people overriding things, however
as you haven't really given us any details (like what your
'Error::Throws' class actually is / what it contains), or what the
error actually is if you try and use it unmodified - so I can't really
speculate..
In particular, I'm also using Embperl as a Catalyst interpreter
instead of TT,
Erm, you means as the view? Surely perl is the interpreter here
Any suggestion on a solution that isn't going to take me days?
Yes, give us some actual details about the issue you have :)
FWIW, most people's applications run entirely unmodified with Catalyst
5.80, and I'd very much guess that exception handling is likely to be
the only major issue you have...
The above proves that you're changing your app before actually just
trying to get it running - which is causing you more problems than
it's solving!
Cheers
t0m
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] Oddness with Catalyst::Plugin::Session::Store::DBIC
Hi folks, Recently after upgrading all of Catalyst, I'm witnessing some weird behaviour in some apps. I'm using Catalyst::Plugin::Session::Store::DBIC to store my sessions, and when I have DBIC_TRACE going, I see this: BEGIN WORK SELECT me.id, me.session_data, me.expires FROM session me WHERE ( me.id = ? ): 'session:fe3baeddb6ec2d3a14b07651a8792c7b85df9722' COMMIT UPDATE session SET expires = ? WHERE ( id = ? ): '1272443848', 'session:fe3baeddb6ec2d3a14b07651a8792c7b85df9722 Not once per request, but up to 50 times in a single request. Is this something wrong in my code or is C::P::S::S::DBIC going nuts? -- Ben van Staveren phone: +62 81 70777529 email: benvanstave...@gmail.com ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
RE: [Catalyst] Alternatives to Catalyst ?
I'm running out of popcorn now so here's a quick summary of my observations
WRT getting request parameters:
- If a simple question about something so fundamental to what Catalyst is
for (i.e. Dermot's question, not Oleg's) can generate so much debate then
something's not right somewhere. Hopefully, in the docs.
- Three methods of getting CGI parameters have been mentioned:
- $c-req-{parameters}-{name}
Undocumented, dangerous, used only by lunatics and trolls.
- $c-req-param(name)
Documented legacy interface, deprecated (but unfortunately the only
one mentioned in Catalyst/Manual/Intro.pod#Query_Parameter_Processing).
- $c-req-param[eter]s-{name}
The correct encapsulation - use this.
- CS101: premature optimisation is the root of much evil but OTOH it's a
good idea to be in the habit of using optimal methods when there's a choice
not dictated by other factors. But that's not actually relevant here.
- It's nice to answer people's questions without making assumptions about
their context. OTOH additional advice which turns out to be irrelevant is
free so we shouldn't scorn it. OTOH it can be off-putting to people trying
find their way through the information overload as they start using a new
system as complex as Catalyst. OTOH complaining about it just causes bad
feeling so we shouldn't do that. OTOH complaining about complaints is no
different from complaining about anything else. OTOH this loop has no exit
condition. break;
So I had a quick look at the docs (for the first time in many years - I
found them at http://search.cpan.org/~hkclark/Catalyst-Manual/) to see if I
could see what this is all about. The answer to Dermot's question is there
but it it's a bit obscured by the CGI.pm combatability aspect - that was
very important at the start of Catalyst's life (because most users would be
coming from there) but probably isn't so much any more. In particular, as
mentioned above, Catalyst/Manual/Intro.pod#Query_Parameter_Processing really
only talks about the req-param() interface. I propose that all references
to the req-param() interface should be replaced by references to the
$c-req-parameters-{} interface except where explicit discussions of
CGI.pm compatability are appropriate, which would only be very briefly in
the case of the Intro. I'm afraid I don't know how to do this but if someone
sends me a pointer to instructions I'll have a go at making a doc patch or
whatever's appropriate.
Merlyn
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
2010/4/27 J. Shirley jshir...@gmail.com:
On Mon, Apr 26, 2010 at 1:51 PM, Zbigniew Lukasiak zzb...@gmail.com wrote:
On Mon, Apr 26, 2010 at 1:26 PM, Ben van Staveren
benvanstave...@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.
Why can't nobody understand, the question is not why someone should
use $c-req-{params}. Of course that is an evil. Problem is that if
i could get -{parameters}{name} at a speed 100x there can't be no
reason for -params to work as a turtle and i see a good reason to use
wrappers around Request to provide normal, fast method of acessing
parameters. Use Class::XSAccessor, Fast::XS, i dont now, use
something!!! Many people ask me why most of catalyst accessors working
so slow ? i dunno what to answer except for writing our own wrapper
accessors getting values directly with massive speedup.
-J
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
Merlyn Kline wrote:
So I had a quick look at the docs (for the first time in many years - I
found them at http://search.cpan.org/~hkclark/Catalyst-Manual/) to see if I
could see what this is all about. The answer to Dermot's question is there
but it it's a bit obscured by the CGI.pm combatability aspect - that was
very important at the start of Catalyst's life (because most users would be
coming from there) but probably isn't so much any more. In particular, as
mentioned above, Catalyst/Manual/Intro.pod#Query_Parameter_Processing really
only talks about the req-param() interface. I propose that all references
to the req-param() interface should be replaced by references to the
$c-req-parameters-{} interface except where explicit discussions of
CGI.pm compatability are appropriate, which would only be very briefly in
the case of the Intro.
+1 Agree.
I'm afraid I don't know how to do this but if someone
sends me a pointer to instructions I'll have a go at making a doc patch or
whatever's appropriate.
Well volunteered! Check out:
http://dev.catalyst.perl.org/repos/Catalyst/Catalyst-Manual/5.80/trunk/
And either make changes and stick a diff in the RT queue, or stop by
#catalyst-dev on irc and ask for a commit-bit to commit your changes
yourself :)
Cheers
t0m
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Oddness with Catalyst::Plugin::Session::Store::DBIC
I had the same problem. I boiled it down to Static::Simple. Each request to a static resource issued a session update. In a recent release of cat the handling of requests seemed to have changed. Try downgrading to 5.80018 which fixed it for me (which is not a good solution, but I have no time right know to fix it in catalyst or write a test). On Tue, 27 Apr 2010 15:42:21 +0700, Ben van Staveren benvanstave...@gmail.com wrote: Hi folks, Recently after upgrading all of Catalyst, I'm witnessing some weird behaviour in some apps. I'm using Catalyst::Plugin::Session::Store::DBIC to store my sessions, and when I have DBIC_TRACE going, I see this: BEGIN WORK SELECT me.id, me.session_data, me.expires FROM session me WHERE ( me.id = ? ): 'session:fe3baeddb6ec2d3a14b07651a8792c7b85df9722' COMMIT UPDATE session SET expires = ? WHERE ( id = ? ): '1272443848', 'session:fe3baeddb6ec2d3a14b07651a8792c7b85df9722 Not once per request, but up to 50 times in a single request. Is this something wrong in my code or is C::P::S::S::DBIC going nuts? ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: Alternatives to Catalyst ?
* Zbigniew Lukasiak zzb...@gmail.com [2010-04-27 09:20]: Not a very concrete answer - but I remember that Miyagawa talked about fixing that in Plack::Request (and I am not sure but I think it also involved H::MV) - so there might be some occasion for reuse :) Yeah, that’s exactly what he wrote H::MV for. I chimed in a bit, and the way its internal storage works now fell out of a back forth between the two of us, designed for the typical use case in web apps – it’s optimised for initialisation speed at the expense of query speed, because you typically only ask for param values once anyway, and the initialisation cost is incurred for every request no matter how little of its effort you exploit. (So people who randomly microbenchmark querying, like the thread starter, will be unhappy about that… just goes to show the fallacy of doing that.) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Oddness with Catalyst::Plugin::Session::Store::DBIC
Hi Moritz, Yeah I just figured that one out - but that's new, never saw it do this before to be honest - it's not a big deal actually since in production Static::Simple isn't used and I let lighttpd take care of serving static files, but in testing it's a bit disconcerting to see it crop up all of a sudden :) Thanks! :D Moritz Onken wrote: I had the same problem. I boiled it down to Static::Simple. Each request to a static resource issued a session update. In a recent release of cat the handling of requests seemed to have changed. Try downgrading to 5.80018 which fixed it for me (which is not a good solution, but I have no time right know to fix it in catalyst or write a test). On Tue, 27 Apr 2010 15:42:21 +0700, Ben van Staveren benvanstave...@gmail.com wrote: Hi folks, Recently after upgrading all of Catalyst, I'm witnessing some weird behaviour in some apps. I'm using Catalyst::Plugin::Session::Store::DBIC to store my sessions, and when I have DBIC_TRACE going, I see this: BEGIN WORK SELECT me.id, me.session_data, me.expires FROM session me WHERE ( me.id = ? ): 'session:fe3baeddb6ec2d3a14b07651a8792c7b85df9722' COMMIT UPDATE session SET expires = ? WHERE ( id = ? ): '1272443848', 'session:fe3baeddb6ec2d3a14b07651a8792c7b85df9722 Not once per request, but up to 50 times in a single request. Is this something wrong in my code or is C::P::S::S::DBIC going nuts? ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ -- Ben van Staveren phone: +62 81 70777529 email: benvanstave...@gmail.com ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
Merlyn Kline wrote:
I propose that all references
to the req-param() interface should be replaced by references to the
$c-req-parameters-{} interface except where explicit discussions
of CGI.pm compatability are appropriate, which would only be very
briefly in the case of the Intro.
It's not just useful for new users reading the intro with a CGI.pm
background.
There are other useful modules on CPAN that will process incoming request
parameters, that have been designed to expect a CGI object that they can
call param on. When using those modules with Cat it's handy to be able to
pass the Cat Request object over to make them work the same.
Carl
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] unsubsricbe
___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
Dermot wrote: Why wouldn't you, as you write, use the the fastest access methods available? Surely you'd want to develop habits that will a) provide better performance and b) as mentioned below avoid the thorny side-effects of req-params(). This isn't a matter of premature optimisation but simply establishing good practise. Answering this in the general case. If you know that the object is stored as a hash, yes you can access it like a hash - but that's your risk. When you upgrade your modules and it switches to being stored some other way - you get to fix all your code. That's one of the things that many perl coders like - to the degree that it's perl culture - you *can* poke inside the box if you want but you have to accept the risks that go with that. As far as other optimisations, yes it's nice to develop some good habits but you don't want that to be at the expense of maintainability. Even if you're a team of one - you will still have to come back and maintain your own code at some future time. I have plenty of code that I wrote and understood very well at the time, but is a confusing mess now! So if an optimisation doesn't impact maintenance too much it's worth turning into a habit. eg print with a list rather than using concatination Carl ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
On 27 April 2010 12:09, Carl Johnstone catal...@fadetoblack.me.uk wrote:
Dermot wrote:
Why wouldn't you, as you write, use the the fastest access methods
available? Surely you'd want to develop habits that will a) provide
better performance and b) as mentioned below avoid the thorny
side-effects of req-params(). This isn't a matter of premature
optimisation but simply establishing good practise.
Answering this in the general case.
If you know that the object is stored as a hash, yes you can access it like
a hash - but that's your risk. When you upgrade your modules and it switches
to being stored some other way - you get to fix all your code. That's one of
the things that many perl coders like - to the degree that it's perl
culture - you *can* poke inside the box if you want but you have to accept
the risks that go with that.
[meh] I was really trying to avoid coming back into this thread but I
feel I have to make clear what I was asking. There is this assumption
that I *wanted* to break encapsulation. That wasn't the case. I
started from J.Shirely's point. That's was why I left that extract in.
Benchmark: running all, low, sep for at least 1 CPU seconds...
all: 1 wallclock secs ( 1.11 usr + 0.00 sys = 1.11 CPU) @
2917341.44/s (n=3238249)
low: 0 wallclock secs ( 1.27 usr + 0.04 sys = 1.31 CPU) @
12930179.39/s (n=16938535)
sep: 1 wallclock secs ( 1.21 usr + 0.01 sys = 1.22 CPU) @
3223081.15/s (n=3932159)
Subroutines suck, lets all use hashrefs.
That comment was obviously tongue in cheek but there was an
underlining point that access via sub-routine reference is slower than
access via a hash. Toby was quick to point out that as far as he knew
$req-param-{} was the referred method. Now that doesn't break
encapsulation and I'm assuming that it will be faster access method
than $req-params(). I could be wrong. I haven't benchmarked. I am
simply following the logic that subroutine references are slower that
hash lookups. Is it really so wrong to want to use params-{} over
params()? You may call it premature optimisation (as if is a dirty
word) but to me it's just a good habit that has the benefits of being
a bit faster.
So just in case you missed it, when I said:
...but if I'm breaking the encapsulation in some ways that's going to
bite me later, I'd steer
clear.
I meant, I'd don't want break encapsulation.
I hope that clear things up and you can stop talking about me as if
I'm not here :)
Thanx,
Dp
PS: It goes without saying that I agree with Paul's point.
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
On Tue, Apr 27, 2010 at 2:39 AM, Oleg Pronin syber@gmail.com wrote:
Why can't nobody understand, the question is not why someone should
use $c-req-{params}. Of course that is an evil. Problem is that if
i could get -{parameters}{name} at a speed 100x there can't be no
reason for -params to work as a turtle and i see a good reason to use
wrappers around Request to provide normal, fast method of acessing
parameters. Use Class::XSAccessor, Fast::XS, i dont now, use
something!!! Many people ask me why most of catalyst accessors working
so slow ? i dunno what to answer except for writing our own wrapper
accessors getting values directly with massive speedup.
The response you are getting, and having a hard time understanding
apparently, is that the worrying about overhead of accessors is
premature optimization that has no benefit to the scope of your real
application.
Unless you provide a NYTProf of your application showing Catalyst is
the bottleneck, nobody is going to care what you are saying.
I'm not sure why you think Catalyst accessors are so slow... on 5.10+
they are faster than Class::Accessor::Fast. Startup time is slower,
but runtime is faster. I'd prefer that.
Oleg, seriously, what are you trying to accomplish here? You aren't
saying anything helpful and you really aren't good at trolling. I'm
genuinely curious about your goals and the only reason I (and others)
are bothering to respond to you because your history on the mailing
list.
-J
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
Good morning,
On 27/04/10 at 1:22 PM +0100, Dermot paik...@googlemail.com wrote:
That comment was obviously tongue in cheek but there was an
underlining point that access via sub-routine reference is slower than
access via a hash. Toby was quick to point out that as far as he knew
$req-param-{} was the referred method. Now that doesn't break
encapsulation and I'm assuming that it will be faster access method
than $req-params(). I could be wrong. I haven't benchmarked. I am
simply following the logic that subroutine references are slower that
hash lookups. Is it really so wrong to want to use params-{} over
params()? You may call it premature optimisation (as if is a dirty
word) but to me it's just a good habit that has the benefits of being
a bit faster.
So just in case you missed it, when I said:
...but if I'm breaking the encapsulation in some ways that's going to
bite me later, I'd steer
clear.
I meant, I'd don't want break encapsulation.
I hope that clear things up and you can stop talking about me as if
I'm not here :)
That didn't clear things up for me, and I thought I had some
clarity already. So I guess one of us is (still) confused.
I thought it was an issue of:
$req-param(...)
vs:
$req-params-{...}
Note, one is plural, the other is not. The param method is for
legacy CGI.pm compatibility, and as such, is slower. The params
method returns a hash, and of course one then does direct hash lookups.
The params method is an alias for parameters. And since it
simply returns a hash it is relatively speedy and encapsulates
the internal parameters access (hash or whatever) within C::Request.
And for those who like juggling with sharp knives with one hand,
they could skip both param and params methods and use:
$req-{parameters}-{...}
So as long as one doesn't need CGI.pm compat, use
$req-params-{...} as the 'best practices' approach. It's not
slower like $req-param(...) is, but still offers the desired encapsulation.
Have I got that right or am I still confused?
My mental clue sheet looks like this:
$req-param(...) will return one value (scalar or array),
the way I'm used to with CGI.pm.
$req-params-{...} returns multiple values in a hash,
which I can then reference by key.
One thing this discussion did help me with was some confusion
that HTML::FormFu threw in there for me. In my mind, I kept
confusing its $form-param(...) ( related) methods with
$req-params-{...}. This discussion has resulted in me
reviewing my usage of all various param(s) methods and I've
found a few things to fix (or improve).
I hope I've got it right now. :-)
Charlie
--
Ꮚ Charlie Garrison ♊ garri...@zeta.org.au
O ascii ribbon campaign - stop html mail - www.asciiribbon.org
〠 http://www.ietf.org/rfc/rfc1855.txt
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
