add string form, extend selector with EXISTS, new tests/some old tests use table-driven style

Based on discussion in https://github.com/GoogleCloudPlatform/kubernetes/pull/715. Some of the old tests were not converted to table-driven format since the code on which they are based will probably be removed in the near term. Future work includes: changing uses of old code in other parts of the code base to use newer version of selector, removing old selector code, removing tests of old selector code, and adding number ranges to selector values.
Splitting a string is a poor man's parser.  You should be able to write a
simple state-based parser in 5 LOC, once we settle on syntax.  Remember
this will end up in URLs, so it will be escaped in horrible ways.  I have a
weak pref for "x in (y, z)" vs "in(x, [y,z])" because it is more obvious to
me, but you're right that whitespace matters (e.g. in(x,[y,z]) has not
whitespace, but is valid).

On the last point, any time there's a DSL stored in a string, your IDE will
sort of suck at helping you with it.



On Wed, Aug 20, 2014 at 9:33 PM, meirf <notifications@github.com> wrote:

> In pkg/labels/selector_test.go:
>
> >  	}
> >  }
> >
> > -func TestRequirementMatches(t *testing.T) {
> > -	s := Set{"x": "foo", "y": "baz"}
> > -	a := Requirement{key: "x", operator: IN, strValues: util.NewStringSet("foo")}
> > -	b := Requirement{key: "x", operator: NOT_IN, strValues: util.NewStringSet("beta")}
> > -	c := Requirement{key: "y", operator: IN, strValues: nil}
> > -	d := Requirement{key: "y", strValues: util.NewStringSet("foo")}
> > -	expectMatchRequirement(t, a, s)
> > -	expectMatchRequirement(t, b, s)
> > -	expectNoMatchRequirement(t, c, s)
> > -	expectNoMatchRequirement(t, d, s)
> > +var strValidityTests = []struct {
> > +	in      string
> > +	isValid bool
> > +}{
> > +	{"abc", false},
>
> To be clear, I meant when combining these Requirements so having "in(a,
> [b, c]),d,not_in(e, [f, g]". In this context having commas both between
> values and between requirements would make parsing bit more difficult than
> just splitting. Though I suppose using a regex would work. I prefer "in(a,
> [b, c])" over "x in (y, z)" I think programmers would be wary of the white
> space surrounding "in" and "not in" in a non-interpreted/compiled
> environment where they wouldn't get immediate feedback - from an IDE for
> example - that their syntax was wrong.
>
> --
> Reply to this email directly or view it on GitHub
> <https://github.com/GoogleCloudPlatform/kubernetes/pull/951/files#r16520088>
> .
>