Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100882
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.22 as permitted sender)
To: PHP Internals <internals@lists.php.net>
Message-ID: <c90bc2ef-8f5d-ee37-6aab-56353bfc1908@gmx.de>
Date: Thu, 12 Oct 2017 19:18:41 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.4.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: 7bit
Subject: Enchant 2
From: cmbecker69@gmx.de ("Christoph M. Becker")

Hi!

I've noticed the other day that Enchant 2.0.0 has been released in
August[1].  ext/enchant does not support Enchant 2 yet, however.  Only a
few fixes are necessary to make it compile[2], but there is an issue
regarding the PHP functions enchant_broker_set_dict_path() and
enchant_broker_get_dict_path(), which rely on enchant_broker_get_param()
which has been completely removed.  Instead there is now a single
function to specify the path where to look for the dictionary files:
enchant_set_prefix_dir()[3].  Apparently, it would be possible to store
the individual paths internally, and to call enchant_set_prefix_dir()
whenever a dictionary is requested or checked for existence, thus
retaining the old functionality.

I have some doubts if this would be sensible, though, because
enchant_broker_(s|g)et_dict_path() only supported the Ispell and
Myspell/Hunspell back-ends anyway.  Instead it may be more reasonable to
introduce a new PHP function enchant_set_prefix_dir() which would
directly map to the C function with the same name.  Depending on whether
ext/enchant had been compiled with Enchant 1 and 2, respectively, the
other function(s) would not be available.  If done this way, the
constants PHP_ENCHANT_MYSPELL and PHP_ENCHANT_ISPELL should neither be
available, if compiled with Enchant 2, because they are only useful for
enchant_broker_(s|g)et_dict_path().

Somewhat related to supporting Enchant 2 would be the question if we can
lift the requirements to Enchant 1.6.0 (released 2010-04-01).  This
version introduced enchant_get_version() (which is still there in
Enchant 2), and would allow us to simplify and clean the libenchant
version info in PHP info[4].

Thoughts?  Would that require an RFC?

[1] <https://github.com/AbiWord/enchant/releases>
[2] <https://gist.github.com/cmb69/aa2e5adfc3a08daf16566165d237fba6>
[3] <https://github.com/AbiWord/enchant/blob/v2.0.0/src/enchant.h#L358>
[4]
<https://github.com/php/php-src/blob/php-7.2.0RC4/ext/enchant/enchant.c#L321-L325>

-- 
Christoph M. Becker