Why hand-rolled OO and not Moo for Reply?

[devel-chm]

I'm working on some PDL development using Moo
for its support of modern OO features and because
it is compatible with full Moose if needed.

In addition, I plan to move the pdl2 interactive shell
implementation from one based on Devel::REPL to
one built with Reply due to its improved startup
file support (more sh-ish!) and the simplicity.

In trying to minimize code duplication, I was wondering
what the design goals were for a more hand-rolled
OO implementation (classic perl5) versus using Moo.
I was thinking to try refactoring Reply to use Moo and
was wondering if you see any benefits or problems
with that?

Thanks,
Chris

[doy]

What exactly is the goal here? Is there something you're trying to do that is more difficult because it doesn't use Moo?

[devel-chm]

I was trying to avoid duplicate code implementing essentially the same feature where the user would need to use one approach in Reply code and another in Moo code. Specifically, the wrapped, chained, and concatenate callbacks seems to be a Reply-specific implementation of the around, before, and after method modifiers. I wanted to understand if the implementations did overlap in the way I thought they and and wondered if there are specific benefits to doing things one way or another.

The backstory re PDL development is that we're starting work on a new compute kernel approach for the Perl Data Language that would use Moo as the basis for the OO framework. The hope was to have PDL3 support modern perl OO best practices efficiently by using Moo for the basics but to use the Moosification to full Moose when more powerful tools are needed.

[devel-chm]

Didn't mean to close---clicked by mistake.

[doy]

I don't understand what you mean by "Moo code" and "Reply code". There is no reason that you can't write Reply plugins using Moo. Reply doesn't have anything to do with the code you write - it just executes it. That said, the wrapped/chained/etc stuff is actually not like method modifiers at all - Reply plugins are not implemented via roles/inheritance in the way that Devel::REPL plugins are (getting away from that model was one of the main reasons I wrote Reply rather than just using Devel::REPL - implementing plugins as role application is in general a pretty bad design).

I guess I still just don't understand what kind of code you will be writing where the way Reply is implemented would matter.

[devel-chm]

It is true that Reply doesn't use Roles per se, but I still see parallels between the following:

• Reply::Plugin abstract base class <=> Plugins as Roles
• require_module <=> Role application
• wrapped plugins <=> around() method modifier to specific list of methods in plugins
• chained plugins <=> before() method modifier to list of methods in plugins
• concatenate plugins <=> after() method modifier to list of applicable methods in plugins

However, I think you have answered my basic question. By implementing Reply callbacks and plugins without the general MOP stuff you can keep the implementation light and efficient. Having a clear contract and description for how plugins and pub/sub stuff works also simplifies understanding, use and extension of Reply-based shells. Thanks. -chm