Comments (5)
What exactly is the goal here? Is there something you're trying to do that is more difficult because it doesn't use Moo?
from reply.
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.
from reply.
Didn't mean to close---clicked by mistake.
from reply.
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.
from reply.
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
from reply.
Related Issues (20)
- wishlist: #vars (or similar) to show current variables HOT 2
- Reply::Plugin::ReadLine broken for PERL_RL=perl (a.k.a. Term::ReadLine::Perl) HOT 1
- accessing lexical variables from inside a named sub
- reply doesn't work on 5.22 on my system HOT 4
- unexpected output from map HOT 2
- plugin to page long results HOT 1
- ReadLine's history_file should expand '~' to $ENV{HOME} HOT 2
- ReadLine plugin can't handle quoted paths, but the pod implies it can HOT 1
- Multiline support HOT 1
- Bare heredoc HOT 1
- Term::ReadKey is a recommends, not a requires but tests fail without HOT 1
- Want to contribute my code to reply HOT 2
- Useless dependency on Devel::LexAlias
- Warn, don't die, on bad/missing plugins or missing optional dependencies
- cannot use feature 'say'
- Negative zero is misprinted as zero
- How about use perl not dosini as the config language HOT 1
- When it receives ctrl-C, reply will quit
- [feature] Shell completion
- broken readline HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from reply.