Check for constant definition before invoking

[KaanOzkan]

Motivation

Closes #1913

Implementation

Tests

[amomchilov]

Would it be better to check for the exact constant that we reference?

Suggested change

	when defined?(ActiveRecord::Encryption) && ActiveRecord::Encryption::EncryptedAttributeType
	when defined?(ActiveRecord::Encryption::EncryptedAttributeType) && ActiveRecord::Encryption::EncryptedAttributeType

[paracycle]

I think it is dangerous to use when like this:

irb> foo = nil
#=> nil

irb> case foo
irb> when defined?(Foo) && 42
irb>   puts "Oh no"
irb> when 42
irb>   puts "Here"
irb> end
Oh no

The current way only works because defined?(Foo) && Foo evaluates to Foo if it is defined, but it evaluates to nil if it is not.

I think what we want is:

Suggested change

	when defined?(ActiveRecord::Encryption) && ActiveRecord::Encryption::EncryptedAttributeType
	when ->(type) { defined?(ActiveRecord::Encryption) && type == ActiveRecord::Encryption::EncryptedAttributeType }

[paracycle]

This change should be applied to all the other cases that use this pattern as well.

[KaanOzkan]

Had to slightly change it to use ===

[paracycle]

Yes, I got confused with type and mistook it for the class itself, but it's actually an instance of the class we are checking against. Sorry for the misdirection.

[paracycle]

How come this wasn't failing the CI on Rails 6.1? Are we missing a test for this?

[paracycle]

Ah, because we don't officially support Rails 6.1, so we don't test against it, that makes sense.

[paracycle]

Thanks!

[amomchilov]

Interesting pattern, which answers the question:

Why does Proc respond to #===?! When would you ever call some_proc === some_arg instead of just some_proc.call(some_arg)?!

[paracycle]

Yes, a lot of the #=== implementations are so that you can use them in when clauses.