proposed changes to use more of Moo, second attempt #17
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
the munging of values passed into ->new should be done in BUILDARGS, which is invoked automatically by Moo.
I kept the `sub build` in case someone was using them, but they just delegate to `->new` now. I had to add some filters into ::Command, because `->build` accepted blessed objects (and took them apart, and rebuild identical objects), but `->new` only accepts un-blessed hashrefs (or hashes, but that's not the issue here)
attributes that should only hold instance of App::Spec are now constrained, and will throw exceptions when set to something different
I've left some attributes without `isa`, because they require more complex type constraints; I'll get back to those later
->callbacks is a hashref of arrayrefs
BUILDARGS must now make sure it doesn't return `undef` values, because they won't pass the constraints. I've had to change `has_subcommands` to handle the case of an empty hashref (it worked more-or-less by accident, before)
this constrains values within the set we can handle (e.g. markup can only be `'pod'` or `'swim'`)
13.argv.t used an arrayref instead of a hashref for `->callbacks`, fixed it
These are awkward, as they have to capture all the various ways these attributes' values can be shaped. I have covered all the types I could discern from the tests and code, I hope I caught them all
with type constraints, there are no longer useful
coderefs always worked, there's no reason to only accept method names
that block of code takes user-provided plugin names, and converts them into a form that's valid for the class; that's exactly what BUILDARGS is for
`BUILD` is invoked automatically from `->new`, to finish initialising the object, so those calls should be there: every object requires them! the trick with declaring the sub and them applying a modifier to it is needed because we're in a role: if the class that consumes the role declares its own `BUILD`, the one provided by the role won't be installed. This way, instead, the empty one won't be installed, but the modifier will still be applied, and we always get the correct behaviour
|
I suggest looking at one commit at a time, in order: I've tried to keep them self-contained (tests always pass, for example) and focused (one file, or one class of type constraints per commit, for example). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
(This PR contains the same changes as #15, but organised in a way that should make it much easier to review)
In reference to #14 :
BUILDARGS/newinstead ofcommon/build, this makes classes easier to use and extendopnow canonically accepts a coderef (previously it did, but probably by mistake: it's a useful feature, let's support it properly)Maybe needed before merging:
Possible future work:
rwattributes