-
-
Notifications
You must be signed in to change notification settings - Fork 419
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
Use reject(&:nil?) in enabled? check #887
base: main
Are you sure you want to change the base?
Conversation
Rejecting nil has the advantage of allowing use of null object patterns using objects that implement nil? but are not strictly nil. This also works well with the 'actor cannot be nil' guard clause which uses `nil?` to check nilness.
@stevecrozz hey! I have no thoughts. were you just pursuing code or did you hit a snag that required this? |
I was inspired by an old RailsConf talk to try using a null object pattern https://www.youtube.com/watch?v=OMPfEXIlTVE In my data model we have users that may or may not have a company. So without null object, Probably using compact to reject nils has better performance than Ultimately, I don't think I'm going to go through with using this pattern so I'm not actually impacted, but maybe others are, so I wanted to drop this breadcrumb for anyone who might wind up with the same trouble. I'd be perfectly happy closing this if there's little interest. |
Maybe just add a code comment with link to this PR so I don't forget and switch it (or someone else)? I'd merge after that. |
Sure. I could probably even add a test case so we really don't forget :) |
@stevecrozz haha yeah that's better. |
@jnunemaker I added a test case but it looks like something is up with the Rails7+ scenarios. Looks like an existing issue. |
Rejecting nil has the advantage of allowing use of null object patterns using objects that implement nil? but are not strictly nil. This also works well with the 'actor cannot be nil' guard clause which uses
nil?
to check nilness.Just an idea. Would love to hear if there are other ideas. Could handle it differently further down by making Types::Actor.wrap(actor) return nil instead of throw an error. Not sure if that would have unintended affects.