On Fri, Mar 16, 2007 at 09:15:37PM -0500, Yevgen Muntyan wrote: > I do understand that a separate match object is a good idea. > But "separate match object in C API is a good idea" is questionable. > While thread-safety is important, it doesn't sound feasible a single > GRegex object will be used from different threads to match something > in *many* cases. Maybe it makes sense to add thread safety > in some other way? The single-object version is certainly more > convenient than a version with a separate match object. > By the way, I don't know about Java, but having re.match() > return an object is very often gets in your way in Python (for > different reasons but it does say something about "it's done > so in Python").
It looks to me like you are suggesting the worst of all worlds. Not thread-safe, not scaleable, and not simple. If you want simple - give up on GRegexp altogether. Try something like: if (g_string_regexp_match(s, pattern)) ... If it happens to do some sort of internal caching - great. If not? At least it is simple. For Java, this maps to: if (string.matches(pattern)) ... Having a matcher object serves more purposes than just thread scaleability. What if I wish to walk through the string, finding each match, processing each match as it is found? Why should I have to search the entire search before I can display the first match? In Perl, this functionality is available as: while ($scalar =~ /(pattern)/g) { ... each match ... } With a Matcher object, the same can be accomplished in a thread-safe manner. Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list