Skip to content
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

Raises errors when giving encryption as non-Hash object #257

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

satoryu
Copy link
Collaborator

@satoryu satoryu commented Jan 13, 2016

In #250 , Net::LDAP of the latest version 0.13.0 accepts encryption options on its initializer. It causes an error when creating a connection as reported.

This PR provides a validation which check whether a given encryption option is a Hash or not.

@tonobo
Copy link

tonobo commented Jan 13, 2016

👍 it would be nice to validate all given parameters from constructor.

@@ -540,6 +540,9 @@ def initialize(args = {})
@base = args[:base] || DefaultTreebase
@force_no_page = args[:force_no_page] || DefaultForceNoPage
@encryption = args[:encryption] # may be nil
if [email protected]? and [email protected]_a?(Hash)
Copy link
Member

Choose a reason for hiding this comment

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

Can we switch this to @encryption && [email protected]_a?(Hash)? This makes the nil check implicit, and the && operator is higher precedence than and (doesn't matter in this case, but I prefer it when used in a conditional)

Copy link
Contributor

Choose a reason for hiding this comment

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

These operators still hurt my brain, if we replace the and operators in the this codebase to && all the tests fail.

http://devblog.avdi.org/2014/08/26/how-to-use-rubys-english-andor-operators-without-going-nuts/

Copy link
Member

Choose a reason for hiding this comment

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

Alternatively, we could also use a single type check with @encryption.respond_to?(:[]). I don't have a strong preference here.

@mynameisrufus why would && fail here?

Copy link
Contributor

Choose a reason for hiding this comment

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

Not here specifically, but when trying to replace and with && throughout the entire codebase (I tried it) all the test fail :)

Copy link
Member

Choose a reason for hiding this comment

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

Thanks for clarifying. I wasn't trying to make so bold a claim ;)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@jch @mynameisrufus Thank you for pointing out this condition. made my understanding about these operators clear 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants