Matt S Trout
dbix-class at trout.me.uk
Wed Oct 5 16:02:50 CEST 2005
On Wed, Oct 05, 2005 at 11:31:51AM +0200, Bernhard Graf wrote:
> Matt S Trout wrote:
> > If you could work the Regexp part up as a patch to the current state
> > of the refactored branch, I'd be much obliged.
> I'm not sure what you want me todo.
> Of course I could send you a diff how I'd like things to be...
Well, I was thinking a diff that makes a qr// argument fall straight
through to the regexp match.
> I personally don't like the idea to search for "Foo" in
> "Foo", "MyApp::Foo", "MyApp::[MVC]::Foo", because
> - I cannot think of a case where this would be usefull and
Portability of components between apps.
my $comp = $c->comp('M::Foo');
will work in another app; MyApp::M::Foo won't.
> - it is a pitfall (imagine you have a MyApp::C::Foo first and later,
> when you forgot about the $c->comp('Foo') in your code, you add
> MyApp::M::Foo and your application breaks).
A lot of people already use the $c->comp('Foo') idiom and rely on the
regex match; I'm just making it more likely to return what they expected.
> As Wade I'd like comp() to follow DWIM:
> Say $c->comp('MyApp::C::Foo') if I want this and no other,
As noted above, my changes are designed specifically *to* make this method
DWIM. If you want to be totally explicit about it you can be, but that
is not and should not be required.
Plus if you really need to be explicit-or-fail, you can always do
> say $c->comp(qr/foo$/i) if I want to build my own pitfalls. ;*)
I suspect this actually works now; it'd be nice to have it fall straight
through though, which is what I was asking for.
Matt S Trout Specialists in perl consulting, web development, and
Technical Director UNIX/Linux systems architecture and automation. Mail
Shadowcat Systems Ltd. mst (at) shadowcatsystems.co.uk for more information
+ Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +
More information about the Catalyst