Re: GRegex

["Dominic Lachowicz" <domlachowicz gmail com>]

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 <marco barisione org> 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.