Expanding Usage of RubyRegex from just Validation #3

klappy opened this Issue Sep 22, 2011 · 3 comments


None yet
2 participants

klappy commented Sep 22, 2011

Validation is one great usage of regex in ruby but I use searching more often than validation and there must be others that could take advantage of expanding the scope of this project.

Would you be interested in expanding the scope of this project to search for the defined regex in a larger context as well as the current usage of validation of a string only containing the desired pattern?

Since the current regex for each locates each on a line by itself it seems as if having an option to locate them in a line would be helpful. Nesting regex is quite simple in ruby and could be used to keep it dry.

email = /([\w\!\#$\%\&\'\*\+\-\/\=\?\^\`{\|\}\~]+\.)*[\w-]+@((((([a-z0-9]{1}[a-z0-9\-]{0,62}[a-z0-9]{1})|[a-z])\.)+[a-z]{2,6})|(\d{1,3}\.){3}\d{1,3}(\:\d{1,5})?)/i
email_validation = /^#{email}&/

"this is my email: user@domain.tld"[email]
=> "user@domain.tld"

=> "user@domain.tld"

"this is my email: user@domain.tld"[email_validation]
=> nil

I can propose more some samples and examples of usage if necessary. Obviously some thought has to be invested in organization and backwards compatibility.

Thanks for your consideration!


eparreno commented Sep 27, 2011

it sounds interesting. I think it would be a good solution to use namespaces to organize this new feature, for example

RubyRegex::Email (email validation)
RubyRegex::Text::Email (email matching within a text)

What do you think?


klappy commented Sep 27, 2011

That seems like a logical solution. What if we took this one step further and name them RubyRegex::Validate::Email and RubyRegex::Search::Email so that the namespace defines its usage and what it does. That way if we expand the project further we could possibly even have RubyRegex::Split::Email (not that one would split a string at every Email but you get the idea that there are other uses for regex). Then RubyRegex < RubyRegex::Validation so that the default remains backwards compatible. This would allow the user to override the default namespace.

Either way I would happy with it and would also be eager to assist.

Thanks again!

klappy closed this Sep 27, 2011

klappy reopened this Sep 28, 2011


klappy commented Sep 28, 2011

Must have clicked "Comment & Close" instead of "Comment"

eparreno self-assigned this Nov 14, 2014

eparreno closed this Feb 25, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment