Re: [PHP-DEV] [RFC] [Vote] Doxygen

[Christopher Jones]

On 17/6/17 5:53 pm, Fleshgrinder wrote:

Hi!

I started voting on the Doxygen RFC:

https://wiki.php.net/rfc/doxygen


Did I miss seeing when the vote ends?

Chris

--
http://twitter.com/ghrd


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Extensions License

[Christopher Jones]

On 15/6/17 10:34 pm, Johannes Schlüter wrote:

On Do, 2017-06-15 at 11:06 +0200, Nikita Popov wrote:

On Tue, Jun 13, 2017 at 8:23 AM, Remi Collet 
wrote:


Hi,

All extensions in php-src are PHP 3.01 Licensed
(libs may, of course, have different license)

Is there any strong rule about this ?
Or is it OK to have a BSD Licensed extension ?

Context: see sodium PR
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_php_php-2Dsrc_pull_2560=DwIDaQ=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=lLpUdeB4xTiOOWD6yGzxPFv2SHvPzg3yLT7kvD-ZfyU=GT6MkgICJHeF19FAbAaTtuH4St0KJibc9P1oLj7395Y=VGZgqeH18gkOkITtpv0ZRNfFvmlvCHdsjJ13Zu2yIv4=


IMHO, make sense to have only PHP Licensed ext.


I think we should allow BSD/MIT licenses, as they are compatible with
and
less restrictive than the PHP license. TBH, the PHP license seems
somewhat
dubious when applied to extensions, as most of the additional clauses
are
simply not applicable (extensions do not bundle the Zend Engine and
extensions have no control over the PHP group or the PHP name).



What about the Apache 2 license?

I'd like to be able to include the ODPI-C library code [1] in PDO_OCI and/or 
OCI8.
It is being used for Python cx_Oracle [2] and Node.js node-oracledb [3].
ODPI-C is under a dual license, one of which is Apache 2.


Mind: The PHP License[1]  doesn't talk about the Zend engine, but "PHP
Software", "PHP Software" is, since PHP License 3.01 compared to PHP
License 3.0 defined as PEAR, PECL and PHP on [2]

The "this software includes the ZendEngine" thing in the PHP
distribution's license file[3] is not part of the PHP License, but a
requirement for the PHP product, which includes the Zend Engine
product, which is licensed under the Zend Engine License[4].

According to the most legal interpretations I know (IANAL ... ask two
lawyers, get three answers ...) a BSD-licensed extension bundled in PHP
would be relicensed under PHP license "automatically" when being
distributed as part of the PHP product.


IANAL-too, and haven't talked to one about this - but will one day.


I however think it makes sense to license all bundled extensions as PHP
license with copyright PHP Group as this simplifies moving code around
(i.e. if a BSD licensed extension contains some nice macro which might
be useful to put into main/ this is simpler from a stricter legal pov
if it's the same license)


True.

Chris

[1] https://github.com/oracle/odpi
[2] https://github.com/oracle/python-cx_Oracle
[3] https://github.com/oracle/node-oracledb/tree/dev-2.0


johannes

[1] 
https://urldefense.proofpoint.com/v2/url?u=http-3A__php.net_license_3-5F01.txt=DwIDaQ=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=lLpUdeB4xTiOOWD6yGzxPFv2SHvPzg3yLT7kvD-ZfyU=GT6MkgICJHeF19FAbAaTtuH4St0KJibc9P1oLj7395Y=7x6vjEasY6oe1GzH9OXDBE3pXyveWOz8ls3sXtwy1vw=
[2] 
https://urldefense.proofpoint.com/v2/url?u=http-3A__php.net_software.php=DwIDaQ=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=lLpUdeB4xTiOOWD6yGzxPFv2SHvPzg3yLT7kvD-ZfyU=GT6MkgICJHeF19FAbAaTtuH4St0KJibc9P1oLj7395Y=g1dWNiQpuE2RR-lswQmJXYYD_zwkAzYd1bVVRLXOVBw=
[3] 
https://urldefense.proofpoint.com/v2/url?u=http-3A__git.php.net_-3Fp-3Dphp-2Dsrc.git-3Ba-3Dblob-3Bf-3DLICENSE-3Bh-3D9964e0737cc9be=DwIDaQ=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=lLpUdeB4xTiOOWD6yGzxPFv2SHvPzg3yLT7kvD-ZfyU=GT6MkgICJHeF19FAbAaTtuH4St0KJibc9P1oLj7395Y=ZUqrUXKbNqC3ECQzQRCh6wTF8HWoWt18RInPHAMHcQM=
0521b056be697a5fbeb14d01ef;hb=refs/heads/master
[4] 
https://urldefense.proofpoint.com/v2/url?u=http-3A__git.php.net_-3Fp-3Dphp-2Dsrc.git-3Ba-3Dblob-3Bf-3DZend_LICENSE-3Bh-3D8acb9af4f=DwIDaQ=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=lLpUdeB4xTiOOWD6yGzxPFv2SHvPzg3yLT7kvD-ZfyU=GT6MkgICJHeF19FAbAaTtuH4St0KJibc9P1oLj7395Y=3J0pO0pb7tkfrqMlrZeaJ729znnn2I8lQqGW_lIt51I=
8a589076f305c31501565a2cfe0f6ff;hb=refs/heads/master



--
http://twitter.com/ghrd


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Vote] Doxygen

[Christopher Jones]

On 22/6/17 1:43 am, Fleshgrinder wrote:

On 6/21/2017 5:38 PM, Nikita Popov wrote:

Can you please clarify where functions that are declared in a header and
defined in a source file should be documented? I believe the usual
recommendation is to document in the source file, because it's closer to
the implementation and thus more likely to be updated. On the other hand,
documentation in headers only is more useful if you're just browsing code
and not using generated output.

Nikita



The documentation should go into the header file. Source files actually
must not have documentation, because everything in there is private
anyways. Unless it is exported via a header file that is. Doxygen will
automatically inherit the documentation (no @inheritDoc necessary),
because it understands the C code in C mode.


That kind of detail belongs in the RFC.

A link to existing 'prior art' would have rounded the picture out and let
people decide between alternatives of internal vs external doc.
E.g. link to https://wiki.php.net/internals/references

Also, is this for core and for extensions?  Or for core only?  What
about PECL extensions not part of the PHP bundle?

In summary, see point 8 of 
https://blogs.oracle.com/opal/the-mysterious-php-rfc-process-and-how-you-can-change-the-web

Chris



Documentation should never document what the implementation does, only
how it can be used. This gets blurry if you implement a particular,
standardized algorithm (like the UUIDs) where the actual implementation
suddenly becomes an important part of information that should go into
the documentation.

In other words, refactoring and other changes in a functions body should
not require changes of the documentation. A usage change usually
directly translates to a breaking change. A situation in which many
places require updates (e.g. CHANGELOG, NEWS, ...) and not something a
dev should do without thinking about the implications of doing so.



--
http://twitter.com/ghrd

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Vote] Doxygen

[Christopher Jones]

On 26/6/17 4:43 pm, Joe Watkins wrote:

Morning,

I also voted no for similar reasons to Anatol.

This is not really a thing that needs a vote, this is a thing that requires
the handful of people who are actually able to document ZE to spend
considerable time doing so. In addition it requires a commitment from the
community of developers to continue to maintain, and introduce inline
documentation with new code.

Additionally, I'm a little concerned that an RFC that has the potential to
touch every single source file has gone to vote with a simple majority. It
would seem that we are deciding that new code must be documented in this
specific way, to say nothing of the massive task of documenting existing
code. That would seem to be a decision that could effect everybody that
works on PHP in perpetuity and a simple majority is nothing like a strong
enough consensus.

Cheers
Joe


I agree that although the intention is good, the burden on developers is likely
to cause it to be unsuccessful.  The current state of inline documentation is
partly the result of the culture of PHP, but also the general reluctance of
developers to create documentation :(

Chris



On Sat, Jun 24, 2017 at 10:59 PM, Anatol Belski  wrote:




-Original Message-
From: Fleshgrinder [mailto:p...@fleshgrinder.com]
Sent: Saturday, June 24, 2017 11:34 PM
To: php-internals ; Anatol Belski

Subject: Re: [PHP-DEV] [RFC] [Vote] Doxygen

On 6/24/2017 11:28 PM, Anatol Belski wrote:

I voted no, because it is too short term and I'd see a productivity
drop having such an obligation suddenly right in place for 7.2. To
implement the change, there's more than just to put the doc into the
source. Every piece of code needs to be revisited by someone who
understands it.

I'm not saying the current situation is better than the aim, but to be
realistic - the change needs a culture to be developed. It is clear,
that some know doxygen, but I believe maintaining the doc will be
still a huge effort for many contributors. If some patch were in place
- at least one would have a source for learning by watching, so it
would reduce the learn hurdle  Without being familiar with Doxygen
the actual productivity will for sure suffer.

Neither there's a patch covering at least the very core, nor there's a
strategy for the transition period. I can imagine, that even if the
RFC is voted positive, many contributors not familiar with doxygen
won't have time to complete the doc part. The intention good, but the
assertion might be hard. I might be wrong, but ATM I think the
intention is good, whereby the RFC implementation owes IMHO some
elaborated strategy.

Regards

Anatol


We are only voting that we want to use Doxygen for documentation as a
format, not that documentation is a must for PRs or anything. From the

RFC:

This RFC does not propose any big documentation fest where development
is halted and everybody starts writing documentation. Rather to start
documenting in the future, as well as while refactoring or rewriting
existing code.

Hence, it would be nice to write a little while one is working on

something

anyways.

There is no must to document!


Ok, that was my very concern. Documenting the existing code would also
need profound reviews.


There is a must that IF you document, that it must use Doxygen.

That's what we are voting on. Everybody has plenty of time to get

acquainted

with Doxygen and we can create follow-up RFCs with clearer rules on how

to

document (if need be).


I'd still see an issue, the formulation is a bit slack. If I don't have
to, probably I'd spare 10 minutes I'd have to spend, because a bug
investigation or implementation would take a triple time or more. Depending
on what it takes for me personally in the sum, it could be at least 1 hour
a week, most even 8 hours in a week, that's huge. I'd still say, it needs a
strategy and the community says it's a must. Otherwise, the doc might come
not from a person who implements or understands it. Or - the doc would only
reflect function signatures, which are anyway browsable with lxr, by grep
directly, or the code can be studied from the source.

Thanks

Anatol




--
http://twitter.com/ghrd


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Flexible Heredoc and Nowdoc Syntaxes

[Christopher Jones]

On 13/10/17 8:40 pm, Thomas Punt wrote:

Morning internals,


I'd like to propose an RFC to make the heredoc and nowdoc syntaxes more 
flexible[1]. Any thoughts?


Thanks,

Tom


[1]: https://wiki.php.net/rfc/flexible_heredoc_nowdoc_syntaxes



I like the added flexibility in placement of the end token, but I think requiring only tabs or spaces, and stripping whitespace from all {here|now}doc 
lines is error prone and adds unnecessary complexity.


Chris

--
http://twitter.com/ghrd


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Flexible Heredoc and Nowdoc Syntaxes

[Christopher Jones]

On 2/11/17 8:58 am, Stanislav Malyshev wrote:

Hi!


Voting has now started on the flexible heredoc and nowdoc syntaxes RFC[1].


Voting will be open for 2 weeks (until November 15th).

Something I am missing here. RFC is talking about removing indents from
heredoc text, but the vote says "Allow for the closing marker to be
indented?" and does not mention that indenting closing marker also
changes how the rest of the heredoc is parsed. Is this still the case?




I'm going to have to assume so and vote No.

Chris

PS. RFC writers: please take care when writing specs.


--
http://twitter.com/ghrd


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Flexible Heredoc and Nowdoc Syntaxes

[Christopher Jones]

On 24/10/17 8:27 pm, Thomas Punt wrote:


Hi Christopher,


> I like the added flexibility in placement of the end token, but I think requiring only tabs or spaces, and stripping whitespace from all 
{here|now}doc

> lines is error prone and adds unnecessary complexity.

I agree that the requirement for using either tabs or spaces is not necessary, 
but
I included it because it does help with readability when looking at the 
indentation
level of the heredoc and nowdoc (and subsequently how much whitespace will
be stripped from each line). With respect to the stripping of whitespace, 
however,
I feel that this is definitely necessary.


If developers accidentally add/subtract leading space from the closing token 
then the whole string changes;  this can lead to subtle bugs and annoyances.

Chris


If it was not stripped, then indenting the
closing token and body will cause a lot of whitespace to prepend every line in
the body of text. This is definitely not desirable, and may cause programmers to
continue to not indent the body of the heredoc/nowdoc, which leads us back to
where we currently are of having indentation of code ruined with such syntaxes.

Other languages follow these semantics of stripping whitespace from new lines

according to the indentation of the closing marker, such as Elixir (normal """ 
syntax)

and Ruby (special <<~ syntax).


Thanks,

Tom



--
http://twitter.com/ghrd

Re: [PHP-DEV] [RFC] [VOTE] Cleaning up unmaintained extensions

[Christopher Jones]

On 18/6/18 5:43 am, Stanislav Malyshev wrote:

Hi!

I would like to open the vote for the RFC about cleaning up the
unmaintained extensions:

https://wiki.php.net/rfc/umaintained_extensions

The vote ends 2018-06-26 23:59 PDT.

I have added some discussion about active maintainers and abandonment
procedures, this can be refined further later. I also kept the list of
the candidates as-is for now, but I will update it soon and probably
make a separate wiki page for maintaining it. Please note this list is
not part of the vote (the vote is on the process, not specific list
which will change all the time).

Thanks,

- I know we're all online all the time, but I would have gone for a 4 week 
period instead of 3.  Many countries have significant vacation periods.

- the "community maintained" option looks OK.

- Since this is a process & policy RFC that has a long lifespan as a reference, 
what about renaming it to 'PHP RFC: Process for Unmaintained Extensions'?

[Somehow https://wiki.php.net/rfc should capture these active references. 
Currently they are in the same section as things such as PHP 5.3 EOL]

Chris

--
http://twitter.com/ghrd

Re: [PHP-DEV] Preparing for PHP 8.0.0 GA

[Christopher Jones]

On 20/11/20 1:50 am, Sara Golemon wrote:

I've just cut the release branch for PHP-8.0.0 final which will be released
in one week on 26 Nov.  Minor bug fixes can continue to be merged via the
PHP-8.0 branch for inclusion in 8.0.1, but 8.0.0 will be precisely what
8.0.0RC5 contained unless serious issues are encountered.


What is the status of Windows builds?

In particular who can I work with to get the build to use updated Oracle client libraries for the OCI8 extension in the PHP bundle and the upcoming 
OCI8 3.0 release on PECL?  I.e. drop building with 11g and add 19c?


Fine print: Oracle 19 is a long-term release.  Using Oracle Client 19c 
libraries lets OCI8 connect to Oracle DB 11.2 or later.

Chris

--
https://twitter.com/ghrd

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: [External] : [PHP-DEV] Re: [VOTE] Deprecations for PHP 8.1

[Christopher Jones]

On 12/7/21 5:49 pm, Nikita Popov wrote:

On Wed, Jun 30, 2021 at 11:32 AM Nikita Popov  wrote:


Hi internals,

I have opened voting on 
https://urldefense.com/v3/__https://wiki.php.net/rfc/deprecations_php_8_1__;!!ACWV5N9M2RV99hQ!eOdPIFLsofVNrUBd4W7sbMWdcjqDAxoj6dUr1ubpwolU9F88ArjY_it8fiKBOoU67d5vLg$
 .
The vote closes on 2021-07-14.

This RFC is a collection of various deprecation suggestions from different
people. Each deprecation is voted separately, and should be considered on
its own merit.

Most deprecations should be uncontroversial, but there are some more
contentious ones as well: See 
https://urldefense.com/v3/__https://externals.io/message/113657__;!!ACWV5N9M2RV99hQ!eOdPIFLsofVNrUBd4W7sbMWdcjqDAxoj6dUr1ubpwolU9F88ArjY_it8fiKBOoXqarWpuA$
  for
additional discussion.


The oci8.old_oci_close_semantics deprecation is looking for someone to
implement it (I'm not sure who added it in the first place). I have
everything else covered, but don't have an oci8 test environment to work on
this one.

Regards,
Nikita


I will do it.

Chris

--
https://twitter.com/ghrd

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: [External] : [PHP-DEV] [VOTE] [RFC] Unbundle ext/imap, ext/pspell, ext/oci8, and ext/PDO_OCI

[Christopher Jones]

On 2/11/2023 2:46 am, Derick Rethans wrote:

Hi,

I have just opened voting on the RFC to unbundle imap, pspell, and
oracle integrations.


:)

--
https://twitter.com/ghrd

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: [External] : [RFC} Unbundle ext/imap, ext/pspell, and ext/oci8

[Christopher Jones]

On 27/9/2023 11:27 pm, Derick Rethans wrote:

Hi,

after the initial introduction, here is the formal RFC to unbundle the
imap, pspell, and oci8 extensions and move them to PECL, for PHP 8.4.

https://wiki.php.net/rfc/unbundle_imap_pspell_oci8

cheers,
Derick


Hi Derick,

A small point: the bug URL for OCI8 in the RFC includes issues for 
PDO_OCI - which is not part of the RFC.


Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php