This one is easy to explain. My primary selling point of using Perl6 is its multithreading capabilities. The final code would have to deal with a really big number of devices and parallel processing is of a great help here. Resource-vise it's way more reasonable to have a single process with tens of threads than tens of processes. Perl5 involvement would level down this advantage.
Otherwise, I don't need the whole Moo. Perl6 has enough of good stuff to deal with. I was only missing laziness and triggers the most. Just added filtering feature on top of it as Moo lacks it (and for the purpose I had to create MooX::AtttributeFilter, but that's another story...) > 5 вер. 2018 р. о 10:43 Ralph Mellor <ralphdjmel...@gmail.com> написав(ла): > > This is another follow up to Vadim's post. > > Vadim, you didn't touch upon the `use Moo:from<Perl5>;` approach. > > As you noted, you wanted to avoid P5. > > And you've already created AttrX::Moo. > > So perhaps you see anything related to Inline::Perl5 as doubly moot. > > Regardless, I really would love to hear your take on it as an alternative > approach to the one you've taken even if only to guide someone *else* taking > that approach. > > Likewise anyone else reading this. > > ---- > > I talked about Inline::Perl5 in my SO commentary. Have you used it? > > The basic approach is you just write `use Module::Such::As::Moo:from<Perl5>;` > and stuff works as you'd expect if the module were a P6 module. Behind the > scenes it is executing P5 code using the usual P5 interpreter and run-time > and data, objects, calls, and exception handling are automatically mapped to > the equivalent P6. (Thanks to work done by Stefan Seifert and friends over > the last 4 years.) > > Going this route, you would just need to figure out how to declare attributes > on the P6 side such that Moo does its thing on the P5 side. If you got that > working you'd presumably be able to use P6 to seamlessly interoperate with > *existing* P5 code that uses Moo objects and would get as much as you wanted > of Moo's functionality and battle-hardening for free. > > You would presumably be able to do a lot more work in P6 with this P5/P6 > interop than you could with just AttrX::Moo. And the simple :from<Perl5> > solution would presumably be even more widely interesting to users with Moo > code and an interest in P6 than a pure P6 AttrX::Moo. > > ---- > > Which would you say is more true for you: > > * You will be ignoring :from<Perl5> for the foreseeable future. If this is > true it's presumably because you've already seriously explored :from<Perl5> > and found it wanting and/or you or your company are already fully invested in > the direction you've taken. Either way, if so, you might perhaps experience > discussion of it as an unwelcome distraction; please LMK if that's the case. > > OR > > * You prefer to largely ignore :from<Perl5> just for now. (Hopefully you're > willing to say at least a *little* about your view of it in this sub-thread.) > > If you haven't tried :from<Perl5> I can't help but wonder if perhaps we let > you down by not advocating strongly enough for you to explore it. > > If you have, I can't help but wonder what you made of it and why you ruled > out using Moo features in P6 via :from<Perl5>. > > So in summary I'm anxious to hear whether you tried :from<Perl5> and found it > wanting; or we just failed to adequately bring your attention to it; or you > rejected it from the get go based on your understanding of its relevance (or > rather irrelevance) to your situation. > > -- > raiph Best regards, Vadim Belman
