Hi Marco, Please take my review with a grain of salt. I've been wanting a convenience API on top of PCRE for a while now, and it would be great if we could get something like GRegex into Glib proper.
1) Please don't name variables 'string', as there may be a conflict with C++'s std::string 2) I noticed that there are g_regex_ref/unref() methods. Why did you choose to do this, rather than subclass GObject? You would also then have easy GObject-style accessors for the regex's "pattern" and "match_options". 3) Should there be a "GRegexMatch" object too? For instance, at least Python and Java have a notion of a read-only "Pattern" and a "Match Set". Your design combines the two into a single GRegex object. Having the pattern be read-only gets around your thread-safety "gotcha" comment in the docs. 4) Python's search() and match() methods have a "start position" and an "end position" argument, while your match_full() has only a "start position" argument. Is there a reason for this? Could it be implemented? 5) I didn't fully investigate, but Java and Python have a concept of "search vs. match" with slightly different semantics. Is this semantic distinction easily expressible in your API? http://docs.python.org/lib/re-objects.html 6) GRegex requires that PCRE be built with UTF-8 support, which some existing installations aren't. For reference, Gnumeric and Goffice get around this by including a copy of PCRE in their distribution and statically link it in. How do you ensure that GRegex finds a version of PCRE compiled with UTF-8 support? Thanks, Dom On 10/24/06, Marco Barisione <[EMAIL PROTECTED]> wrote: > As discussed some times ago [1] I propose to add a PCRE wrapper to GLib. > Bug #50075 [2] contains a patch that adds it as a separate libgregex. > The documentation of the new API is at [3] (yes, there are some > unresolved problems with gtk-doc). > > Owen Taylor would prefer to have GRegex directly in the main GLib > library: > (17:38:55) owen: is the latest plan for gregex really a separate > library? > (17:39:45) mclasen: owen: you would prefer it folded in ? > (17:40:16) owen: mclasen: I think it makes tons more sense folded in. A > regular expression facility is most useful if you can just use it when > you need it > (17:40:36) owen: mclasen: And on the desktop, having it folded in is > purely a performance win > (17:41:36) owen: if there is an embedded problem (how big is it > anyways?) then a --without-regex configure option would be better > (17:43:19) mclasen: owen: you are probably right > > What are your ideas? > > > I would like to add to the documentation a simple and short tutorial on > regular expressions and GRegex API. Does someone know something good > (and with a compatible license) to copy? > > > [1] > http://mail.gnome.org/archives/gtk-devel-list/2006-July/msg00099.html > > [2] http://bugzilla.gnome.org/show_bug.cgi?id=50075 > > [3] http://www.barisione.org/gregex/ > > > -- > Marco Barisione > http://www.barisione.org/ > > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > -- Counting bodies like sheep to the rhythm of the war drums. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
