-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Axiom types refactor #36
Conversation
# @return [Range<::DateTime>] | ||
# | ||
# @api public | ||
def range |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A #range method needs to be added back to this class like in Axiom::Attribute::Date
.
@cored ok I think I have something working that passes the tests. There's some performance issues with this though, the specs run much slower than before and I think it's in I also think we should audit the Attribute subclasses and make sure our quick patches didn't miss anything. Ideally we want to remove as much as possible from each Attribute subclass, and delegate things to the type, when possible. I've already left comments hinting in this direction, but I'm sure there's more we can do. I am going to do a pass over the diff and look at everything we did to make sure there's no extraneous stuff, and make sure it's optimal. Feel free to do the same if you want, the more of us looking at this the better. |
# | ||
# @return [Range<::Date>] | ||
# | ||
# @api public | ||
def range | ||
DEFAULT_RANGE | ||
type = self.type | ||
type.minimum..type.maximum |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if maybe instead of #range
we can simply delegate #minimum
and #maximum
to the type?
@cored I just added the |
@cored on the TODO list, I have some notes about removing |
@cored I also noticed that we have things like Previously all these methods were needed in Attribute because it was handling constraints and validations. Now all that is handled by axiom-types. Maybe someday we'll need a way to get to the type constraints through the attribute, but I would rather remove code until that is totally required. |
@cored after thinking about this for a while, I think it is probably unnecessary to completely eliminate the However, I do think we should continue with removing functionality that is duplicated between them. Please note this does not change anything we've done up to this point, and does not affect anything still to be done in this PR. All it means is that once the todo notes in this PR are complete and this code is merged into master, we're essentially done with the integration. |
Signed-off-by: Dan Kubb <dan.kubb@gmail.com>
* This is a temporary change until mutant allows me to exclude the Axiom::Types namespace from the classes it mutation tests.
Refactor attributes to use axiom-types
This branch will include a refactoring of axiom to use axiom-types.
DEFAULT_SIZE
constants since the types use the defaults from axiom-types anyway#type
methods to become class methods, and have#type
delegate to itAxiom::Attribute::Date#range
Axiom::Attribute::DateTime#range
Axiom::Attribute::Time#range
Axiom::Attribute::String
constructor to be:minimum_length
and:maximum_length
instead of:min_length
and:max_length
Axiom::Attribute::String
constructor to only create a custom type only if the:minimum_length
or:maximum_length
options are specifiedAxiom::Attribute::Numeric
constructor to only create a custom type if a:size
option is specified@options
ivar fromAxiom::Attribute
. Descendants should pull what they need from the options and store an explicit ivartype.common_ancestor(other)
.Axiom::Types::Type#common_ancestor
to return the best type fromAxiom::Function::Numeric::Binary#type
@example
YARD docs, and others, were not accidentally removed during the conversion