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

Add prevailing_rule/2 and matches_explicit_rule?/1 #17

Merged
merged 1 commit into from Jun 3, 2016

Conversation

andersju
Copy link
Contributor

This fixes #15 by adding prevailing_rule/2 (returns prevailing rule of domain) and matches_explicit_rule? (checks whether domain matches explicit rule). E.g.:

iex(1)> PublicSuffix.prevailing_rule(".com")                 
nil
iex(2)> PublicSuffix.prevailing_rule("foobar.com")
"com"
iex(3)> PublicSuffix.prevailing_rule("foobar.co.uk")
"co.uk"
iex(4)> PublicSuffix.prevailing_rule("com")         
"com"
iex(5)> PublicSuffix.prevailing_rule("foobar.example")
"*"
iex(6)> PublicSuffix.prevailing_rule("ck")            
"*"
iex(7)> PublicSuffix.prevailing_rule("www.ck")
"ck"
iex(8)> PublicSuffix.prevailing_rule("foobar.net.ck")
"net.ck"
iex(9)> PublicSuffix.matches_explicit_rule?(".com")          
false
iex(10)> PublicSuffix.matches_explicit_rule?("foobar.com")
true
iex(11)> PublicSuffix.matches_explicit_rule?("ck")        
false
iex(12)> PublicSuffix.matches_explicit_rule?("www.ck")
true
iex(13)> PublicSuffix.matches_explicit_rule?("foobar.net.ck")
true
iex(14)> PublicSuffix.matches_explicit_rule?("foobar.example")
false

Tests also added. prevailing_rule is tested in test/generated_test_cases.exs. It should return the same as public_suffix, except for a few cases (e.g. when the domain is unlisted) where it should return "*"; these are handled separately in test/public_suffix_test.exs, where there are also some tests for matches_explicit_rule?.

(Disclaimer: I'd never touched ExUnit before but I think it's OK :))

|> String.split(".")
|> find_prevailing_rule(options)
|> Enum.join(".")
end
Copy link
Contributor

Choose a reason for hiding this comment

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

I think it's confusing to overload parse_domain to do entirely separate things based on the flag provided as the last argument. Instead, WDYT about removing the last arg to parse_domain and inlining this logic in prevailing_rule/2?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yep. Will do.

@andersju
Copy link
Contributor Author

andersju commented Jun 2, 2016

Alright, should be better now. I did a few slight modifications to make find_prevailing_rule return a tuple with the actual matching rule, as suggested. Also removed the prevailing_rule/2 tests from generated_test_cases.exs (as it was probably just messy and confusing with the exceptions), and instead added more in public_suffix_test.exs.

# TODO: "Wildcards are not restricted to appear only in the leftmost position"
@wild_card_rules[["*" | suffix]] in allowed_rule_types -> domain_labels
@wild_card_rules[["*" | suffix]] in allowed_rule_types -> {:normal, ["*"] ++ suffix}
Copy link
Contributor

Choose a reason for hiding this comment

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

I recommend using ["*" | suffix] over ["*"] ++ suffix. The ++ operator is O(n) over the size of the list on the left, whereas [a | b] is highly optimized and is always constant time.

In this case, the list of the left has only one element so I doubt there's a perf difference, but as a a matter of habit I think it's best to prefer the [a | b] form when it can be used, as it can here.

@myronmarston
Copy link
Contributor

Well done @andersju! I left a few suggestions but this LGTM otherwise.

same; make find_prevailing_rule return actual matching rule; update README
@andersju
Copy link
Contributor Author

andersju commented Jun 2, 2016

@myronmarston: I fixed the last few things you mentioned. Thanks for the feedback, very helpful!

@myronmarston
Copy link
Contributor

LGTM. Thanks, @andersju!

@myronmarston myronmarston merged commit 917dc81 into seomoz:master Jun 3, 2016
myronmarston added a commit that referenced this pull request Jun 3, 2016
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.

Handling suffixes not in the public list
2 participants