Owen Taylor wrote: > On Sat, 2007-03-17 at 16:08 -0500, Yevgen Muntyan wrote: > >> Yevgen Muntyan wrote: >> >>> [snip] >>> To me here the only good argument in favor of separate Match objects is >>> multi-thread uses. >>> Simply because we already have Match object, just hidden. If the best >>> way to fix GRegex >>> for multi-threading is a separate match object, then it should be a >>> separate match object. >>> >>> >> In fact it's not a solution, right? Since if it's separate Match >> structure, then Regex still needs to keep state. >> So, the solution is to rename some stuff to make GRegex be >> a GRegexExp or something, and move the actual functionality >> to some new GMatcher, i.e. not change anything conceptually but >> explicitly separate Pattern and Matcher. Did I get it right? >> > > Yes, I think you've understood what I was talking about with a > matcher object ... almost all the methods in GRegex currently other > than g_regex_new()/g_regex_optimize() are conceptually matcher methods. > > I don't have any objection to a matcher object with state; what I don't > > like is binding it together with the pattern into a single indivisible > object. > What I was arguing to (if you ignore "don't change it period" part) was creating new match objects every time you perform a match (it's what's done in Python). Basically I don't want every match() method to get me new allocated structure which has to be freed. And given it wouldn't work anyway, I was arguing to something which wouldn't work anyway :) Making cool new API which would be nice is certainly not a bad thing.
One thing should be taken care of: how all those things will be copied/referenced. The language bindings concern led to this silly g_regex_copy(); so we can get same funny thing when someone says "not bindings-friendly" about new API. Perhaps making Matcher and Regex ref-countable (perhaps internally for Regex) wouldn't be bad, would it? It would be great if concerned people [1] commented about it in http://bugzilla.gnome.org/show_bug.cgi?id=419368 Yevgen [1] Owen :) _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
