Perl 6 - the future is here, just unevenly distributed

IRC log for #metacpan, 2016-05-16

| Channels | #metacpan index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
06:05 oiami joined #metacpan
07:59 neilb joined #metacpan
08:11 Relequestual joined #metacpan
08:11 neilb joined #metacpan
09:23 Relequestual joined #metacpan
11:58 anon3252523 joined #metacpan
13:54 mateu joined #metacpan
16:09 neilb joined #metacpan
18:04 oiami joined #metacpan
19:51 ranguard jberger: can I mix Mojolicious and Moo? after 'required' on attributes
19:52 jberger Mojolicious can operate on classes built in Moo
19:52 jberger if that is what you mean
19:52 jberger package My::Controller; use Moo; extends 'Mojolicious::Controller';
19:52 mst ranguard: Moo has built in nonMoo
19:53 mst ranguard: so it Just Works
19:53 ranguard cheers
19:53 mst only thing is the mojo constructor still gets called so if you pass an unknown key to ->new it'll end up in the object
19:53 mst but Mojo considers that a feature, and Moo isn't going to argue with what the superclass considers a feature
19:54 ranguard fairly snuff - thanks
19:54 jberger also remember which class creates the accessor, since the return value on setter will be different
19:54 jberger (mst: am I right about that ^^?)
19:57 Grinnz_ right, you want either Mojo::Base has() or Moo has(), not both
19:57 Grinnz_ but they'll "work together"
20:06 mst jberger: yep
20:07 mst though there's MooX::ChainedAttribute
20:16 jberger I like the "but typically it is to be avoided" :-P
20:16 jberger glad to see the author is keen on the feature
20:22 metacpan joined #metacpan
20:22 metacpan [cpan-api] ranguard created leo/refactor_monitoring from mi/es2 (+0 new commits): https://git.io/vrnDI
20:22 metacpan left #metacpan
20:26 metacpan joined #metacpan
20:26 metacpan [cpan-api] ranguard pushed 1 new commit to leo/refactor_monitoring: https://git.io/vrnyJ
20:26 metacpan cpan-api/leo/refactor_monitoring 531eb1e Leo Lapworth: cleanup the monitoring
20:26 metacpan left #metacpan
20:28 _dolmen_ joined #metacpan
20:55 mst jberger: well, I would imagine they hold the same opinion as I do, which is basically "I don't actually dislike this API as such, but given it's not how CPAN normally works it's bloody confusing sometimes"
20:55 mst *however* that also comes, to my mind, with 'in a mostly mojo project, you probably *should* use it'
20:56 jberger true, my projects mostly come in an "all mojo flavored" or very little mojo
20:56 * mst keeps meaning to write a better version of that extension for Mew
20:57 jberger even though I'm on of the loudest advocates for "try a little bit of Mojo, even in a non-Mojo project"
20:57 jberger well, check that, I don't do very many non-mojo things anymore ... guess I don't
21:04 * Grinnz_ thinks how CPAN normally works is stupid, so chains all the attributes
21:06 * Grinnz_ also still wishes he was able to figure out how to make MooX::ChainedAttributes better
21:07 * Grinnz_ but Class::Tiny::Chained being efficient is usually good enough
21:07 * Grinnz_ emotes some more
21:09 haarg Grinnz_: better how?
21:09 Grinnz_ haarg: the current implementation is not very efficient as it wraps the existing accessor with another call IIRC
21:09 haarg ah
21:10 haarg i could fix that pretty easily
21:22 mst it should really be an MGA role
21:22 mst that would simplify things a lot
21:22 haarg yeah
22:20 vanstyn joined #metacpan
23:00 ether I'm not sure if this is a perlbrew or metacpan issue -- are the search args being passed here correct?   https://github.com/miyagawa/cpanminus/issues/501
23:01 ether if 'path' => 'module' is wrong, what should it be instead?
23:13 jdv79 joined #metacpan

| Channels | #metacpan index | Today | | Search | Google Search | Plain-Text | summary