If cre2 meets the standard and community agree, I do not care to be honest, I
just mentioned PCRE because it is the “de facto standard” and we are tired of
not being compatible :)
About an in-image solutions in general: Yes, it is better than rely in a
solution like that.
Also about in-image solutions in general: It is harder to maintain them. We are
a small community and we cannot allow us to have everything we need implemented
in image. Using an FFI solution is a perfect valid way and IMO is preferred
many times because of this maintainability issue.
Of course, it does not applies to all cases with same intensity :)
I don’t know the cost of maintain a regex lib in-image. I know at the moment is
infinite because there is no-one there doing it (and I know I do now have the
time). So we stay for years with a suboptimal solution :(
Anyway I want to point to some things I (In my “architect” role, or whatever is
what I do here) I always think:
1- This solution is state-of-the-art?
2- is it maintained or the cost to maintain it can be absorbed ?
2.1- Is maintained by whom?
2.2- Will this kick us back if maintainers leave?
3- is it well tested?
4- is it well documented?
People often forgets that making libraries is a commitment with your user
community, is a lot more than “I do this and then I forget”. Of course you can
proceed like that (and not few of my own projects are of use-and-throw), but we
as “pharo makers” need to take this into account with priority to other
variables.
Notice that “performance” is not in this list. I care a lot about performance,
but I care a lot more about the other points.
Now, that does not means we do not make decisions we later regret (we are
humans, after all… and this is a learning process).
Cheers,
Esteban
> On 6 Feb 2019, at 02:38, Pierce Ng <[email protected]> wrote:
>
> On Tue, Feb 05, 2019 at 07:25:07PM +0100, Norbert Hartl wrote:
>>> Am 05.02.2019 um 16:16 schrieb Sven Van Caekenberghe <[email protected]>:
>>> Still, there are advantages to an in-image solution, can't says this
>>> enough, these external lib dependencies pose their own problems ...
>> +1
>
> Libraries like libgit2, libssh2 and quite a few more are already a core
> part of Pharo, so I'd say philosophically might as well go all in to
> make FFI to external libraries an intrinsic part of computing with
> Pharo, not just for developing Pharo itself. The more people use UFFI,
> the better it will become.
>
>
>
