FROM : Alastair Houghton
DATE : Tue Sep 11 19:02:52 2007
On 11 Sep 2007, at 17:39, Mark Munz wrote:
> I think you just made my argument for me. Apple is waiting for all the
> features they felt they needed for really great regexp support. (the
> bug description seemed a bit vague on what it was they were waiting
> for, more like one of those high-level "we need some APIs" bugs)
I believe the bug Deborah pointed at is basically talking about
changing the ICU regexp engine to be character-encoding agnostic (so
you can compile a regexp once and then use it to match against
strings in UTF-8, UTF-16 or perhaps text in other coding systems) and
to support matching against buffers that are spread across multiple
memory regions. (Currently it only supports native-endian UTF-16,
and to do a really good job of regexp integration with CF/NSString,
you'd want to be able to support 8-bit encodings and ideally---for
NSTextStorage---multi-chunk storage as well.)
I could be wrong, but I think that's what it's all about.
>> Put another way, since we have plenty of options right now, why rush
>> to make an official "NSRegularExpression" (or CFRegularExpression...)
>> before there's a significant advantage in doing so?
>
> That argument could be made for virtually anything Apple does or
> doesn't do. There are existing options for animation, advanced
> controls, data management. Those can all be done right now, but the
> new APIs make the whole task easier.
Well... there are plenty of things that *only* Apple can do, and even
more that only Apple can do without risking the use of unsupported APIs.
> That's all I'm asking for, make the task of using regexp easier
> (especially given how commonplace it now is in everything but Cocoa).
Sure, though it isn't exactly hard right now. It just requires a
little bit of effort on the part of developers, and there are several
Cocoa regexp frameworks available (including RegexKit, which I still
wish had a different name :-)).
> I'm just beginning to look at CocoaICU (first heard of it in this
> thread), but if one guy can do that -- certainly Apple could do
> something similar.
There's OGREKit as well:
http://www8.ocn.ne.jp/~sonoisa/OgreKit/
Personally, where I've needed regexps in Cocoa apps, I've just used
Oniguruma's C API together with a little bit of CoreFoundation; it's
quite easy, which is why I'm not hugely concerned about having this
feature as part of Cocoa just yet (or rather, why I'd rather Apple
did the changes mentioned above before adding it... that way there
will be really obvious advantages to using Apple's NSRegularExpression).
I do understand where those people asking for this feature are coming
from, but I also think it would be a mistake to rush a solution and
then have to deprecate APIs almost immediately.
Kind regards,
Alastair.
--
http://alastairs-place.net
DATE : Tue Sep 11 19:02:52 2007
On 11 Sep 2007, at 17:39, Mark Munz wrote:
> I think you just made my argument for me. Apple is waiting for all the
> features they felt they needed for really great regexp support. (the
> bug description seemed a bit vague on what it was they were waiting
> for, more like one of those high-level "we need some APIs" bugs)
I believe the bug Deborah pointed at is basically talking about
changing the ICU regexp engine to be character-encoding agnostic (so
you can compile a regexp once and then use it to match against
strings in UTF-8, UTF-16 or perhaps text in other coding systems) and
to support matching against buffers that are spread across multiple
memory regions. (Currently it only supports native-endian UTF-16,
and to do a really good job of regexp integration with CF/NSString,
you'd want to be able to support 8-bit encodings and ideally---for
NSTextStorage---multi-chunk storage as well.)
I could be wrong, but I think that's what it's all about.
>> Put another way, since we have plenty of options right now, why rush
>> to make an official "NSRegularExpression" (or CFRegularExpression...)
>> before there's a significant advantage in doing so?
>
> That argument could be made for virtually anything Apple does or
> doesn't do. There are existing options for animation, advanced
> controls, data management. Those can all be done right now, but the
> new APIs make the whole task easier.
Well... there are plenty of things that *only* Apple can do, and even
more that only Apple can do without risking the use of unsupported APIs.
> That's all I'm asking for, make the task of using regexp easier
> (especially given how commonplace it now is in everything but Cocoa).
Sure, though it isn't exactly hard right now. It just requires a
little bit of effort on the part of developers, and there are several
Cocoa regexp frameworks available (including RegexKit, which I still
wish had a different name :-)).
> I'm just beginning to look at CocoaICU (first heard of it in this
> thread), but if one guy can do that -- certainly Apple could do
> something similar.
There's OGREKit as well:
http://www8.ocn.ne.jp/~sonoisa/OgreKit/
Personally, where I've needed regexps in Cocoa apps, I've just used
Oniguruma's C API together with a little bit of CoreFoundation; it's
quite easy, which is why I'm not hugely concerned about having this
feature as part of Cocoa just yet (or rather, why I'd rather Apple
did the changes mentioned above before adding it... that way there
will be really obvious advantages to using Apple's NSRegularExpression).
I do understand where those people asking for this feature are coming
from, but I also think it would be a mistake to rush a solution and
then have to deprecate APIs almost immediately.
Kind regards,
Alastair.
--
http://alastairs-place.net






Cocoa mail archive

