Skip to content

Update how generics work for Avram::Attribute#586

Merged
matthewmcgarvey merged 1 commit intoluckyframework:masterfrom
matthewmcgarvey:attribute-rework
Jan 4, 2021
Merged

Update how generics work for Avram::Attribute#586
matthewmcgarvey merged 1 commit intoluckyframework:masterfrom
matthewmcgarvey:attribute-rework

Conversation

@matthewmcgarvey
Copy link
Member

I'm starting to look into #408 but noticed that the generics for Avram::Attribute were a bit weird. We document that values for attributes are always nilable but that wasn't necessarily true. It's always nilable because where ever we were "new-ing" up an attribute we were doing so in a macro and adding in a ? to whatever type was supplied but the attribute's type could have been anything (including not nilable). We can avoid doing that in the macros by making the attribute's value nilable within the class. So Avram::Attribute(String?) becomes Avram::Attribute(String) but Avram::Attribute(String)#value is still String?

This would be a breaking change for anyone referencing the type. For instance, some validations had to be updated so anyone that defined their own and specified the type will be broken.

@matthewmcgarvey matthewmcgarvey added the BREAKING CHANGE This will cause a breaking change label Jan 4, 2021
getter :param_key
getter name : Symbol
setter value : T?
getter param_key : String
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I change symbol to type declaration out of preference, hopefully that's ok 😄

@errors << message
end

private def perform_add_error(message : (Proc | Avram::CallableErrorMessage))
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moving this overload into the add_error method simplifies the code and error stack traces

Copy link
Member

@jwoertink jwoertink left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this makes sense. We lock in the type the attribute wants, but say the value could be nil. 👍

if value.is_a?(Avram::Uploadable | String) && value.blank?
nil
else
value
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should be adding a not_nil! here so the compiler knows this type is locked in? 🤔

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The value can always be nil, this code is just the logic that also treats blank strings as nil.

@matthewmcgarvey matthewmcgarvey merged commit 03d1a7b into luckyframework:master Jan 4, 2021
@matthewmcgarvey matthewmcgarvey deleted the attribute-rework branch January 4, 2021 16:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

BREAKING CHANGE This will cause a breaking change

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants