Re: GRegex

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

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

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?

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?


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
(17:38:55) owen: is the latest plan for gregex really a separate
(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?




Marco Barisione

gtk-devel-list mailing list
gtk-devel-list gnome org

Counting bodies like sheep to the rhythm of the war drums.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]