Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98644
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.179 as permitted sender)
To: internals@lists.php.net
References: <CA+XhMqxQ8QT+GGbR=Jb9A9y4hYTBX_VEaPa7A9fn_oS5GSjgFQ@mail.gmail.com>
Message-ID: <5276ebe0-ded4-9da4-053b-31e5d721b1b2@gmail.com>
Date: Mon, 27 Mar 2017 22:29:16 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CA+XhMqxQ8QT+GGbR=Jb9A9y4hYTBX_VEaPa7A9fn_oS5GSjgFQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: operating system specific features
From: rowan.collins@gmail.com (Rowan Collins)

On 27/03/2017 19:28, David CARLIER wrote:
> I wanted first to know if php source code can welcome oses specific
> features or should it remain as separated php modules ?

Hi David,

I think there is not really a distinction between "PHP source code" and 
"separated modules", since pretty much everything above the syntax level 
is technically an "extension". As illustration, note that the really 
basic functions like string and array manipulation are in the directory 
"ext/standard"; obviously, you can't turn that module off, but it is 
just one of 72 that are distributed with official builds.

The main difference is between "bundled" extensions and those on PECL 
(http://pecl.php.net). If what you're looking at would make sense as a 
group of functions / classes in its own right, it might be wise to work 
on it first as an independent extension on PECL. This gives you the 
freedom to present a proof of concept, release early and often, and make 
breaking changes based on experience with early adopters. Once it's 
mature, you can ask for it to be adopted into core, where you could 
remain as maintainer, but be constrained by the release process and 
compatibility promises of the main project.

If it's a more natural fit for an existing extension, though, or more of 
a low-level implementation issue, I'd suggest going ahead and proposing 
it, and being open to suggestions of how best to proceed for that 
particular case.

As for platform-specific features, there certainly are functions, and 
entire bundled extensions, that are platform-specific. Quickly glancing 
for obvious examples, I can see that ext/com_dotnet is Windows-only, 
while ext/posix is unavailable on Windows. Where possible, functionality 
is emulated such that it is available on as many platforms as possible, 
even if this means degraded functionality (uniqid() is an example that 
springs to mind), but sometimes you just want access to a feature that's 
unique to one platform.

Regards,

-- 
Rowan Collins
[IMSoP]