Lets take the question of 'do I really need AttrX::Mooish' out of the scope and postulate for now that I do need it; and no, I don't want to use any of Perl5 solutions. Just to focus more on Proxy itself.
What other approaches to implement laziness in Perl6? Method based. It could either be redefined accessors (lvalue methods) or setters/getters. The latter I would reject as it imposes the $obj.attribute($value) style of using a setter which brings us back to the world of Perl5 code style. Pardon, no option. Lvalue is no go here because I'm out of control the value being stored. Or... Wait a second... I'm not because I can use Proxy for that! And this is how I got to the idea of replacing attribute container with Proxy. So far, I see no other solutions. Of course, I'm a beginner in the Perl6 world and could miss just about anything. But that's how things are for now. > > The real problem is that, in the absence of Proxy, rakudo can optimize a > bunch of things away because it knows it has full control of the value. But > if it encounters a Proxy, it has to assume that the Proxy might be > manipulating state outside of the current thread, or even outside of rakudo, > that might change at any time. > My luck in this situation is that I'm not very much dependent on the performance. My current task is more about networks operations and a couple of simple manipulations on the tool side. Trading some performance for flexibility is ok with me. Perhaps the only for Perl6 to keep control over optimization is to provide a mechanism of allowing a third-party code to legally participate in attribute fetching or storing. Not that it would solve all the problems, but the level of control from the compiler would then be much higher. > > This is why Proxy is used as an attribute container. It allows for using of > > auto-generated accessors or user-provided ones without extra headache of > > how to deal with conflicts. It's being said that Proxy is problematic in > > many aspects, but it would be eventually fixed, wouldn't it? So far it does > > the job for me. > > The primary problem I was alluding to is that, at least last time I > investigated, Proxy semantics reserve the right to repeat FETCH calls > multiple times per single read and likewise STORE calls per single write and > in reality this happens a lot, or at least used to. So far, this doesn't bother me much. There was a side effect of binding a Proxy object to an attribute where FETCH was executed voluntarily at the moment binding, but I worked out a way to ignore it at a cost of additional key in a storage hash. Otherwise, I did not observe any significant repetitions of FETCH while debugging except for say calls. > That said, P6 is driven forward by its users interacting with the community > and/or ecosystem. If you create test cases covering functionality that > matters to you and/or your company and get them added to roast, the suite of > tests that officially define P6, you can directly and formally influence > prioritizing of attention to P6's and Rakudo's capabilities and bugs. This is something I never thought about. Would get back to the idea after finishing the current project. Best regards, Vadim Belman
