[08:01] *** Geth left [08:01] *** Geth joined [08:04] *** Xliff left [08:51] *** sena_kun joined [09:03] .tell Xliff Probably the best way - if wanting to plug into the router - is to provide a role that implements Cro::Transform from HTTP request to HTTP response, maps requests to the correct method, and then use it as `delegate 'foo', ThatObject.new` [09:04] ah, delegate is probably taking a pair, so `delegate foo => ThatObject.new;` [09:38] Ah, though if you meant that you want to just subscribe methods to the `get`/`post` calls, then you can do it using `assuming` [09:39] (and assume the invocant) [09:39] Then the router will see the method sans invocant and stuff should work out [09:40] `get TheClass.^lookup('get').assuming($an-instance);` or similar [10:19] *** sena_kun left [10:21] *** sena_kun joined [10:41] *** Xliff joined [10:41] . [11:01] https://gist.github.com/Xliff/c7e4b55598de3904a2be6d64c541ca9a [12:15] Xliff: Your "cleaned up considerably with class methods" looks hugely clutterred and repetitive to me. [12:16] But of course no objections to putting the code to make that kinda thing happen into a module :) [12:27] jnthn: Was thinking a Role, to be honest. Still...would like to know how to get there. The hygiene comes from not needing an explicit route block, as that will be autogenerated from self.^methods. [12:28] Which has the benefit of being MUCH cleaner when the number of routes scales upward. [12:28] If you think it does look "hugely cluttered and repetitive", I would love to hear your suggestions for cleaning it up! :) [12:44] Xliff: I structured larger apps by having route blocks spread over a number of different functions/modules and composing them with `include`/`delegate`. [12:47] Yes, I've been using that strategy as well. Still, sometimes it's nice to keep logically similar routes in the same place. This can make route blocks kinda cumbersome. I only offered another way to arrange them. I expect Cro-users will adopt a wide variety of strategies. [12:47] I'm only trying to develop another one., [13:22] Sure; I think you already have all the pieces to get there, though, between the MOP, `.assuming`, etc. and can package something up as a module? [13:45] Yep! I think I can package it up as a role. I just need the time to do some testing. [13:45] And I don't have that ATM because I am doing much of this for $dayJob and I just got pulled off on another tangent. :/ [13:57] Sigh, know the feeling, I had a 2 week vacation, and only just now have I dug myself out of the backlog of meetings/emails/discussions induced by it. [13:57] (Whereby I started on Monday. So 4 days just to catch up...) [13:58] Now I need another vacation to recover from it :P [14:11] Hahahaha! [14:12] (not to laugh at your pain, but.... I know the feeling!) [14:12] More often than not, my frustrations result in finding out more requirements for a project just when I'm about to deliver it! [14:12] My company doesn't believe in specs. [14:13] (halp!) [14:15] if your company does not believe in specs, they shouldn't believe in deadlines either [14:44] *** melezhik joined [14:51] *** melezhik left [16:10] *** sena_kun left [16:11] *** sena_kun joined [16:34] lizmat: You would think... but alas. [17:30] lizmat: "DWIM by Friday" [18:47] *** japhb left [18:54] *** japhb joined [19:05] *** andinus left [19:06] *** andinus joined [19:37] *** japhb left [19:43] *** japhb joined [19:46] *** sena_kun left [22:25] *** rba_ joined [22:25] *** ecocode____ joined [22:27] *** jnthn left [22:30] *** perlmaros_ joined [22:31] *** ecocode joined [22:33] *** ecocode___ left [22:33] *** ecocode_ left [22:33] *** rba left [22:33] *** perlmaros left [22:33] *** rba_ is now known as rba [22:33] *** perlmaros_ is now known as perlmaros [22:33] *** ecocode____ is now known as ecocode___ [23:16] *** jnthn joined