PHP Wiki

phpvcs

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2008/11/13 13:27		current
Line 4:		Line 4:
	* Date: 2008-03-29		* Date: 2008-03-29
	* Author: Gwynne Raskind		* Author: Gwynne Raskind
-	* Status: In the works	+	* Status: Accepted
-	* **Votes: (+0/-0)**	+	* **Progress: Roughly 90% implemented, see [[http://svn.php.net/]]**
-	* **Pro:**	+	* **Votes: While most people prefer a move to Git/Github, a more unanimous desire is required before such a large shift. We're sticking with the status quo and moving to SVN. A git bridge will exist.**
-	* Contra:****	+
	==== Purpose ====		==== Purpose ====

Line 92:		Line 92:

	==== Further Discussion And Reading ====		==== Further Discussion And Reading ====
		+	[[http://news.php.net/svn.migration]]
		+
	[[http://doc.php.net/php/rfc/rfc-proposal-show.php?id=8]]		[[http://doc.php.net/php/rfc/rfc-proposal-show.php?id=8]]

better_benchmarks

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2009/07/20 13:09		current
Line 208:		Line 208:
	* crypto-md5 (29.06.2009)		* crypto-md5 (29.06.2009)
	* richards (29.06.2009)		* richards (29.06.2009)
		+	* Crypto-AES

	===== Still unfinished =====		===== Still unfinished =====

karma-ml

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/04/23 13:47	current
Line 1:	Line 1:
	+	====== Request for Comments: Karma-based Mailing List ======
	+	* Version: 1.0
	+	* Date: 2008-11-07
	+	* Author: Davey Shafik <davey@php.net>
	+	* Status: Under Discussion
	+	* First Published at: http://wiki.php.net/rfc/karma-ml
	+
	+	===== Introduction =====
	+
	+	This RFC is to start a discussion on technical solutions to the noise:signal ratio on internals and other mailing lists.
	+
	+	==== The Problem ====
	+
	+	The problem with mailing lists is that they are a free for all, it doesn't matter who posts, everybody at every level gets to see the post.
	+
	+	In the real world, communications pass through a hierarchy of people, escalating as necessary, passing from person to person up the chain.
	+
	+	This means that, given enough time, any mailing list starts to have a large noise:signal ratio, at least for any given person's take on the list; they want to read what they want to read, and don't need to be distracted ignoring the stuff they don't want to read.
	+
	+	===== Solving the Problem =====
	+
	+	There is an unspoken — some what hap-hazard — hierarchy among the community, which with some thought, I believe, could be defined, refined and utilized to our advantage. As an example:
	+
	+	<code>
	+	- Active internals contributors with access to internals CVS (contributions of code and useful discussions)
	+	\
	+	- Active internals contributiors without access to internals CVS (patch submitters, useful discussions)
	+	\
	+	- Active non-internals, PHP contributions (docs, phpweb, PEAR)
	+	- Active community leaders
	+	- Active project leaders
	+	- Active linux distro maintainers
	+	\
	+	- General Users with a high understand
	+	\
	+	- Genernal users with little understanding (newbies)
	+	</code>
	+
	+	If we take each of these, and assign them a number:
	+
	+	<code>
	+	L1 - Active internals contributors with access to internals CVS (contributions of code and useful discussions)
	+	\
	+	L2 - Active internals contributiors without access to internals CVS (patch submitters, useful discussions)
	+	\
	+	L3 - Active non-internals, PHP contributions (docs, phpweb, PEAR)
	+	L3 - Active community leaders
	+	L3 - Active project leaders
	+	L3 - Active linux distro maintainers
	+	\
	+	L4 - General Users with a high understand
	+	\
	+	L5 - Genernal users with little understanding (newbies)
	+	</code>
	+
	+	Now, what if, at any level, you could only see (by default) 1 level below you (and all levels above you). For example: L1 can see L2, L2 can see L3 etc.
	+
	+	This immediately means that you only see stuff that might be relevant to you; however, as a community, we then lose the ability for newcomers to contribute good ideas; because they would start out with zero karma. To help solve this issue, we adjust karma based on responses:
	+
	+	==== Scenario ====
	+
	+	* A L3 user posts something of interest
	+	* A L2 user see's the post and replies, the reply is L2
	+	* This bumps the original post up to L2 as well, maintaining context
	+	* All L2 users can see the reply and the original thread
	+	* After a second (or more?) L2 response, an L1 see's the post now, and can then participate in the discussion if they choose
	+
	+	In this case, only the thread in question is bumped up, however given enough L2/L1 (weighted) direct responses over different threads, a L3 user can gain karma and eventually become a L2 user (and obviously this applies to anyone moving up the chain)
	+
	+	In this way, threads (and by this mechanism, users also) can organically make their way up the tree as they gain traction, are discussed at each level and moved up.
	+
	+	Furthermore, by not responding to threads, they will organically die, and never make their way up the tree to bother people.
	+
	+	I believe it would be possible to have a single mailing list that could span everything from internals right down to php-general, but this is probably not desired! It would however allow the users of a single list to, regardless of their experience in the tree, contribute without weighing down the list.
	+
	+	==== Features ====
	+
	+	Karma tree seeded by current "social" climate
	+	based on CVS access level, activity in a sliding timescale, community contributions etc
	+	Some manual work will be needed on this
	+	Weighted responses, a L2 responding to a L3, will move it to L2, but 2 L1's or 1 L2 and 1 L1 responding would move it to L1, for example.
	+	Adjustable threshold. Perhaps some magnanimous internals contributor likes to help out newbies, he can choose to see the whole tree, or perhaps just 3 levels down
	+	Championing — it should be possible for a user to champion someone to quickly move them up the ladder, for example a L2 can bring a L5 up to L3, so their peers can see stuff, this is bringing the user up, not the thread
	+	Continued tweaking of karma based on CVS access and contributions
	+	Personal filters, you can add users (of any level) from whom you would like to see threads, helping the movement of stuff up the tree, skipping levels
	+	In this way, we can, in some ways, automate the karma, and in someways advance it through our own choices; creating a hierarchy based on merit and trust.
	+
	+	==== Final Thoughts ====
	+
	+	* Some smart filtering, so that "You're an idiot" responses don't elevate a thread would be good
	+	* That, or just handle it biologically — Don't respond to people in negative ways
	+	* Implementing this as a ML (in terms of interaction) is likely the only way to get some of the higher internals folks using it, a web interface [for the messages] just won't fly
	+	* Personal filters would be handled at master.php.net or maybe a new web interface for this
	+
	+	==== Comments ====
	+
	+	(paraphrased)
	+
	+	* Greg Beaver: The only way to get the core contributors to use the system, is as a mailing list filter
	+	* Lukas Smith: The automatic management is pretty good, but more transparency is needed for users on how posts/users are being ranked

dvcs

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/09/05 09:39		current
Line 3:		Line 3:
	* Date: 2011-07-30		* Date: 2011-07-30
	* Author: David Soria Parra <dsp at php dot net>		* Author: David Soria Parra <dsp at php dot net>
-	* Status: [[rfc:dvcs:vote\|Voting]] (Voting ends Sep 7, 2011 12:00 UTC)	+	* Status: Accepted with Option Git [[rfc:dvcs:vote\|Voting Results]] (Voting ended Sep 7, 2011 12:00 UTC)
	* First Published at: http://wiki.php.net/rfc/dvcs		* First Published at: http://wiki.php.net/rfc/dvcs

solution2

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2008/04/02 16:00		current
Line 50:		Line 50:
	* A version string must include a major, a minor and a patch level number (x.y.z) Please note that all are version numbers are mandatory.		* A version string must include a major, a minor and a patch level number (x.y.z) Please note that all are version numbers are mandatory.
	* A package version has a "state" (as indicated in the package.xml file), which describes the maturity. The state may be one of "alpha", "beta", "RC" or "stable" (listed in the order of code maturity). Please note that the state "RC" is achieved by using the state "beta" and appending the version number with "RC" followed by an integer		* A package version has a "state" (as indicated in the package.xml file), which describes the maturity. The state may be one of "alpha", "beta", "RC" or "stable" (listed in the order of code maturity). Please note that the state "RC" is achieved by using the state "beta" and appending the version number with "RC" followed by an integer
-	* The state should always be added as a suffix unless the state is "stable" 'a', 'b' or 'RC' (respectively for alpha, beta and release candidate) followed by a numeric value. E.g. '1.2.1b3', '1.0.0RC2', '1.1.0a1'	+	* The state should always be added as a suffix unless the state is "stable". Valid suffixes are 'a', 'b' or 'RC' (respectively for alpha, beta and release candidate) followed by a numeric value. E.g. '1.2.1b3', '1.0.0RC2', '1.1.0a1'
	* //Note that the PEAR installer cannot recognize hyphens in a package version string//		* //Note that the PEAR installer cannot recognize hyphens in a package version string//
	* In package.xml, the 'status' field for a release may be any of "alpha", "beta" or "stable". These states should be reflected in the version number: a "stable" release should be at least 1.0.0, for example. A Release Candidate is signified by RCx in the version number and a "beta" status in package.xml.		* In package.xml, the 'status' field for a release may be any of "alpha", "beta" or "stable". These states should be reflected in the version number: a "stable" release should be at least 1.0.0, for example. A Release Candidate is signified by RCx in the version number and a "beta" status in package.xml.

calltimebyref

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/04/06 10:59		current
Line 3:		Line 3:
	* Date: 2008-05-21		* Date: 2008-05-21
	* Author: Steph Fox <sfox@php.net>		* Author: Steph Fox <sfox@php.net>
-	* Status: Under Discussion	+	* Status: Implemented
	* First Published at: http://wiki.php.net/rfc/calltimebyref		* First Published at: http://wiki.php.net/rfc/calltimebyref

Line 51:		Line 51:
	- [3] [[http://cvs.php.net/viewvc.cgi/php-src/main/main.c?r1=1.676&r2=1.677]]		- [3] [[http://cvs.php.net/viewvc.cgi/php-src/main/main.c?r1=1.676&r2=1.677]]

-		+	==== Comments ====
		+	currently allow_call_time_pass_reference is set to Off in both php.ini-production and php.ini-development for 5.3, and Call-time pass-by-reference was removed from 5.4, so this RFC is implemented/obsolete.

solution1

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2008/04/04 09:55		current
Line 3:		Line 3:
	* Status: Work in progress		* Status: Work in progress

-	=== The Problem ===	+	=== History ===
-	Currently, PECL versioning is fairly anarchic. From a user perspective, it's impossible to determine the status of an extension, or whether an update will break binary compatibility with previous versions - or work with a given PHP release - without falling back on trial-and-error. From a developer perspective, it's impossible to know exactly which code base a given bug was reported against. Windows PECL binaries should have reliable version information in the DLL resources (physically visible in the file properties), and PECL packages across all platforms should have this information available at runtime through phpinfo(), phpversion('extname') etc. Some of the processes in php.net that currently use hard-coded extension lists could also benefit from standardized versioning within the source files.	+	PECL versioning has historically been fairly anarchic. From a user perspective, this made it impossible to determine the status of an extension, or whether an update would break binary compatibility with previous versions - or work with a given PHP release - without falling back on trial-and-error. From a developer perspective, it was impossible to know exactly which code base a given bug was reported against. Windows PECL binaries should have reliable version information in the DLL resources (physically visible in the file properties), and PECL packages across all platforms should have this information available at runtime through phpinfo(), phpversion('extname') etc. Some of the processes in php.net that currently use hard-coded extension lists could also benefit from standardized versioning within the source files.
-		+
-	Resolving these issues will help bring PECL to a higher level of quality and reliability.	+
-		+
-	=== Some Facts and Figures ===	+
-	There are currently 214 modules in PECL. Of these:	+
-		+
-	* 1 is written in PHP	+
-	* 3 are SAPIs	+
-	* 2 are no longer hosted in PECL (and should be deleted)	+
-	* 1 doesn't declare a zend_module_entry	+
-	* 1 doesn't have versioning capability (pre-PHP 4.1?)	+
-	* 1 was a CVS error (and should be deleted)	+
-	* 1 is the timezone library for ext/date, and probably has non-standard versioning requirements	+
-		+
-	Of the remaining 204:	+
-		+
-	* 13 already use PHP_EXTNAME_VERSION declared in php_extname.h, but don't use -dev	+
-	* 25 already declare and use a versioning macro in php_extname.h, but the name could be anything	+
-	* 27 already declare and use a versioning macro somewhere in the source	+
-	* 3 do the whole thing in reverse and use the release version from package.xml	+
-	* 136 either hard-code the version, use $Id alone, use $Revision alone or ignore the whole thing	+

	=== Update ===		=== Update ===
-	As of 31st March 2008, the figures given above are incorrect: 145 PECL packages now use the PHP_EXTNAME_VERSION macro appropriately, and a mere handful now declare it in a file other than php_extname.h. The current focus is on PECL packages that are also core extensions in one or more versions of PHP.	+	As of April 2008, all PECL packages should use the PHP_EXTNAME_VERSION macro appropriately and declare the macro in the file //php_extname.h//, and all but a handful have been altered to do so. The one area that is still open for discussion concerns PECL packages that are also core extensions in one or more versions of PHP.

	=== Requirements ===		=== Requirements ===
Line 54:		Line 33:

	* A version string must include a major, a minor and a patch level number (x.x.x)		* A version string must include a major, a minor and a patch level number (x.x.x)
-	* The status of the package may be described using 'a', 'b' or 'RC' followed by a numeric value, e.g. '1.2.1b3', '1.0.0RC2', '1.1.0a1'	+	* The status of the package may be described using 'a', 'b' or 'RC' followed by a numeric value, e.g. '1.2.1b3', '1.0.0rc2', '1.1.0a1'
	* In package.xml, the 'status' field for a release may be any of "dev", "alpha", "beta" or "stable". These states should be reflected in the version number: a "stable" release should be at least 1.0.0, for example. A Release Candidate is signified by RCx in the version number and a "beta" status in package.xml.		* In package.xml, the 'status' field for a release may be any of "dev", "alpha", "beta" or "stable". These states should be reflected in the version number: a "stable" release should be at least 1.0.0, for example. A Release Candidate is signified by RCx in the version number and a "beta" status in package.xml.

Line 60:		Line 39:

	=== Core Modules in PECL ===		=== Core Modules in PECL ===
-	Johannes Schlueter - as Release Master of the PHP 5.3 series - made it known early in the proceedings that he has concerns over -dev, alpha or beta tags appearing in PHP core module versions. There's no process in place to export PECL releases into the PHP core; many of the modules in PECL are symlinked into the PHP core, affecting both snapshots and releases. This has benefits for the PECL modules concerned, in that they get far more testing than they otherwise might during the PHP development cycle, but the point remains that they are linked directly rather than filtered through an independent PECL release process.	+
		+	Johannes Schlueter - currently Release Master of the PHP 5.3 series - made it known early in the proceedings that he had concerns over -dev, alpha or beta tags appearing in PHP core module versions during a PHP release. There's no process in place to export PECL releases into the PHP core; many of the modules in PECL are symlinked into the PHP core, affecting both snapshots and releases. This has benefits for the PECL modules concerned, in that they get far more testing than they otherwise might during the PHP development cycle, but the point remains that they are linked directly rather than filtered through an independent PECL release process.

	The idea of using the tag '-core' rather than '-dev' to reflect the status of those dual-nature extensions came up. The PECL versioning could then remain x.x.x (no tag) during PECL releases, with the version number itself used to reflect alpha/beta development status. Christopher Jones of Oracle voiced his concern regarding core PECL modules in separate development branches, which happens with core symlinking (and can of course occur manually too). "Should the version in CVS HEAD be tagged -core6?" Pierre Joye recommended that module versions with a conflicting API simply reflect this in the version number, e.g. 1.0.3-core for PHP 5.* and 2.0.3-core for PHP 6. The PECL releases would be 1.0.3 and 2.0.3 respectively, and the version bumped to 1.0.4-core/2.0.4-core following release.		The idea of using the tag '-core' rather than '-dev' to reflect the status of those dual-nature extensions came up. The PECL versioning could then remain x.x.x (no tag) during PECL releases, with the version number itself used to reflect alpha/beta development status. Christopher Jones of Oracle voiced his concern regarding core PECL modules in separate development branches, which happens with core symlinking (and can of course occur manually too). "Should the version in CVS HEAD be tagged -core6?" Pierre Joye recommended that module versions with a conflicting API simply reflect this in the version number, e.g. 1.0.3-core for PHP 5.* and 2.0.3-core for PHP 6. The PECL releases would be 1.0.3 and 2.0.3 respectively, and the version bumped to 1.0.4-core/2.0.4-core following release.

backslashnamespaces

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2008/10/25 13:54		current
Line 287:		Line 287:
	* because \ is a single keystroke, it is possible to require \ prefix for all global functions/classes/constants, and conversion is minimally effortful (from personal experience trying to convert files to several namespace separators to see what it was like)		* because \ is a single keystroke, it is possible to require \ prefix for all global functions/classes/constants, and conversion is minimally effortful (from personal experience trying to convert files to several namespace separators to see what it was like)
	* code review ambiguities disappear permanently		* code review ambiguities disappear permanently
-	* name resolution order problems disappear if we decide that "foo/bar" or "foo::bar" is always prefixed with namespace name, and only short names like "bar()" or "new bar" are checked for both "nsname/bar()" and internal function "bar()" or "class nsname/bar" and internal class "bar". "/foo/bar" is used for global scoping.	+	* name resolution order problems disappear if we decide that "foo\bar" or "foo::bar" is always prefixed with namespace name, and only short names like "bar()" or "new bar" are checked for both "nsname\bar()" and internal function "bar()" or "class nsname\bar" and internal class "bar". "\foo\bar" is used for global scoping.
	* code coverage of namespace-related code is so good, it is possible to be very confident of the correctness of the patch.		* code coverage of namespace-related code is so good, it is possible to be very confident of the correctness of the patch.

svnexternals

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/04/06 10:59		current
Line 1:		Line 1:
-	====== Request for Comments: How to write RFCs ======	+	====== Request for Comments: SVN externals ======
	* Version: 1.0		* Version: 1.0
	* Date: 2008-07-01		* Date: 2008-07-01

zendsignals

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/05/31 22:50		current
Line 3:		Line 3:
	* Date: 2008-07-05		* Date: 2008-07-05
	* Author: Lucas Nealan <lucas@facebook.com>		* Author: Lucas Nealan <lucas@facebook.com>
-	* Status: Under Discussion	+	* Status: Implemented in PHP 5.4
	* First Proposed by: [[http://markmail.org/message/3jg6cwqfghdlydhy\|Rasmus Lerdorf]]		* First Proposed by: [[http://markmail.org/message/3jg6cwqfghdlydhy\|Rasmus Lerdorf]]
	* Source code: [[http://tekrat.com/downloads/bits/php-5.3-signals.20091120.patch\|PHP_5_3 patch]] [[http://tekrat.com/downloads/bits/php-trunk-signals.20091120.patch\|PHP Trunk patch]] (11-20-2009).		* Source code: [[http://tekrat.com/downloads/bits/php-5.3-signals.20091120.patch\|PHP_5_3 patch]] [[http://tekrat.com/downloads/bits/php-trunk-signals.20091120.patch\|PHP Trunk patch]] (11-20-2009).

abstract_syntax_tree

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2014/08/27 18:08		current
Line 95:		Line 95:

	==== Changes to list() ====		==== Changes to list() ====
		+
		+	> Note: The behavior of ''list($a, $b) = $a'' described below no longer applies. After this RFC was accepted ''list()'' assignments that contain the same variable on the left- and right-hand side have been special cased to ensure the right-hand side always evaluates first. This means that ''list($a, $b) = $a'' continues working as expected.

	''list()'' currently assigns variables right-to-left, the AST implementation will assign them left-to-right instead:		''list()'' currently assigns variables right-to-left, the AST implementation will assign them left-to-right instead:
Line 147:		Line 149:

	==== Auto-vivification order for by-reference assignments ====		==== Auto-vivification order for by-reference assignments ====
		+
		+	> Note: The auto-vivification order for reference assignments has been restored to the old behavior in PHP 7.1. The reason for this is that we found hard to avoid memory safety issues with the new order.

	While by-reference assignments are (CVs notwithstanding) evaluated left-to-right, auto-vivification currently occurs right-to-left. In the AST implementation this will happen left-to-right instead:		While by-reference assignments are (CVs notwithstanding) evaluated left-to-right, auto-vivification currently occurs right-to-left. In the AST implementation this will happen left-to-right instead:

dvcsmigration

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/04/23 13:47	current
Line 1:	Line 1:
	+	====== Request for Comments: Migrating to a Distributed Version Control System for PHP ======
	+	* Version: 1.0
	+	* Date: 2010-11-30
	+	* Author: Herman Radtke <hradtke@php.net>
	+	* Status: Under Discussion
	+	* First Published at: http://wiki.php.net/rfc/dvcsmigration
	+
	+	===== Introduction =====
	+	A distributed version control system (DVCS) provides considerable more flexibility than SVN. Key features include a developers ability to interact with the repository without the need for a network connection and the low cost of branching.
	+
	+	The initial discussion for moving to a DVCS began during the SVN conversion process. It was not given much credibility because the SVN conversion was mostly finished. There is also the issue of a learning curve. The workflow for SVN is not that different from CVS. The biggest change in converting to SVN was the syntax change. Converting to a DVCS will introduce both a workflow change and a syntax change. The conversion to a DVCS will have a higher intial cost, but the medium and long term benefits far outweigh this cost.
	+
	+	===== DVCS Options =====
	+
	+	Options are listed in alpha order:
	+	* [[http://bazaar.canonical.com/en/\|Bazaar]]
	+	* [[http://www.git-scm.com/\|git]]
	+	* [[http://mercurial.selenic.com/\|Mercurial]]
	+
	+	===== Migration Path =====
	+	The migration to a DVCS should be a gradual one. Converting a repository of PHP's size is a huge task with lots of moving parts. The SVN conversion was a major disruption to the developer community. The initial steps of migration to a DVCS should focus on the conversion of one section of the existing SVN repository to a DVCS.
	+
	+	This does not mean that the migration plan should be made up as we go along. A solid migration plan for all parts of the existing SVN repository should be in place before the initial migration begins. This includes topics such as karma, authentication and scripts. The community will be encouraged to give feedback as the migration process is underway.
	+
	+	===== Use Cases =====
	+
	+	===== References =====
	+	* http://www.python.org/dev/peps/pep-0374/
	+	* http://book.git-scm.com/index.html
	+
	+

heredoc-with-double-quotes

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/04/06 10:59		current
Line 4:		Line 4:
	* Date: 2008-03-22		* Date: 2008-03-22
	* Author: Lars Strojny		* Author: Lars Strojny
-	* Status: [[http://news.php.net/php.zend-engine.cvs/6597\|Accepted]] (Implemented in PHP 5.3)	+	* Status: [[http://news.php.net/php.zend-engine.cvs/6597\|Implemented in PHP 5.3]]
	* Votes: (+6/-4)		* Votes: (+6/-4)
	* Pro: [[http://marc.info/?l=php-internals&m=120679140717702&w=2\|Pierre A. Joye]], [[http://marc.info/?l=php-internals&m=120674698503890&w=2\|Felipe Pena]] , [[http://marc.info/?l=php-internals&m=120636366616273&w=2\|Marcus Boerger]], [[http://marc.info/?l=php-internals&m=120671376003536&w=2\|Gwynne Raskind]], Christopher Jones, Lars Strojny		* Pro: [[http://marc.info/?l=php-internals&m=120679140717702&w=2\|Pierre A. Joye]], [[http://marc.info/?l=php-internals&m=120674698503890&w=2\|Felipe Pena]] , [[http://marc.info/?l=php-internals&m=120636366616273&w=2\|Marcus Boerger]], [[http://marc.info/?l=php-internals&m=120671376003536&w=2\|Gwynne Raskind]], Christopher Jones, Lars Strojny

open_release_manifest

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2021/07/22 23:22		current
Line 18:		Line 18:
	Two types of manifests would be maintained, the first would be per-release and would contain all information that internals sees fit to include, but no less than:		Two types of manifests would be maintained, the first would be per-release and would contain all information that internals sees fit to include, but no less than:

-	* Version	+	* Version
-	* Alpha / Beta / RC / Stable	+	* Alpha / Beta / RC / Stable
-	* Release date	+	* Release date
-	* Download locations for source code, including file hashes	+	* Download locations for source code, including file hashes
-	* A description (if applicable) with support for multiple languages.	+	* A description (if applicable) with support for multiple languages.
-	* A list of changes, grouped by module, where each change includes additional metadata e.g. a bugfix number, CVE and CVSS, or author.	+	* A list of changes, grouped by module, where each change includes additional metadata e.g. a bugfix number, CVE and CVSS, or author.
-	* A list of flags to indicate essential considerations, such as if it is a security release.	+	* A list of flags to indicate essential considerations, such as if it is a security release.

	=== Description Changes ===		=== Description Changes ===

rounding

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2008/08/24 15:50		current
Line 3:		Line 3:
	* Date: 2008-08-23		* Date: 2008-08-23
	* Author: Christian Seiler <chris_se@gmx.net>		* Author: Christian Seiler <chris_se@gmx.net>
-	* Status: Under Discussion	+	* Status: Implemented
	* First Published at: http://wiki.php.net/rfc/rounding		* First Published at: http://wiki.php.net/rfc/rounding

Line 274:		Line 274:
	in a platform-independent way. The GNU C library offers the _FPU_SETCW and		in a platform-independent way. The GNU C library offers the _FPU_SETCW and
	_FPU_GETCW macros in fpu_control.h while on Windows Systems a function named		_FPU_GETCW macros in fpu_control.h while on Windows Systems a function named
-	_controlfp is available for this job.	+	_controlfp is available for this job. FreeBSD provides fpsetprec() and other
		+	Operating Systems that run on x86 require inline assembly.

	Please note that zend_strtod() is also affected by this problem: On systems		Please note that zend_strtod() is also affected by this problem: On systems
Line 394:		Line 395:
	==== Building an abstraction layer for FP control register manipulation ====		==== Building an abstraction layer for FP control register manipulation ====

-	In a first step, my patch introduces 3 macros:	+	See http://www.christian-seiler.de/projekte/fpmath/ for further information
		+	on how to ensure double precision on different architectures, operating
		+	systems and with different compilers.

-	* _ZEND_FPU_CW_DECLARE	+	This proposal proposes to wrap the above abstraction into the following
-	* _ZEND_FPU_CW_SET	+	macros:
-	* _ZEND_FPU_CW_RESTORE	+

-	The DECLARE macro declares certain necessary variables, the SET macro modifies	+	* ZEND_FLOAT_DECLARE
-	the FPU control word so that double precision is used for calculation and	+	* ZEND_FLOAT_ENSURE()
-	RESTORE restores the previous state of the control word. The following example	+	* ZEND_FLOAT_RESTORE()
-	illustrates how these macros are to be used:	+	* ZEND_FLOAT_RETURN(val)

-	<code c>	+	These will be defined in Zend/zend_float.h.
-	double somefunction (double val)	+
-	{	+
-	_ZEND_FPU_CW_DECLARE;	+
-	double foo;	+
-		+
-	_ZEND_FPU_CW_SET;	+
-		+
-	/* some calculations... */	+
-	foo = val / 100.0;	+
-		+
-	*/ ... /*	+
-		+
-	_ZEND_FPU_CW_RESTORE;	+
-	return foo;	+
-	}	+
-	</code>	+
-		+
-	These macros expand to the correct versions for each platform or to NOPs if	+
-	the method for the corresponding platform could not be determined.	+

	==== Fix of zend_strtod ====		==== Fix of zend_strtod ====
Line 440:		Line 423:
	different results.		different results.

-	For this reason, my patch also fixes zend_strtod() by adding the _ZEND_FPU_CW	+	For this reason, my patch also fixes zend_strtod() by adding the proposed
	macros to the function. Then, C and PHP will yield the same results on all		macros to the function. Then, C and PHP will yield the same results on all
	platforms (that support IEEE 754 arithmetics anyway).		platforms (that support IEEE 754 arithmetics anyway).
Line 451:		Line 434:
	=== Usage of FP control word manipulation ===		=== Usage of FP control word manipulation ===

-	The round function uses the new _ZEND_FPU_CW macros in order to ensure double	+	The round function uses the new ZEND_FLOAT macros in order to ensure double
	precision arithmetics within the function body. This will make sure the final		precision arithmetics within the function body. This will make sure the final
	division works properly.		division works properly.
Line 525:		Line 508:
	==== Patch =====		==== Patch =====

-	The patch is available under	+	The patch was already applied to PHP_5_3 and HEAD.
-	[[http://www.christian-seiler.de/temp/php/2008-08-23-rounding/rounding-5.3-1.patch]].	+
-	It applies against the current CVS branch of 5.3, porting it to HEAD should	+
-	be extremely trivial (since this only affects math-related stuff).	+
-		+
-	I tested the patch under Linux 32 bit x86, Linux 64 bit x86_64 and Windows	+
-	32 bit x86. Please note that MinGW does not define _controlfp_s but does	+
-	define _controlfp. Thus I added a conditional ifdef to use _controlfp instead	+
-	if _controlfp_s is not present. This is not relevant now but may be relevant	+
-	when CMake is used as build system for PHP and thus PHP starts to support	+
-	MinGW.	+

-	The _ZEND_FPU_CW macros are currently defined in zend_strtod.h, but there may	+	I tested the patch under Linux 32 bit x86, Linux 64 bit x86_64, Windows
-	be a better place for that. Also, the configure checks for those makros are	+	32 bit x86 and FreeBSD 32 bit x86. Additionally, the macros themselves were
-	currently in ext/standard/config.{m4,w32} while they are probably better	+	tested on various platforms (see the above link for details).
-	located somewhere else.	+

	===== Comparison with the 2004 proposal =====		===== Comparison with the 2004 proposal =====
Line 599:		Line 571:
	===== Changelog =====		===== Changelog =====

		+	* 2008-12-02 Christian Seiler: Updated to current situation
	* 2008-08-23 Christian Seiler: Created RFC		* 2008-08-23 Christian Seiler: Created RFC

shortsyntaxforarrays

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/08/06 19:28		current
Line 75:		Line 75:
	===== Conclusion =====		===== Conclusion =====

-	This patch will not be accepted because slight majority of the core developers voted against. Though if you take a accumulated mean between core developers and userland votes seems to show the opposite it would be irresponsible to submit a patch witch is not supported or maintained in the long run.	+	This patch has been merged in PHP 5.4.0 and trunk.
	===== Discussion on the List =====		===== Discussion on the List =====

trailing-comma-function-args

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2013/03/25 18:28		current
Line 3:		Line 3:
	* Date: 2013-02-19		* Date: 2013-02-19
	* Author: Sara Golemon <pollita@php.net>		* Author: Sara Golemon <pollita@php.net>
-	* Status: Voting Open	+	* Status: Rejected
	* First Published at: http://wiki.php.net/rfc/trailing-comma-function-args		* First Published at: http://wiki.php.net/rfc/trailing-comma-function-args

uniform_variable_syntax

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2014/07/30 00:03		current
Line 2:		Line 2:
	* Date: 2014-05-31		* Date: 2014-05-31
	* Author: Nikita Popov <nikic@php.net>		* Author: Nikita Popov <nikic@php.net>
-	* Status: Accepted (for PHP 7)	+	* Status: Implemented (in PHP 7)
	* Discussion: http://markmail.org/message/mr4ihbubfbdxygci		* Discussion: http://markmail.org/message/mr4ihbubfbdxygci

Line 276:		Line 276:
	</code>		</code>

-	This change is backwards incompatible (with low practical impact), which is the reason why this RFC targets PHP 6.	+	This change is backwards incompatible (with low practical impact), which is the reason why this RFC targets PHP 7.
	However it is always possible to recreate the old behavior by explicitly using braces:		However it is always possible to recreate the old behavior by explicitly using braces:

Line 285:		Line 285:
	</code>		</code>

-	This syntax will have guaranteed same behavior in both PHP 5 and PHP 6.	+	This syntax will have guaranteed same behavior in both PHP 5 and PHP 7.

	==== Newly added and generalized syntax ====		==== Newly added and generalized syntax ====
Line 357:		Line 357:
	occurrence of ''%%$loader[0]::$loader[1]($className)%%'' in the Doctrine class loader will be affected by this change.		occurrence of ''%%$loader[0]::$loader[1]($className)%%'' in the Doctrine class loader will be affected by this change.
	This occurrence must be replaced with ''%%$loader[0]::{$loader[1]}($className)%%'' to achieve compatibility with both		This occurrence must be replaced with ''%%$loader[0]::{$loader[1]}($className)%%'' to achieve compatibility with both
-	PHP 5 and PHP 6.	+	PHP 5 and PHP 7.

	The latter change turns currently valid syntax into a parse error. Expressions like ''%%global $$foo->bar%%'' are no		The latter change turns currently valid syntax into a parse error. Expressions like ''%%global $$foo->bar%%'' are no
	longer valid and ''%%global ${$foo->bar}%%'' must be used instead.		longer valid and ''%%global ${$foo->bar}%%'' must be used instead.

-	As these changes only apply to some very rarely used syntax, the breakage seems acceptable for PHP 6.	+	As these changes only apply to some very rarely used syntax, the breakage seems acceptable for PHP 7.

	===== Open issues =====		===== Open issues =====

progress

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2014/01/20 16:47		current
Line 128:		Line 128:
	\| Implement mechanism to ensure PECL extensions fail to compile if not updated for new API \| not started \|		\| Implement mechanism to ensure PECL extensions fail to compile if not updated for new API \| not started \|
	\| Do smart platform recognition and ermove the size_t/int64 configure options \| done \|		\| Do smart platform recognition and ermove the size_t/int64 configure options \| done \|
-	\| Develop a tutorial (and possibly tools) for PECL extensions \| not started \|	+	\| Develop a tutorial (and possibly tools) for PECL extensions \| in progress \|

2011/04/06 10:59		current
Line 4:		Line 4:
	* Date: 2008-03-22		* Date: 2008-03-22
	* Author: Lars Strojny		* Author: Lars Strojny
-	* Status: [[http://news.php.net/php.zend-engine.cvs/6597\|Accepted]] (Implemented in PHP 5.3)	+	* Status: [[http://news.php.net/php.zend-engine.cvs/6597\|Implemented in PHP 5.3]]
	* Votes: (+6/-4)		* Votes: (+6/-4)
	* Pro: [[http://marc.info/?l=php-internals&m=120679140717702&w=2\|Pierre A. Joye]], [[http://marc.info/?l=php-internals&m=120674698503890&w=2\|Felipe Pena]] , [[http://marc.info/?l=php-internals&m=120636366616273&w=2\|Marcus Boerger]], [[http://marc.info/?l=php-internals&m=120671376003536&w=2\|Gwynne Raskind]], Christopher Jones, Lars Strojny		* Pro: [[http://marc.info/?l=php-internals&m=120679140717702&w=2\|Pierre A. Joye]], [[http://marc.info/?l=php-internals&m=120674698503890&w=2\|Felipe Pena]] , [[http://marc.info/?l=php-internals&m=120636366616273&w=2\|Marcus Boerger]], [[http://marc.info/?l=php-internals&m=120671376003536&w=2\|Gwynne Raskind]], Christopher Jones, Lars Strojny

2014/01/20 16:47		current
Line 128:		Line 128:
	\| Implement mechanism to ensure PECL extensions fail to compile if not updated for new API \| not started \|		\| Implement mechanism to ensure PECL extensions fail to compile if not updated for new API \| not started \|
	\| Do smart platform recognition and ermove the size_t/int64 configure options \| done \|		\| Do smart platform recognition and ermove the size_t/int64 configure options \| done \|
-	\| Develop a tutorial (and possibly tools) for PECL extensions \| not started \|	+	\| Develop a tutorial (and possibly tools) for PECL extensions \| in progress \|