Global keywords still in Dancer 2?
I like a lot about Dancer 1 but I don't like the PHP-ish style of having all the helper kewords/functions in the global namespace. I'm coming to Dancer from CGI::Application where we have a persistent $c object, as with Catalyst. Is this approach built into Dancer 2 or is it still using the same global namespace approach? I'd like to be able to be able to: my $d = new Dancer; OR my $d = Dancer->new(); ...... $d->session(); $d->template(); etc. gvim
On Sat, 15 Dec 2012 21:29:09 +0000 gvim <gvimrc@gmail.com> wrote:
I like a lot about Dancer 1 but I don't like the PHP-ish style of having all the helper kewords/functions in the global namespace.
That's Dancer's DSL, and is a fairly core part of what Dancer is. Some people dislike DSLs, but a lot of people do like and enjoy it, and it certainly makes for clear and expressive code, no?
On 15/12/2012 22:28, David Precious wrote:
On Sat, 15 Dec 2012 21:29:09 +0000 gvim <gvimrc@gmail.com> wrote:
I like a lot about Dancer 1 but I don't like the PHP-ish style of having all the helper kewords/functions in the global namespace.
That's Dancer's DSL, and is a fairly core part of what Dancer is. Some people dislike DSLs, but a lot of people do like and enjoy it, and it certainly makes for clear and expressive code, no?
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
Just realised I may be missing the obvious - if Dancer was object oriented you wouldn't have: get '/routename' => sub { }; ... but rather something like: my $d = Dancer->new; $d->get('/routname', $subref); gvim
Dancer 2's DSL is just sugary syntax over lexical variables. You could create your own Dancer application and Route objects and store them in the application. It will saved lexically. But this isn't what Dancer is designed for, and it won't look as pretty as you might expect. On Sun, Dec 16, 2012 at 1:12 AM, gvim <gvimrc@gmail.com> wrote:
On 15/12/2012 22:28, David Precious wrote:
On Sat, 15 Dec 2012 21:29:09 +0000 gvim <gvimrc@gmail.com> wrote:
I like a lot about Dancer 1 but I don't like the PHP-ish style of
having all the helper kewords/functions in the global namespace.
That's Dancer's DSL, and is a fairly core part of what Dancer is. Some people dislike DSLs, but a lot of people do like and enjoy it, and it certainly makes for clear and expressive code, no?
______________________________**_________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/**mailman/listinfo/dancer-users<http://lists.preshweb.co.uk/mailman/listinfo/dancer-users>
Just realised I may be missing the obvious - if Dancer was object oriented you wouldn't have:
get '/routename' => sub { };
... but rather something like:
my $d = Dancer->new; $d->get('/routname', $subref);
gvim
______________________________**_________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/**mailman/listinfo/dancer-users<http://lists.preshweb.co.uk/mailman/listinfo/dancer-users>
On Sat, 15 Dec 2012, gvim wrote:
Just realised I may be missing the obvious - if Dancer was object oriented you wouldn't have:
get '/routename' => sub { };
... but rather something like:
my $d = Dancer->new;
This is an object constructor but in Perl you don't have to call it 'new'.
$d->get('/routname', $subref);
The $d object needs some values for the 'get' attribute. In one line: my $d = Dancer->new->get('/routname', $subref); Mmm, I do not need $d and let's write 'Dancer->new->get' as get: get '/routename' => sub { }; Very object oriented IMHO. -- Henk
On Sat, 15 Dec 2012 23:12:18 +0000 gvim <gvimrc@gmail.com> wrote:
On 15/12/2012 22:28, David Precious wrote:
On Sat, 15 Dec 2012 21:29:09 +0000 gvim <gvimrc@gmail.com> wrote:
I like a lot about Dancer 1 but I don't like the PHP-ish style of having all the helper kewords/functions in the global namespace.
That's Dancer's DSL, and is a fairly core part of what Dancer is. Some people dislike DSLs, but a lot of people do like and enjoy it, and it certainly makes for clear and expressive code, no?
Just realised I may be missing the obvious - if Dancer was object oriented you wouldn't have:
get '/routename' => sub { };
... but rather something like:
my $d = Dancer->new; $d->get('/routname', $subref);
Dancer is, if you like, DSL-orientated, so, yes, you get DSL keywords by default - that's how it is designed. Dancer2 is all OO under the hood, though. If you don't want the DSL keywords, you can disable importing them - hell, you can even replace the core DSL with your own: http://advent.perldancer.org/2012/17 Does that help? -- David Precious ("bigpresh") <davidp@preshweb.co.uk> http://www.preshweb.co.uk/ www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook www.preshweb.co.uk/cpan www.preshweb.co.uk/github
On Tue, Dec 18, 2012 at 7:50 AM, David Precious <davidp@preshweb.co.uk> wrote:
If you don't want the DSL keywords, you can disable importing them - hell, you can even replace the core DSL with your own:
http://advent.perldancer.org/2012/17
Does that help?
I don't see you can disable importing them without specifying an alternative. It's too bad that Dancer2 is doing all the exporting "by hand" instead of relying somehow on a tool like Sub::Exporter. It would be nice to be able to easily rename any particular keyword that clashes with something else. David -- David Golden <xdg@xdg.me> Take back your inbox! → http://www.bunchmail.com/ Twitter/IRC: @xdg
Le mardi 18 décembre 2012 à 19:36, David Golden a écrit :
On Tue, Dec 18, 2012 at 7:50 AM, David Precious <davidp@preshweb.co.uk> wrote:
If you don't want the DSL keywords, you can disable importing them - hell, you can even replace the core DSL with your own:
http://advent.perldancer.org/2012/17
Does that help?
I don't see you can disable importing them without specifying an alternative.
Good idea I'll add that.
It's too bad that Dancer2 is doing all the exporting "by hand" instead of relying somehow on a tool like Sub::Exporter. It would be nice to be able to easily rename any particular keyword that clashes with something else.
That's something I've been willing to add for some time now, but I wouldnt want to add a dependency just for that. Any idea ?
David
-- David Golden <xdg@xdg.me> Take back your inbox! → http://www.bunchmail.com/ Twitter/IRC: @xdg _______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
On Tue, Dec 18, 2012 at 6:27 PM, Damien Krotkine <dkrotkine@gmail.com> wrote:
That's something I've been willing to add for some time now, but I wouldnt want to add a dependency just for that. Any idea ?
That's a dependency worth adding, IMO, though I'm not sure it can do what is necessary. Worst case, you crib it's '-as' API and reimplement it. use Dancer 'any' => { -as => 'any_method' }; But I'm not sure that works, since D2 is already abusing import() in various ways. E.g. sort of like Exporter, but sort of like keys/value pair initializers, too. Ugly. David -- David Golden <xdg@xdg.me> Take back your inbox! → http://www.bunchmail.com/ Twitter/IRC: @xdg
participants (6)
-
Damien Krotkine -
David Golden -
David Precious -
gvim -
Henk van Oers -
sawyer x