You are right. I had inadvertently constrained my thinking
to patterns of the form match(".*{x}.*") == find(".*{x}.*") == find("{x}")
but that isn't everything someone
might be using it for.On Mon, Aug 6, 2012 at 9:26 AM, Keith Turner <[email protected]> wrote: > I was thinking find() will select everything that match() does and > more. So it may return data that someone used to the current behavior > is not expecting, which could break existing code that uses it. For > example ".*foo" would select "cfooa" with find() but not with match(). > > On Sun, Aug 5, 2012 at 7:16 PM, Michael Flester <[email protected]> wrote: > > Keith -- > > > > Switching from match to find should be no change for anyone that is > > currently using it. > > All patterns that "match" will equally "find". But new users would be > able > > to take advantage > > of not adding the wildcards on both ends. > > > > Mike > > > > > > On Tue, Jul 31, 2012 at 11:21 AM, Keith Turner <[email protected]> wrote: > >> > >> On Sun, Jul 29, 2012 at 9:47 PM, Michael Flester <[email protected]> > >> wrote: > >> > > >> > > >> > On Sat, Jul 28, 2012 at 7:57 PM, John Vines <[email protected]> wrote: > >> >> > >> >> And when dealing with java, it does full matches, so adding the .* to > >> >> start and end is necessary. > >> >> > >> > > >> > Java has both Matcher#matches and Matcher#find. The latter would > operate > >> > more > >> > like the egrep(1) command without requiring the wildcards on both > ends. > >> > >> Ah, It should have used the find() call when it was first written. > >> Changing it now would be tricky because people who expect the current > >> behavior could get unexpected results. I think we are kinda stuck > >> with the current behavior. Could possibly add an option to use > >> find() instead of match(). > > > > >
