PHP Wiki rfc

rfc:altmbstring

2009-07-27T08:01:16+00:00

	current
Line 1:	Line 1:
	+	====== Request for Comments: Alternative implementation of mbstring using ICU ======
	+	* Version: 1.0
	+	* Date: 2009-07-27
	+	* Author: Moriyoshi Koizumi <moriyoshi@php.net>
	+	* Status: Under Discussion
	+	* First Published at: http://wiki.php.net/rfc/altmbstring

	+	===== Introduction =====
	+
	+	This RFC discusses the alternative implementation of mbstring extension that in turn uses ICU instead of libmbfl.
	+
	+	===== Rationale =====
	+
	+	Ever since its introduction in the very first version of PHP 4, mbstring extension has been controversial in a sense supposedly owing to the following reasons:
	+
	+	* Lack of understanding -- It took long for those who don't use Unicode or other non-single-byte codesets to figure out how essential the functionality this extension covers, just until recently.
	+	* Huge bundled libraries -- One of the bundled libraries, libmbfl, consists of a large set of Unicode-to-legacy charset mapping tables and vice versa. This may look redundant to those who aren't interested in manipulating multibyte strings.
	+	* Limited support for locales -- libmbfl has a setting called "NLS" that determines the defaults for several functions, but only a random list of locales are supported; Armenian, Chinese (simplified and traditional), English, German, Japanese, Korean, Russian and Turkish (yes, French is not there...).
	+	* Incompliancy with the standards -- Character cases are not well handled in a case-insensitive matches performed by stripos(), strripos() and so on because libmbfl doesn't implement Unicode collations.
	+
	+	To overcome these issues, a complete rewrite of the extension has long been wanted. But it didn't come into reality because there was no good Unicode library. Now that ICU is stable and we already relies on it (intl in 5.3), why not make it happen?
	+
	+	===== Preliminary stuff =====
	+
	+	It is currently hosted by GitHub.
	+
	+	http://github.com/moriyoshi/mbstring-ng/
	+
	+	==== Implemented functions ====
	+	* mb_convert_encoding()
	+	* mb_detect_encoding()
	+	* mb_ereg()
	+	* mb_ereg_replace()
	+	* mb_internal_encoding()
	+	* mb_list_encodings()
	+	* mb_output_handler()
	+	* mb_parse_str()
	+	* mb_preferred_mime_name()
	+	* mb_regex_set_options()
	+	* mb_split()
	+	* mb_strcut()
	+	* mb_strimwidth()
	+	* mb_stripos()
	+	* mb_stristr()
	+	* mb_strlen()
	+	* mb_strpos()
	+	* mb_strripos()
	+	* mb_strrpos()
	+	* mb_strstr()
	+	* mb_strtolower()
	+	* mb_strtotitle()
	+	* mb_strtoupper()
	+	* mb_strwidth()
	+	* mb_substr()
	+	* mb_substr_count()
	+
	+	==== Removed (deprecated) functions and reasons behind it ====
	+	* mb_check_encoding() -- Not that usable as it is advertised, period. First of all, validation in terms of encoding is just as same as filtering through the converter supplied with the same value for the input and output encoding. Thus just use mb_convert_encoding().
	+	* mb_convert_case() -- Use mb_strtoupper(), mb_strtolower() and mb_strtotitle()
	+	* mb_convert_kana() -- This can't be standard-compliant. In addition, part of the functionality is already covered by Normalizer of intl extension, so we need to carefully consider what is actually needed here again.
	+	* mb_convert_variables() -- This can be implemented as a script.
	+	* mb_decode_mimeheader() and mb_encode_mimeheader() -- Non-standard compliancy.
	+	* mb_decode_numericentity() -- Removed in favor of html_entity_decode().
	+	* mb_encode_numericentity() -- Removed in favor of htmlentities() and htmlspecialchars().
	+	* mb_encoding_aliases() -- Just unnecessary.
	+	* mb_ereg_match() -- Use mb_ereg()
	+	* mb_ereg_search(), mb_ereg_search_getpos(), mb_ereg_search_getregs(), mb_ereg_search_init(), mb_ereg_search_pos(), mb_ereg_search_regs() and mb_ereg_search_setpos() -- I rarely heard a script that actively uses these functions. They involve an internal state that is not visible to users, and thus it most likely causes confusion when used across the function calls. Need to be reimplemented as a class.
	+	* mb_eregi() -- Use mb_regex_options() and mb_ereg()
	+	* mb_eregi_replace() -- I wonder why this function was added in the first place because giving 'i' option to mb_ereg_replace() works in the same way.
	+	* mb_detect_order(), mb_get_info(), mb_http_input(), mb_http_output(), mb_language() and mb_substitute_character() -- ini_set() and ini_get() are your friends, I guess...
	+	* mb_regex_encoding() -- It is really confusing that the current mbstring allows two different encoding defaults for regex functions and the rest. Those settings are unified in the alternative version and so this is no longer necessary.
	+	* mb_send_mail() -- The behavior of this function relies on the pseudo-locale setting called "mbstring.language" that supports just a limited set of possible locales. As not everyone can benefit from the function and most significant applications implement their own mail functions, I suppose this is no longer wanted.
	+	* mb_strrchr() -- Use mb_strrpos().
	+	* mb_strrichr() -- Use mb_strripos().
	+
	+	==== Known / remaining limitations and incompatibilities ====
	+
	+	* mb_detect_encoding() doesn't work well anymore due to the inaccuracy of ICU's encoding detection.
	+	* Request encoding translator now takes advantage of SAPI filter, therefore the name parts of the query components are not to be converted anymore.
	+	* The features supported by ICU's regular expression engine is not as rich as of Oniguruma, which resulted in the reduced set f options for mb_regex_set_options(). With respect to this, I also extracted the regex functions from the former mbstring and repackaged it to be [[http://github.com/moriyoshi/php-oniguruma/tree/master\|oniguruma extension]]
	+	* The group reference placeholders for mb_ereg_replace() is now $0, $1, $2... instead of \0, \1, \2. This can be avoided if we don't use uregex_replaceAll() and implement our own.
	+	* ILP64 :-P
	+
	+	===== Changelog =====
	+
	+	- 2009-07-27 Moriyoshi Koizumi: Initial

rfc:array_count_handlers

2008-07-09T21:41:19+00:00

1215000160		current
Line 3:		Line 3:
	* Date: 2008-06-25		* Date: 2008-06-25
	* Author: Etienne Kneuss <colder@php.net>		* Author: Etienne Kneuss <colder@php.net>
-	* Status: Draft	+	* Status: Implemented

rfc:autoload_include

2009-11-22T17:04:44+00:00

1258909484		current
Line 55:		Line 55:

	However Stas notes that this would "this would break security distinction between file ops and include ops, when URLs are allowed for open but not include", but Greg notes this should be solvable since "the wrapper used to open the file pointer is stored in the resource, so we can just check it against the same restrictions we would for static urls". That being said Stas additionally notes that this could pose challenges for byte code caches since they would have to "watch all file opens, in case some of these will later be used for include" as well as "somehow be able to get filename back from open stream to get the cached file".		However Stas notes that this would "this would break security distinction between file ops and include ops, when URLs are allowed for open but not include", but Greg notes this should be solvable since "the wrapper used to open the file pointer is stored in the resource, so we can just check it against the same restrictions we would for static urls". That being said Stas additionally notes that this could pose challenges for byte code caches since they would have to "watch all file opens, in case some of these will later be used for include" as well as "somehow be able to get filename back from open stream to get the cached file".
-
	==== Add function to resolve the include path ====		==== Add function to resolve the include path ====

-	Either add a "use_include_path" flag to file_exists() or add a new file_find() function that supports searching the include path and returns the absolute path to the first match or false if none could be found. The later would be superior since it would also enable the optional feature mentioned above. It would still however require file system access twice, though it would only have to resolve the include path once. It also does not solve the edge case of a race condition, which however seems very rare for files that are included via autoload. There is actually already an implementation which was put into HEAD aka PHP6 as the result of a [[http://devzone.zend.com/node/view/id/1514#Heading7\|previous discussion]]. That being said the current implementation needs some tweaks as Greg points out:	+	Either add a "use_include_path" flag to file_exists() or add a new file_find() function that supports searching the include path and returns the absolute path to the first match or false if none could be found. The later would be superior since it would also enable the optional feature mentioned above. It would still however require file system access twice, though it would only have to resolve the include path once. It also does not solve the edge case of a race condition, which however seems very rare for files that are included via autoload. There is actually already an implementation which was put into HEAD aka PHP6 as the result of a [[http://devzone.zend.com/node/view/id/1514#Heading7\|previous discussion]].
		+
		+	That being said the current implementation needs some tweaks as Greg points out:
	"stream_resolve_include_path() as currently constructed could not be intercepted, and is actually unable to process an include_path that contains streams. I'm guessing it was written long before PHP 5.3. This could be easily fixed by having stream_resolve_include_path call zend_resolve_path() instead of doing its own internal calculations. With these changes, an opcode cache could easily cache the results."		"stream_resolve_include_path() as currently constructed could not be intercepted, and is actually unable to process an include_path that contains streams. I'm guessing it was written long before PHP 5.3. This could be easily fixed by having stream_resolve_include_path call zend_resolve_path() instead of doing its own internal calculations. With these changes, an opcode cache could easily cache the results."

	===== Changelog =====		===== Changelog =====

rfc:automatic_get_set_methods

2008-12-16T19:49:23+00:00

	current
Line 1:	Line 1:
	+	====== Request for Comments: Automatic get/set methods for objects ======
	+	* Version: 1.0
	+	* Date: 2008-12-16
	+	* Author: Michael Kimsal <michael@kimsal.com>
	+	* Status: Under Discussion
	+	* First Published at: http://wiki.php.net/rfc/automatic_get_set_methods
	+
	+
	+	===== Introduction =====
	+
	+	Currently, PHP only allows for defining functionality during access to properties on an object when those properties are not defined in the class. This proposal will outline a suggested change to PHP's behaviour when dealing with object properties which will allow for compact code when necessary, and easy refactoring of code when necessary with a minimum of fuss.
	+
	+	===== Proposal version 1 =====
	+
	+	When a class is initialized at runtime, each property will have a 'get' and a 'set' method created for it which will handle basic 'get/set' functionality. If a get or set method exists for the given property, then the corresponding auto-generated method would not be auto-generated.
	+
	+	===== Proposal version 2 =====
	+
	+	When a property on an object is attempted to be read, the PHP engine will look for a corresponding getXXX() method for the given property. If one exists, that methods will be executed. If not, the property will be returned (subject the public/protected/private visibility). Similarly, when a property on an object is attempted to be set, the PHP engine will look for a corresponding setXXX() method. If one exists, that method will be executed. Otherwise, the property will be set normally (subject to public/protected/private visibility).
	+
	+
	+	===== Benefits =====
	+
	+	This will allow for standard PHP code with property access logic to be written without the need for writing corresponding boilerplate get/set methods up front. Only when non-standard or extra logic needs to be applied to a property during reading or writing would get/set methods for those properties need to be written. This will reduce code size and make it more clear that 'out of the ordinary' logic is happening in the given code.
	+
	+	Also, when dealing with existing classes that are not written with traditional get/set methods for each property, this proposed change would make it easier to add in new functionality without the need for extensive refactoring of code that's using the classes in question. For example, rather than needing to update code such as $calendar->dayOfWeek to be $calendar->getDayOfWeek() in the calling code, the code using the calendar library can remain untouched, and a getDayOfWeek() method can be added to the calendar class, introducing some extra functionality in the calculation of the day of the week (in this example).
	+
	+
	+	===== Changelog =====
	+	Initial draft. Full idea not fleshed out entirely with code examples yet.
	+

rfc:backslashnamespaces

2008-10-25T13:54:52+00:00

1224942892		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.

rfc:better_benchmarks

2009-07-20T13:10:13+00:00

1248095392		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 =====

rfc:boxingandunboxing

2009-07-06T16:22:41+00:00

1246897105		current
Line 17:		Line 17:
	The most obvious use for boxing is function and method type hints. The object type hints could be used to do implicit boxing of variables. Either a new magic method (''<nowiki>__</nowiki>box'' for example) or a new interface (''Boxable'' for example) would need to be added to PHP. The boxing method would accept the scalar value and set its internal representation (similar to ''<nowiki>__</nowiki>wakeup''). The method could either return false (and let PHP handle the failure) or throw an exception (''BoxingException'' for example) when the supplied value is not valid for the boxing operation.		The most obvious use for boxing is function and method type hints. The object type hints could be used to do implicit boxing of variables. Either a new magic method (''<nowiki>__</nowiki>box'' for example) or a new interface (''Boxable'' for example) would need to be added to PHP. The boxing method would accept the scalar value and set its internal representation (similar to ''<nowiki>__</nowiki>wakeup''). The method could either return false (and let PHP handle the failure) or throw an exception (''BoxingException'' for example) when the supplied value is not valid for the boxing operation.

-	It would be best for PHP to include as many object versions of scalar types as possible. The boxing functionality could be added to the SPL Types (([[http://.php.net/manual/en/book.spl-types.php\|SPL Types]])) to provide for standard representations of the scalar types. The power to box variables would also be available in userland classes.	+	It would be best for PHP to include as many object versions of scalar types as possible. The boxing functionality could be added to the SPL Types (([[http://php.net/manual/en/book.spl-types.php\|SPL Types]])) to provide for standard representations of the scalar types. The power to box variables would also be available in userland classes.

	It could also be possible to try to perform implicit conversions from one object type to another, but the overhead of this feature may be too much. Consider it as an option only.		It could also be possible to try to perform implicit conversions from one object type to another, but the overhead of this feature may be too much. Consider it as an option only.

rfc:calltimebyref

2009-02-19T17:44:50+00:00

1211376592		current
Line 16:		Line 16:
	Before PHP 4.0 was released, ''allow_call_time_pass_reference'' was introduced as a means of retaining back compatibility with PHP 3, at the point where returning by reference from a function declaration became possible [1]. By default, the INI switch has been On since inception [2]. The warning (formerly ''E_COMPILE_WARNING'' but currently ''E_DEPRECATED'') is only thrown if the INI switch is Off. You therefore need to explicitly switch off the directive in order to discover that the behaviour is deprecated.		Before PHP 4.0 was released, ''allow_call_time_pass_reference'' was introduced as a means of retaining back compatibility with PHP 3, at the point where returning by reference from a function declaration became possible [1]. By default, the INI switch has been On since inception [2]. The warning (formerly ''E_COMPILE_WARNING'' but currently ''E_DEPRECATED'') is only thrown if the INI switch is Off. You therefore need to explicitly switch off the directive in order to discover that the behaviour is deprecated.

-	At the time ''allow_call_time_pass_reference'' was introduced, php.ini-recommended was interestingly referred to as 'php.ini-optimized'. Over the years, it has become fairly standard to regard php.ini-recommended as 'production settings'; things like ''display_errors=Off'' and ''log_errors=On'' have helped this perception along. For the last 8 years, therefore, the first anyone is likely to have known about their code being less than kosher is when it went live.	+	At the time ''allow_call_time_pass_reference'' was introduced, php.ini-recommended was interestingly referred to as 'php.ini-optimized'. Over the years, it has become fairly standard to regard php.ini-recommended as 'production settings'; things like ''display_errors=Off'' and ''log_errors=On'' have helped this perception along. From inception, ''allow_call_time_pass_reference'' was switched ''Off'' in php.ini-recommended but ''On'' in php.ini-dist and by default. For the last 8 years, therefore, the first anyone is likely to have known about their code being less than kosher is when it went live.

	Even in the current php.ini-recommended, the switch is attributed only to 'Code cleanliness'. The full entry in the heading about changed settings reads:		Even in the current php.ini-recommended, the switch is attributed only to 'Code cleanliness'. The full entry in the heading about changed settings reads:

rfc:class_casting_to_scalar

2008-12-09T15:49:31+00:00

1227529727		current
Line 39:		Line 39:

	* None yet		* None yet
		+
		+	==== Bugs ====
		+
		+	* When used with math operators, it seems we have to cast to integer if not explictly requested in the code. TODO: find a way to force our way with a float value if needed

	===== Changelog =====		===== Changelog =====

rfc:class_posing

2009-01-10T10:44:04+00:00

1218955732		current
Line 1:		Line 1:
	====== Request for Comments: Class Posing ======		====== Request for Comments: Class Posing ======
-	* Version: 1.0	+	* Version: 1.0.1
-	* Date: 2008-08-17	+	* Date: 2009-01-10
	* Author: Sebastian Bergmann <sb@sebastian-bergmann.de>		* Author: Sebastian Bergmann <sb@sebastian-bergmann.de>

Line 15:		Line 15:

	==== Use Cases for Class Posing ====		==== Use Cases for Class Posing ====
		+
		+	=== Extending a class and have other classes use the extended class ===
		+
		+	Sometimes when you extend a class it would be nice if classes related to the extended class would return objects of the extended class. Consider the following example:
		+
		+	<code php>
		+	<?php
		+	class MyReflectionMethod extends ReflectionMethod
		+	{
		+	public function getSource()
		+	{
		+	$file = file($this->getFileName());
		+	$result = '';
		+	$start = $this->getStartLine() - 1;
		+	$end = $this->getEndLine() - 1;
		+
		+	for ($line = $start; $line <= $end; $line++) {
		+	$result .= $file[$line];
		+	}
		+
		+	return $result;
		+	}
		+	}
		+	?>
		+	</code>
		+
		+	The code above can be uses just fine like this:
		+
		+	<code php>
		+	<?php
		+	$method = new MyReflectionMethod('className', 'methodName');
		+	?>
		+	</code>
		+
		+	''ReflectionClass::getMethod()'', for instance, still returns an object of ''ReflectionMethod'', making it tedious to work with the extended class.
		+
		+	=== Unit Testing and Mock Objects ===

	In a unit test, mock objects can simulate the behavior of complex, real (non-mock) objects and are therefore useful when a real object is difficult or impossible to incorporate into a unit test.		In a unit test, mock objects can simulate the behavior of complex, real (non-mock) objects and are therefore useful when a real object is difficult or impossible to incorporate into a unit test.
Line 133:		Line 170:
	====== Changelog ======		====== Changelog ======
	* 2008-08-17 Sebastian Bergmann: Initial version.		* 2008-08-17 Sebastian Bergmann: Initial version.
		+	* 2009-01-10 Sebastian Bergmann: Added additional use case.

rfc:closures

2008-08-11T19:06:08+00:00

1228236384		current
Line 172:		Line 172:

	=== Interaction with OOP ===		=== Interaction with OOP ===
		+
		+	$this support has been removed, see [[rfc/closures/removal-of-this\|removal of this]]

	If a closure is defined inside an object, the closure has full access to the current object through $this (without the need to import it explicitly) and all private and protected methods of that class. This also applies to nested closures. Example:		If a closure is defined inside an object, the closure has full access to the current object through $this (without the need to import it explicitly) and all private and protected methods of that class. This also applies to nested closures. Example:

rfc:customfactories

2009-11-18T17:22:26+00:00

1258557639		current
Line 120:		Line 120:

	Now "Foo" does not depend on any specific implementation, neither on an actual ObjectFactory nor on a specific Email implementation. But this comes with a price: At most places where the "new" operator would usually be used to instantiate classes, the ObjectFactory or some other kind of factory needs to be called. If the mechanism of Dependency Injection is consequently used, this results in a lot of additional typing and many classes will need the ObjectFactory getting injected by the surrounding framework.		Now "Foo" does not depend on any specific implementation, neither on an actual ObjectFactory nor on a specific Email implementation. But this comes with a price: At most places where the "new" operator would usually be used to instantiate classes, the ObjectFactory or some other kind of factory needs to be called. If the mechanism of Dependency Injection is consequently used, this results in a lot of additional typing and many classes will need the ObjectFactory getting injected by the surrounding framework.
-
	===== Proposal =====		===== Proposal =====

Line 153:		Line 152:
	class Foo {		class Foo {
	public function bar() {		public function bar() {
		+	// Instantiate by class name:
		+	$email = new Email();
		+	// or even instantiate by interface name (the factory needs to find the right implementation):
	$email = new EmailInterface();		$email = new EmailInterface();
	}		}
Line 174:		Line 176:
	[2] Robert Lemke, "FLOW3 Object Framework"		[2] Robert Lemke, "FLOW3 Object Framework"
	http://flow3.typo3.org/documentation/manuals/flow3/flow3.objectframework/		http://flow3.typo3.org/documentation/manuals/flow3/flow3.objectframework/
-

rfc:dtrace

2009-07-20T13:06:57+00:00

1248095145		current
Line 3:		Line 3:
	* Date: 2009-07-14		* Date: 2009-07-14
	* Author: David Soria Parra <david.soriaparra@sun.com>		* Author: David Soria Parra <david.soriaparra@sun.com>
-	* Status: Accepted	+	* Status: Implemented
	* First Published at: http://wiki.php.net/rfc/dtrace		* First Published at: http://wiki.php.net/rfc/dtrace
	* Patch: http://patches.experimentalworks.net/dtrace.patch		* Patch: http://patches.experimentalworks.net/dtrace.patch

rfc:e-user-deprecated-warning

2008-07-21T09:46:50+00:00

1216418710		current
Line 3:		Line 3:
	* Date: 2008-07-18		* Date: 2008-07-18
	* Author: Lars Strojny <lstrojny@php.net>		* Author: Lars Strojny <lstrojny@php.net>
-	* Status: Under Discussion	+	* Status: Accepted
	* First Published at: http://wiki.php.net/rfc/e-user-deprecated-warning		* First Published at: http://wiki.php.net/rfc/e-user-deprecated-warning

rfc:errors_as_exceptions

2009-07-24T13:23:03+00:00

	current
Line 1:	Line 1:
	+	====== Request for Comments: Exceptions instead of Errors ======
	+	* Version: 1.0
	+	* Date: 2009-07-24
	+	* Author: Ben Scholzen <mail@dasprids.de>
	+	* Status: Under Discussion
	+	* First Published at: http://wiki.php.net/rfc/errors_as_exceptions
	+
	+	This RFC will discuss the usage of exceptions instead of the usual, not catchable, errors.
	+
	+	===== Introduction =====
	+
	+	Exceptions are a proper way of handling errors and are used in many other languages exclusivley.
	+
	+	==== Why do we need exceptions instead of errors? ====
	+
	+	Currently it is not easy to work around expected errors comming from PHP. This does not include errors like E_NOTICE or E_DEPRECATED, but mainly E_WARNING. We frequently notice this problem in the Zend Framework, where it either is bad to performance to use the shut-up-operator (@) and/or there is just no other way instead of supressing an error.
	+
	+	===== Common Misconceptions =====
	+
	+	When, for instance, loading an XML file with simplexml_load_file(), it will throw an E_WARNING when the XML is not valid. When the XML is comming from an external source, you can never be sure beforehand if it will be valid or not, so the only thing you can currently do is supressing the error and checking for the return-value "false". This error supression not only costs time, but also avoids to check for the type of the error (may it be an invalid XML itself, the XML not conforming to the defined DTD or something else). Another example would be fsockopen(), which, when it times out, not only returns false, but also throws an E_WARNING again.
	+
	+	In all those cases it would be a prefered way to be able to simply catch the error as an exception.
	+
	+	===== Proposal and Patch =====
	+
	+	All E_WARNINGS should be replaced by exceptions (preferably, ErrorException). An alternative to keep BC would be to allow the try/catch block to also catch errors (either only E_WARNINGS or also other error levels). In that case, error_reporting() set to 0 should not stop the try/catch block to catch that error.
	+
	+	==== More about Exceptions ====
	+
	+	http://de3.php.net/error_exception
	+
	+	===== Changelog =====
	+
	+

rfc:extdep

2009-02-18T22:32:07+00:00

1234996209		current
Line 12:		Line 12:
	Describe how we could implement an extension dependency system to prevent system errors (symbol not found) and to avoid complex changes for the developers and users. The goal is to keep a single line in the config.* files, using the ADD_EXTENSION_DEP macro.		Describe how we could implement an extension dependency system to prevent system errors (symbol not found) and to avoid complex changes for the developers and users. The goal is to keep a single line in the config.* files, using the ADD_EXTENSION_DEP macro.

-	==== Why do we need RFCs? ====	+

	===== Common Misconceptions =====		===== Common Misconceptions =====

rfc:extensionsiberia

2008-04-14T18:44:18+00:00

1208198450		current
Line 1:		Line 1:
-	Siberia, the graveyard for PHP Extensions	+	Siberia, the cemetery for PHP Extensions

	TBW		TBW

rfc:functional-elements

2008-03-17T09:38:18+00:00

1205746698		current
Line 57:		Line 57:
	=== UC-2: Iterating over an aggregation of objects and keeping the results ===		=== UC-2: Iterating over an aggregation of objects and keeping the results ===
	<code php>		<code php>
-	$result = new CallIterator($list, 'method'));	+	$result = iterate(new CallIterator($list, 'method'), true);
	</code>		</code>

rfc:functionarraydereferencing

2009-05-02T05:48:35+00:00

1213651936		current
Line 1:		Line 1:
	====== Function Array Dereferencing (FAD) ======		====== Function Array Dereferencing (FAD) ======
-	* Version: 0.1	+	* Version: 0.2
-	* Date: June 16, 2008	+	* Date: June 16, 2008 (added)
		+	* Date: May 01, 2009 (declined)
	* Author: Philip Olson <philip@roshambo.org>		* Author: Philip Olson <philip@roshambo.org>
-	* Status: Information Gathering	+	* Status: Declined

	===== Introduction =====		===== Introduction =====

-	This RFC is incomplete and [currently] exists as a historical record for the discussion of this feature request.	+	Note: This RFC was given the "declined" status because it was never implemented or strongly desired. However, no official discussion exists to "decline" except CVS does not lie, and it's not in CVS.
		+
		+	This RFC is incomplete and exists as a historical record for the discussion of this feature request.

	===== Proposal and Patch =====		===== Proposal and Patch =====

rfc:functiongetentropy

2009-03-16T01:19:12+00:00

1228013347		current
Line 21:		Line 21:
	<?php		<?php
	$nonce = unpack('h', getEntropy(128));		$nonce = unpack('h', getEntropy(128));
-	echo '<input type="hidden" name="csrf" value="' . $nonce . '">;	+	echo '<input type="hidden" name="csrf" value="' . $nonce . '">';
	$_SESSION['csrf'] = $nonce;		$_SESSION['csrf'] = $nonce;
	</code>		</code>

rfc:heredoc-with-double-quotes

2008-06-25T16:45:36+00:00

1207563768		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]]	+	* Status: [[http://news.php.net/php.zend-engine.cvs/6597\|Accepted]] (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

rfc:horizontalreuse

2009-10-15T18:42:21+00:00

1252159866		current
Line 961:		Line 961:
	}		}
	?>		?>
		+	</code>
		+
		+	==== Scala Synthax and practical example ====
		+
		+	This is inpired from [[http://www.scala-lang.org/node/117]].
		+
		+	<code php>
		+	trait User_Comments
		+	{
		+	function addComment($c)
		+	{
		+	$db = App::getDb();
		+	$db->Execute("INSERT INTO user_comments (type, type_id, user_id, text)VALUES ($c->type, $c->type_id, $c->uid, $c->text)");
		+	}
		+
		+	function getComments($filter)
		+	{
		+	return array();
		+	}
		+
		+	function removeComment($id)
		+	{
		+	$db = App::getDb();
		+	$db->Execute("DELETE FROM user_comments ... ");
		+	}
		+	}
		+
		+	class App_Email with User_Comments {}
		+
		+	class App_Document with User_Comments {
		+
		+	function removeComment($id)
		+	{
		+	$db = App::getDb();
		+	$db->Execute("DELETE FROM user_comments ... ");
		+
		+	$db->Execute("UPDATE app_documents SET comments_count = ... ");
		+	}
		+	}
		+	// PHP notice : 'User_Comments::removeComment() definition skipped in App_Document'
		+
		+	$doc = new App_Document;
		+
		+	echo is_a($doc, 'App_Document'); // true
		+	echo is_a($doc, 'User_Comments'); // false
		+	echo is_with($doc, 'User_Comments'); // true
		+	</code>
		+
		+	We deal with conflicting class definitions by simply ignoring them.
		+
		+	<code php>
		+	trait Conflict_Comments
		+	{
		+	function removeComment($id)
		+	{
		+	return false;
		+	}
		+	}
		+
		+	class App_Document_Conflict with User_Comments, Conflict_Comments {
		+
		+	function removeComment($id)
		+	{
		+	$db = App::getDb();
		+	$db->Execute("DELETE FROM user_comments ... ");
		+
		+	$db->Execute("UPDATE app_documents SET comments_count = ... ");
		+	}
		+	}
		+	// PHP notice : 'User_Comments::removeComment() definition skipped in App_Document_Conflict'
		+	// PHP notice : 'Conflict_Comments::removeComment() definition skipped in App_Document_Conflict'
		+
		+	$doc = new App_Document_Conflict;
		+
		+	echo is_a($doc, 'App_Document_Conflict');// true
		+	echo is_with($doc, 'User_Comments'); // true
		+	echo is_with($doc, 'Conflict_Comments'); // true
	</code>		</code>

rfc:ifsetor

2008-06-22T08:01:30+00:00

1230742513		current
Line 139:		Line 139:
	- The default value can be omitted in which case NULL will be used.		- The default value can be omitted in which case NULL will be used.

-	http://marcus-boerger.de/php/ext/ze2/ze2-ifsetor-20040901.diff.txt	+	http://php.net/~helly/ze2-ifsetor-20040901.diff.txt

	===== Rejected Features =====		===== Rejected Features =====

rfc:invokable

2008-08-02T16:12:10+00:00

1217693463		current
Line 13:		Line 13:
	Currently, there is no sane way to detect whether an object can be invoked or not. What this RFC proposes is an interface that covers %%__invoke()%%:		Currently, there is no sane way to detect whether an object can be invoked or not. What this RFC proposes is an interface that covers %%__invoke()%%:

		+	<code php>
	interface Invokable {		interface Invokable {
	public function __invoke($args);		public function __invoke($args);
Line 25:		Line 25:
	/* ... */		/* ... */
	}		}
		+	</code>
	And make $obj(); possible only if the interface is implemented, and not only the method.		And make $obj(); possible only if the interface is implemented, and not only the method.
	We have other examples of magic features that are covered by interfaces, like ArrayAccess or Iterator/Traversable.		We have other examples of magic features that are covered by interfaces, like ArrayAccess or Iterator/Traversable.

rfc:iteration-tools

2008-11-03T14:57:52+00:00

1225724618		current
Line 27:		Line 27:
	==== Why do we need tools for iteration ====		==== Why do we need tools for iteration ====

-	Given that iteration is such a recurrent situation and conforming to the DRY principle, but also in total respect with common sense, an abstraction is required. Thankfully, patterns regarding iteration were observed almost fourty years ago by some very smart people. These people found out that iterative processes can be abstracted away in a handful of functions.	+	Given that iteration is such a recurrent situation and conforming to the DRY principle, but also in total respect with common sense, an abstraction is required. Thankfully, patterns regarding iteration were observed almost forty years ago by some very smart people. These people found out that iterative processes can be abstracted away in a handful of functions.
	For example:		For example:
	* some of the functions modify data in the set		* some of the functions modify data in the set
Line 44:		Line 44:
	While these classes do their job they have some shortcomings:		While these classes do their job they have some shortcomings:
	* They only iterate over Traversables. Supporting arrays would be nice (Indeed, we have array_map(), array_walk() and some other similar functions for array processing, yet, I think we should unify these similar tools. Not to mention that array_* functions do not adhere to some param order standard.		* They only iterate over Traversables. Supporting arrays would be nice (Indeed, we have array_map(), array_walk() and some other similar functions for array processing, yet, I think we should unify these similar tools. Not to mention that array_* functions do not adhere to some param order standard.
-	* FilterIterator, RecursiveFilterIterator and SearchIterator require declaration of an aditional classes that extend them	+	* FilterIterator, RecursiveFilterIterator and SearchIterator require declaration of an additional classes that extend them
	* CallbackFilterIterator, although I haven't had the chance to use it, it misses one important thing. It's not passing the iterator itself as a third parameter to the callback.		* CallbackFilterIterator, although I haven't had the chance to use it, it misses one important thing. It's not passing the iterator itself as a third parameter to the callback.

Line 147:		Line 147:
	</code>		</code>

-	While the 1.2 example is very similar to 2.1 it differs from it in that it's not passing the iterator to the callback function and, of course, the fact that I use a function instead of an object. Another difference is that present implementation of CallbackFilterIterator (as documented on http://www.php.net/~helly/php/ext/spl/) may also be used as a virtual CallbackMapIterator. For example, it's not only filtering the elements of the iterator into a new iterator, but it MAY also change those values. In my proposal, the function that changes values is map() which translates a certain value to another depending on the callback function. filter() only keeps items that validate agains certain criteria inside the callback function. I believe a clear distinction between these features must be reflected in the API, thus two different functions in my proposal.	+	While the 1.2 example is very similar to 2.1 it differs from it in that it's not passing the iterator to the callback function and, of course, the fact that I use a function instead of an object. Another difference is that present implementation of CallbackFilterIterator (as documented on http://www.php.net/~helly/php/ext/spl/) may also be used as a virtual CallbackMapIterator. For example, it's not only filtering the elements of the iterator into a new iterator, but it MAY also change those values. In my proposal, the function that changes values is map() which translates a certain value to another depending on the callback function. filter() only keeps items that validate against certain criteria inside the callback function. I believe a clear distinction between these features must be reflected in the API, thus two different functions in my proposal.

-	=====Some aditional benefits=====	+	=====Some additional benefits=====
	As you have seen, my proposal includes a function called walk() which does exactly the same thing as a foreach construct. The real useful thing this function provides is the ability to mimic scope inside a foreach block. So, for example:		As you have seen, my proposal includes a function called walk() which does exactly the same thing as a foreach construct. The real useful thing this function provides is the ability to mimic scope inside a foreach block. So, for example:

Line 192:		Line 192:
	Python:		Python:
	* http://www.python.org/doc/2.5.2/tut/node7.html#SECTION007130000000000000000		* http://www.python.org/doc/2.5.2/tut/node7.html#SECTION007130000000000000000
-	* http://www.python.org/doc/2.5.2/lib/itertools-functions.html (these Python package differs quite much from what I have proposed, nevertheles we may extract other useful things from there too)	+	* http://www.python.org/doc/2.5.2/lib/itertools-functions.html (this Python package differs quite much from what I have proposed, nevertheless we may extract other useful things from there too)

rfc:karma-ml

2008-11-07T17:17:40+00:00

	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

rfc:lemon

2008-05-03T15:41:31+00:00

1206409338		current
Line 4:		Line 4:
	* Date: 2008-03-25		* Date: 2008-03-25
	* Author: Etienne Kneuss		* Author: Etienne Kneuss
-	* Status: Open	+	* Status: In the works

	=== Abstract ===		=== Abstract ===

rfc:lsb_parentself_forwarding

2008-11-29T09:42:37+00:00

1216821608		current
Line 7:		Line 7:
	===== Introduction =====		===== Introduction =====

-	This RFC covers the change that occured to Late Static Bindings (LSB) prior to it's first alpha release.	+	This RFC covers the change that occured to Late Static Bindings (LSB) prior to its first alpha release.

	==== Terms and concepts ====		==== Terms and concepts ====

rfc:magicquotes

2008-04-17T01:01:31+00:00

1208394032		current
Line 2:		Line 2:
	* Version: 1.0		* Version: 1.0
	* Date: April 15, 2008		* Date: April 15, 2008
		+	* Last updated: April 16, 2008
	* Author: Philip Olson <philip@roshambo.org>		* Author: Philip Olson <philip@roshambo.org>
	* Status: Under Discussion		* Status: Under Discussion

rfc:managinglisttraffic

2008-11-03T19:37:29+00:00

1225478278		current
Line 8:		Line 8:

	This RFC proposes a way to reduce mailinglist traffic on the internals list without making it impossible for the community to raise their concerns on this vital piece of infrastructure on PHP.net decision making.		This RFC proposes a way to reduce mailinglist traffic on the internals list without making it impossible for the community to raise their concerns on this vital piece of infrastructure on PHP.net decision making.
-
	===== Introduction =====		===== Introduction =====

	So some core developers as well as lurking end users have noted that the traffic on this list prevents them from being able to follow this list. This is obviously a huge problem since this mailinglist is supposed to be our primary discussion and decision making tool.		So some core developers as well as lurking end users have noted that the traffic on this list prevents them from being able to follow this list. This is obviously a huge problem since this mailinglist is supposed to be our primary discussion and decision making tool.

-	I had a chat about this with Zoe, Stephan (of symfony fame) and Pierre at IPC. In this discussion I got the following idea (note that I am listing the names here in order to credit them in this idea, not because they necessarily endorse it):	+	I had a chat about this with Zoe, Stefan (of symfony fame) and Pierre at IPC. In this discussion I got the following idea (note that I am listing the names here in order to credit them in this idea, not because they necessarily endorse it):

	===== Proposal =====		===== Proposal =====
Line 24:		Line 23:

	===== Changelog =====		===== Changelog =====
-
-
-

rfc:mixin

2008-09-11T10:30:50+00:00

1221129050		current
Line 169:		Line 169:

	<code php>		<code php>
-	class_mixin('PHPUnit_Framework_Assert', 'MY_Assert_Methods'); // throws an E_FATAL Error	+	class_mixin('PHPUnit_Framework_Assert', 'MY_Assert_Methods'); // throws an E_ERROR
	</code>		</code>

rfc:namespacecurlies

2008-08-31T13:37:58+00:00

1220189878		current
Line 44:		Line 44:
	- With the new implementation and no blocks, many people expected one namespace per file.		- With the new implementation and no blocks, many people expected one namespace per file.
	- Since fewer files means faster execution, many people simply concatenate PHP scripts. Their expectation is to be able to do this for code that uses namespaces as well.		- Since fewer files means faster execution, many people simply concatenate PHP scripts. Their expectation is to be able to do this for code that uses namespaces as well.
-	- PHP will add [[php.net/phar\|Phar archive]] support and thus does not really require source concatenation any longer.	+	- PHP will add [[http://php.net/phar\|Phar archive]] support and thus does not really require source concatenation any longer.

	* Consistency:		* Consistency:

rfc:namespaceissues

2008-10-16T13:45:18+00:00

1224164718		current
Line 189:		Line 189:
	This will be better for 99% of scripts, as evidenced by the ratio of internal vs. userspace classes (see http://marc.info/?l=php-internals&m=122127176407546&w=2 for detail)		This will be better for 99% of scripts, as evidenced by the ratio of internal vs. userspace classes (see http://marc.info/?l=php-internals&m=122127176407546&w=2 for detail)

-	==== Why Stas's proposed solution doesn't work ====	+	===== Why Stas's proposed solution doesn't work =====

	[[rfc:namespaceref#namespaces_with_functionsconstants\|Stas's proposed solution]] suggests:		[[rfc:namespaceref#namespaces_with_functionsconstants\|Stas's proposed solution]] suggests:

rfc:namespaceref

2008-10-14T22:43:55+00:00

1224019280		current
Line 64:		Line 64:
	* The model is more complex and may be confusing for the new users.		* The model is more complex and may be confusing for the new users.
	* Unqualified name resolutions for classes and functions/constants are slightly different due to the different usage patterns.		* Unqualified name resolutions for classes and functions/constants are slightly different due to the different usage patterns.
		+	* New syntax for static access

	===== See also =====		===== See also =====

rfc:namespaceresolution

2008-11-04T15:27:50+00:00

1225826415		current
Line 3:		Line 3:
	* Date: 2008-10-30		* Date: 2008-10-30
	* Author: Lukas Smith <smith@pooteeweet.org>		* Author: Lukas Smith <smith@pooteeweet.org>
-	* Status: Under Discussion	+	* Status: Accepted
	* First Published at: http://wiki.php.net/rfc/namespaceresolution		* First Published at: http://wiki.php.net/rfc/namespaceresolution

	This RFC discusses the way identifiers inside a namespace are to be resolved that are not fully qualified.		This RFC discusses the way identifiers inside a namespace are to be resolved that are not fully qualified.
		+
	===== Introduction =====		===== Introduction =====

rfc:namespaces-for-internal-classes

2008-06-17T19:25:33+00:00

1213730688		current
Line 54:		Line 54:
	\| FilesystemIterator \| Spl::Iterator::Filesystem \|		\| FilesystemIterator \| Spl::Iterator::Filesystem \|
	\| FilterIterator \| Spl::Iterator::Filter \|		\| FilterIterator \| Spl::Iterator::Filter \|
-	\| GlobIterator \| Spl::Iterator::Filter \|	+	\| GlobIterator \| Spl::Iterator::Glob \|
	\| InfiniteIterator \| Spl::Iterator::Infinite \|		\| InfiniteIterator \| Spl::Iterator::Infinite \|
	\| IteratorIterator \| Spl::Iterator::Iterator \|		\| IteratorIterator \| Spl::Iterator::Iterator \|

rfc:namespaces

2008-09-16T01:47:34+00:00

1221524689		current
Line 108:		Line 108:
	<code>		<code>
	defined('DEBUG'): YES (expect YES)		defined('DEBUG'): YES (expect YES)
-	defined('my::test::ns::DEBUG_2'): NO (expect YES)	+	defined('MY::TEST::NS::DEBUG_2'): NO (expect YES)
	defined('my::test::ns::DEBUG_2'): NO (expect NO)		defined('my::test::ns::DEBUG_2'): NO (expect NO)
	defined('my::test::ns::debug_2'): NO (expect NO)		defined('my::test::ns::debug_2'): NO (expect NO)

rfc:namespaceseparator

2008-10-28T07:26:23+00:00

1225126057		current
Line 34:		Line 34:
	\| IDE compatibility \| +1 \| +1 \| +1 \| +1 \| -1 \| -1 \| +1 \|		\| IDE compatibility \| +1 \| +1 \| +1 \| +1 \| -1 \| -1 \| +1 \|
	\| number of chars \| +1 \| -1 \| -1 \| -1 \| -1 \| -1 \| -1 \|		\| number of chars \| +1 \| -1 \| -1 \| -1 \| -1 \| -1 \| -1 \|
		+
		+	Please note that we did not weigh all criterions evenly. Also we only included choices that we still felt relevant. For example as you can see in the IRC logs at the bottom we had already ruled out "::".

	As such we have decided to go with <code>\</code> as the new namespace separator instead of the current <code>::</code>		As such we have decided to go with <code>\</code> as the new namespace separator instead of the current <code>::</code>

rfc:newinis

2009-02-17T07:05:02+00:00

1235651315		current
Line 1768:		Line 1768:

	</code>		</code>
-
	===== Development INI =====		===== Development INI =====

Line 2342:		Line 2341:
	; Development Value: On		; Development Value: On
	; Production Value: Off		; Production Value: Off
-	http://www.php.net/manual/en/errorfunc.configuration.php#ini.track-errors	+	; http://www.php.net/manual/en/errorfunc.configuration.php#ini.track-errors
	track_errors = On		track_errors = On

Line 3522:		Line 3521:

	</code>		</code>
		+
	===== Changelog =====		===== Changelog =====

rfc:nonbreakabletraits

2008-03-13T22:09:31+00:00

1205446171		current
Line 21:		Line 21:
	- Making an //alias// of the property or method and use either scope.		- Making an //alias// of the property or method and use either scope.
	- //Merging// multiple properties or methods in the class scope.		- //Merging// multiple properties or methods in the class scope.
		+

	===== Keywords Used In Sample Code =====		===== Keywords Used In Sample Code =====
Line 26:		Line 27:
	For all of the code examples, the following keywords were used:		For all of the code examples, the following keywords were used:

-	''trait''	+	''trait'': This keyword is used to mark a trait definition exactly as the ''class'' keyword works for classes.
-	This keyword is used to mark a trait definition exactly as the ''class''	+
-	keyword works for classes.	+	''class'': Same as current PHP keyword.
-	''class''	+
-	Same as current PHP keyword.	+	''include'': Used to include a trait into a class definition
-	''include''	+
-	Used to include a trait into a class definition	+	''private'': This keyword is used in its current PHP sense as well as to mean that a property or method is to retain its //local// trait scope.
-	''private''	+
-	This keyword is used in its current PHP sense as well as to mean that	+	''public'': This keyword is used in its current PHP sense as well as to mean that a property or method is to be used within the scope of the including class.
-	a property or method is to retain its //local// trait scope.	+
-	''public''	+	''as'': Used to //alias// or //merge// a trait into a class.
-	This keyword is used in its current PHP sense as well as to mean that	+
-	a property or method is to be used within the scope of the including	+
-	class.	+
-	''as''	+
-	Used to //alias// or //merge// a trait into a class.	+

rfc:pdonotices

2009-10-13T09:09:03+00:00

1255423307		current
Line 8:		Line 8:
	===== Databases notices =====		===== Databases notices =====

-	The most important Databases have a functionality which	+	The most important Databases have a functionality which returns some notices about the current query. These notices can be raised by the Database engine within a ''CREATE TABLE'', ''UPDATE'' or ''DELETE'' query for instance or by a user function.
-	returns some notices about the current query. These	+
-	notices can be raised by the Database engine within a	+
-	''CREATE TABLE'', ''UPDATE'' or ''DELETE'' query for instance or by	+
-	a user function.	+

-	Generally, notices contain information about the	+	Generally, notices contain information about the parallel executions, about the number of fetched rows or about the performances of the query.
-	parallel executions, about the number of fetched rows or	+
-	about the performances of the query.	+

	===== Get notices in PDO =====		===== Get notices in PDO =====

-	In PDO, notices are stored into a "''notices''" HashTable in	+	In PDO, notices are stored into a "''notices''" HashTable in the "''_pdo_dbh_t''" structure. Notices are inserted into it by each Database's PDO's driver using:
-	the "''_pdo_dbh_t''" structure. Notices are inserted into it	+
-	by each Database's PDO's driver using:	+

-	> ''zend_hash_next_index_insert(dbh->notices, &val, sizeof(zval *), NULL);''	+	<code c>zend_hash_next_index_insert(dbh->notices, &val, sizeof(zval ), NULL);</code>*

-	Where zval is the zval message string and val the	+	Where zval is the zval message string and val the allocated message string.
-	allocated message string.	+

-	This is done if user have specified that he want to	+	This is done if user have specified that he want to fetch notices using the setAttribute or the $option parameter on the PDO constructor.
-	fetch notices using the setAttribute or the $option	+
-	parameter on the PDO constructor.	+
-	* The name of the attribute is: ''PDO::ATTR_LOG_NOTICES''	+
-	* The possible values are:	+
-	- PDO::NOTICES_NONE -- no fetching	+
-	- PDO::NOTICES_ARRAY -- fetching & noticeInfo returning	+
-	value is an array.	+

-	The name of the function that users have use to get	+	* The name of the attribute is: ''PDO::ATTR_LOG_NOTICES''
-	notices is "''noticeInfo''" which returns an ''array'' (when	+	* The possible values are:
-	''PDO::NOTICES_ARRAY'' is the value of	+	* PDO::NOTICES_NONE -- no fetching
-	''PDO::ATTR_LOG_NOTICES''). The name is based on the	+	* PDO::NOTICES_ARRAY -- fetching &amp; noticeInfo returning value as an array
-	&quot;errorInfo" function to be more user-friendly.	+

-	Note: ''noticeInfo'' is a ''PDO'' function, not a ''PDOStatement''	+	The name of the function that users have use to get notices is "''noticeInfo''" which returns an ''array'' (when ''PDO::NOTICES_ARRAY'' is the value of ''PDO::ATTR_LOG_NOTICES''). The name is based on the "errorInfo" function to be more user-friendly.
-	function.	+
		+	Note: ''noticeInfo'' is a ''PDO'' function, not a ''PDOStatement'' function.

	==== Get notices with PostgreSQL ====		==== Get notices with PostgreSQL ====

-	Notices in PostgreSQL are raised in Pl/PgSQL with the	+	Notices in PostgreSQL are raised in Pl/PgSQL with the "''RAISE NOTICE''" command. They can be fetched using a notice processor defined by the "''PQsetNoticeProcessor''" pointing on a "''_pdo_pgsql_notice''" function which insert the message into ''dbh->notices'' like the principle described into the [[#get notices with postgresql\|Get notices in PDO]] part.
-	"''RAISE NOTICE''" command. They can be fetched using a	+
-	notice processor defined by the "''PQsetNoticeProcessor''"	+
-	pointing on a "''_pdo_pgsql_notice''" function which insert	+
-	the message into ''dbh->notices'' like the principle	+
-	described into the [[#get notices with postgresql\|Get notices in PDO]] part.	+

	==== Get notices in MySQL ====		==== Get notices in MySQL ====

-	In MySQL, the working of notices is NOT like PostgreSQL.	+	In MySQL, the working of notices is NOT like PostgreSQL. MySQL raise notices within simple queries like ''UPDATE'' or ''DELETE''. These notices cannot be raised by a user function.
-	MySQL raise notices within simple queries like ''UPDATE'' or	+
-	''DELETE''. These notices cannot be raised by a user	+
-	function.	+

-	In the MySQL C API, there's a function whose purpose is	+	In the MySQL C API, there's a function whose purpose is to get the number of warnings (and notices) for the last
-	to get the number of warnings (and notices) for the last	+	query. This function is ''mysql_warning_count()''\\ [http://dev.mysql.com/doc/refman/5.1/en/mysql-warning-count.html]
-	query. This function is ''mysql_warning_count()''\\	+
-	[http://dev.mysql.com/doc/refman/5.1/en/mysql-warning-count.html]	+

-	If ''mysql_warning_count'' result is greater than or equal	+	If ''mysql_warning_count'' result is greater than or equal to 1, there are warnings and we will get them. To get
-	to 1, there are warnings and we will get them. To get	+	these warning, we have to fetch results of the "SHOW WARNINGS" query.\\ [http://dev.mysql.com/doc/refman/5.1/en/show-warnings.html]
-	these warning, we have to fetch results of the "SHOW	+
-	WARNINGS" query.\\	+
-	[http://dev.mysql.com/doc/refman/5.1/en/show-warnings.html]	+

-	If ''mysql_warning_count() = 0'', we can get the result of	+	If ''mysql_warning_count() = 0'', we can get the result of mysql_info which returns informations about the last
-	mysql_info which returns informations about the last	+	query. If the result of it is different to NULL, put the results into ''dbh->notices''.\\ [http://dev.mysql.com/doc/refman/5.1/en/mysql-info.html]
-	query. If the result of it is different to NULL, put the	+
-	results into ''dbh->notices''.\\	+
-	[http://dev.mysql.com/doc/refman/5.1/en/mysql-info.html]	+


	==== Get notices in Oracle ====		==== Get notices in Oracle ====

-	In Oracle, notices can be raised by ''DBMS_OUTPUT'' within a	+	In Oracle, notices can be raised by ''DBMS_OUTPUT'' within a Pl/SQL function and some notifications are created by the Oracle Server.
-	Pl/SQL function and some notifications are created by	+
-	the Oracle Server.	+

-	"Call ''OCIInitialize()'' with ''OCI_EVENTS'' mode to specify	+	"Call ''OCIInitialize()'' with ''OCI_EVENTS'' mode to specify that the application is interested in registering for and receiving notifications. This starts a dedicated listening thread for notifications on the client."\\ [http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28395/oci09adv.htm#sthref1428]
-	that the application is interested in registering for	+
-	and receiving notifications. This starts a dedicated	+
-	listening thread for notifications on the client."\\	+
-	[http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28395/oci09adv.htm#sthref1428]	+

-	Informations about notification callback which I didn't	+	Informations about notification callback which I didn't understand very much: http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28395/oci09adv.htm#sthref1446
-	understand very much: http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28395/oci09adv.htm#sthref1446	+

	This is about getting notifications from Oracle: http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28395/oci10new.htm#sthref1457		This is about getting notifications from Oracle: http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28395/oci10new.htm#sthref1457

-	Global method for Oracle, in addition of these previous	+	Global method for Oracle, in addition of these previous methods, to get DMBS_OUTPUT:
-	methods, to get DMBS_OUTPUT:	+

-	- Execute &quot;''BEGIN DBMS_OUTPUT.ENABLE(NULL); END;''&quot; when ''PDO::ATTR_LOG_NOTICES'' is turned a value different to ''PDO::NOTICES_NONE''.\\	+	* Execute &lt;code plsql>;BEGIN DBMS_OUTPUT.ENABLE(NULL); END;&lt;/code>; when ''PDO::ATTR_LOG_NOTICES'' is turned a value different to ''PDO::NOTICES_NONE''.\\
-	- After each successful queries, fetch: &quot;''BEGIN DBMS_OUTPUT.GET_LINE(:LN, :ST); END;''&quot; with '':LN'' and '':ST'' two OUT parameters which define the informations and the number of them. \\	+	* After each successful queries, fetch: &lt;code plsql>;BEGIN DBMS_OUTPUT.GET_LINE(:LN, :ST); END;&lt;/code>; with '':LN'' and '':ST'' two OUT parameters which define the informations and the number of them. \\
-	- Execute &quot;''BEGIN DBMS_OUTPUT.DISABLE(); END;''&quot; when ''PDO::ATTR_LOG_NOTICES'' is turned a value equal to ''PDO::NOTICES_NONE''.\\	+	* Execute &lt;code plsql>;BEGIN DBMS_OUTPUT.DISABLE(); END;&lt;/code>; when ''PDO::ATTR_LOG_NOTICES'' is turned a value equal to ''PDO::NOTICES_NONE''.\\

	==== For others Databases ====		==== For others Databases ====

-	For others Databases who have a notice functionality, we	+	For others Databases who have a notice functionality, we have to
-	have to	+
	reflect. Personally, i do not know which Databases...		reflect. Personally, i do not know which Databases...

rfc:pdov1

2009-04-10T17:54:26+00:00

1219185365		current
Line 63:		Line 63:
	==== More about PDO ====		==== More about PDO ====

-	* http://php.net/pdo	+	* http://php.net/pdo (userland manual)
		+	* http://php.net/internals2.pdo (internals manual)

	==== References ====		==== References ====

rfc:peclversioning

2008-08-18T12:49:51+00:00

1216213241		current
Line 1:		Line 1:
	===== Request for Comments: PECL Versioning =====		===== Request for Comments: PECL Versioning =====

-	=== The Problem ===	+	=== History ===
-	Currently, PECL versioning is fairly anarchic. It is 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 a long try-&-fail process. Windows PECL binaries should have reliable version information in the DLL resources (physically visible in the file properties) as well as at runtime (through phpinfo(), phpversion('extname') etc.). Some of the processes in php.net that currently use hard-coded lists could also benefit from a standardized versioning process. This problem has to be fixed to bring PECL to a higher quality and reliability level.	+	PECL versioning has historically been fairly anarchic. 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 a long try-&-fail process. Some of the processes in php.net that currently use hard-coded lists could also benefit from a standardized versioning process.
		+
		+	The base proposal was implemented across PECL by April 2008. Only the question of what to do about PHP extensions that are both in PECL and in the PHP core - and usually symlinked - remains open. //It would be nice to resolve this before the PHP 5.3.0 release!//

	There are actually two RFCs (proposals) to deal with version numbering in PECL and for core PHP extensions in general.		There are actually two RFCs (proposals) to deal with version numbering in PECL and for core PHP extensions in general.

rfc:php_native_interface

2009-05-02T10:29:12+00:00

1243365295		current
Line 92:		Line 92:

	* Project Zero		* Project Zero
-	* Supportive	+	* Supportive (see [[http://wiki.php.net/rfc/remove_zend_api/scratchpad\|remove_zend_api/scratchpad]] for their discussion.
	* phc		* phc
	* Involved		* Involved

rfc:phpvcs

2009-05-17T13:32:45+00:00

1226582820		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]]

rfc:propertygetsetsyntax

2009-09-16T23:01:44+00:00

1253142303		current
Line 133:		Line 133:
	{		{
	get { return seconds / 3600; }		get { return seconds / 3600; }
-	set { seconds = value * 3600; }	+	set { seconds = value * 3600; }// The variable "value" holds the incoming value to be "set"
	}		}
	}		}
Line 162:		Line 162:
	{		{
	get { return $this->seconds / 3600; }		get { return $this->seconds / 3600; }
-	set { $this->seconds = $value * 3600; }	+	set { $this->seconds = $value * 3600; }// The variable $value holds the incoming value to be "set"
	}		}
	};		};

rfc:protectedlookup

2008-06-03T16:09:21+00:00

1212509361		current
Line 177:		Line 177:
	Remove new rule: remove calls to zend_get_function_root_class().		Remove new rule: remove calls to zend_get_function_root_class().
	=== Patch ===		=== Patch ===
-	* [[http://thread.gmane.org/gmane.comp.php.devel/48176/focus=48179\|Patch from Felipe Pena]]	+	* [[http://thread.gmane.org/gmane.comp.php.devel/48176/focus=48179\|Patch from Felipe Pena]]
-	* [[http://www.soal.org/php/protectedrfc/protected_opt1_tests.zip\|Tests]]	+	* [[http://www.soal.org/php/protectedrfc/protected_opt1_tests.zip\|Tests]]
	=== Pros ===		=== Pros ===
	* Simple code change		* Simple code change
Line 212:		Line 212:
	If option 1 is dismissed due to the violation of LSP, it follows that the current rules for property access, callbacks, ''clone()'' and ''destruct()'' are also violations of LSP and should be fixed. This option ensures that ''zend_get_function_root_class()'' is used consistently for all protected method checks, and implements equivalent functionality for protected property checks.		If option 1 is dismissed due to the violation of LSP, it follows that the current rules for property access, callbacks, ''clone()'' and ''destruct()'' are also violations of LSP and should be fixed. This option ensures that ''zend_get_function_root_class()'' is used consistently for all protected method checks, and implements equivalent functionality for protected property checks.
	=== Patch ===		=== Patch ===
-	* [[http://www.soal.org/php/protectedrfc/protected_opt2.diff\|Patch]]	+	* [[http://www.soal.org/php/protectedrfc/protected_opt2.txt\|Patch]]
-	* [[http://www.soal.org/php/protectedrfc/protected_opt2_tests.zip\|Tests]]	+	* [[http://www.soal.org/php/protectedrfc/protected_opt2_tests.zip\|Tests]]
	=== Pros ===		=== Pros ===
	* Respects the Liskov Substitution Principle.		* Respects the Liskov Substitution Principle.
Line 246:		Line 246:
	</code>		</code>
	=== Patch ===		=== Patch ===
-	* Patch to do.	+	* Patch to do.
-	* [[http://www.soal.org/php/protectedrfc/protected_opt3_tests.zip\|Tests]]	+	* [[http://www.soal.org/php/protectedrfc/protected_opt3_tests.zip\|Tests]]
	=== Pros ===		=== Pros ===
	* Respects the Liskov Substitution Principle.		* Respects the Liskov Substitution Principle.

rfc:releaseprocess

2009-03-25T09:27:23+00:00

1237900987		current
Line 1:		Line 1:
-	====== Request for Comments: How to write RFCs ======	+	====== Request for Comments: Releases management and process ======
	* Version: 0.1		* Version: 0.1
	* Date: 2008-03-06		* Date: 2008-03-06

rfc:remove_zend_api

2009-05-12T12:03:13+00:00

1242129752		current
Line 3:		Line 3:
	* Date: 2009-03-27		* Date: 2009-03-27
	* Author: Paul Biggar <paul.biggar@gmail.com>		* Author: Paul Biggar <paul.biggar@gmail.com>
-	* Status: Soliciting comments for 1.1	+	* **Status: Brainstorming: [[http://wiki.php.net/rfc/remove_zend_api/scratchpad]]**
-		+
-	Currently brainstorming about extensions which are tightly integrated with PHP: [[http://wiki.php.net/rfc/remove_zend_api/scratchpad]]	+

	===== Introduction =====		===== Introduction =====

rfc:rounding

2008-12-02T16:45:20+00:00

1219593036		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

rfc:session_upload_progress

2008-09-27T09:29:17+00:00

1222506517		current
Line 84:		Line 84:
	The current patch also allows to cancel an upload by setting the "cancel_upload" key to true in the progress data (e.g. $_SESSION["upload_progress_123"]["cancel_upload"] = true;).		The current patch also allows to cancel an upload by setting the "cancel_upload" key to true in the progress data (e.g. $_SESSION["upload_progress_123"]["cancel_upload"] = true;).

-	Doing so will cancel the currently uploading file, bypass all remaining data (POST variables, uploads, etc), and start to execute the script.	+	Doing so will cancel the currently uploading file, bypass all remaining data (POST variables, uploads, etc). An upload canceled this way will have "error" set to [[http://www.php.net/manual/en/features.file-upload.errors.php\|UPLOAD_ERR_EXTENSION]].

rfc:shortags

2009-04-16T06:44:57+00:00

1207256217		current
Line 3:		Line 3:
	* Date: 2008-04-03		* Date: 2008-04-03
	* Author: Stas Malyshev <stas@php.net>		* Author: Stas Malyshev <stas@php.net>
-	* Status: Under Discussion	+	* Status: Declined
-		+
-		+
-		+
-		+
-		+

rfc:shortsyntaxforarrays

2008-05-30T16:12:24+00:00

1212163944		current
Line 5:		Line 5:
	* First Published at: 2008-01-10		* First Published at: 2008-01-10
	* Last update: 2008-30-05		* Last update: 2008-30-05
-	* Votes (+5/-9):	+	* Votes (+8/-16):
-	* Pro: Andrei Zmievski, Andi Gutmans, Pierre Joye, Rasmus Lerdorf, Stanislav Malyshev	+	* Pro: Andrei Zmievski, Andi Gutmans, Pierre Joye, Rasmus Lerdorf, Stanislav Malyshev, Brian Moon, Kalle Sommer Nielsen, Edin Kadribasic
-	* Contra: Antony Dovgal, Derick Rethans, Jani Taskinen, Lokrain, Felipe Pena, Lukas Kahwe Smith, Marcus Boerger, David Soria Parra, Johannes Schlüter	+	* Contra: Antony Dovgal, Derick Rethans, Jani Taskinen, Lokrain, Felipe Pena, Lukas Kahwe Smith, Marcus Boerger, David Soria Parra, Johannes Schlüter, Maciek Sokolewicz, Philip Olson, Ilia Alshanetsky, Daniel Brown, Jochem Maas, Hannes Magnusson, David Coallier
-	* Userland Votes (+20/-10):	+	* Userland Votes (+17/-3):
-	* Pro: Sebastian Deutsch, Ryusuke Sekiyama, Stefan Marr, Alexey Zakhlestin, Brian Moon, Carl P. Corliss, Darius Jahandarie, Giedrius D, Eric Coleman, Kalle Sommer Nielsen, Max Antonov, Mike Ford, Larry Garfield, Sam Barrow, Taylor Luk, Hans Ahlin, Karoly Negyesi, Edin Kadribasic, Guilherme Blanco, Jonathan-Bond Caron	+	* Pro: Sebastian Deutsch, Ryusuke Sekiyama, Stefan Marr, Alexey Zakhlestin, Carl P. Corliss, Darius Jahandarie, Giedrius D, Eric Coleman, Max Antonov, Mike Ford, Larry Garfield, Sam Barrow, Taylor Luk, Hans Ahlin, Karoly Negyesi, Guilherme Blanco, Jonathan-Bond Caron
-	* Contra: David Coallier, Geoffrey Sneddon, Hannes Magnusson, Tomi Kaistila, David Zühlke, Maciek Sokolewicz, Philip Olson, Ilia Alshanetsky, Daniel Brown, Jochem Maas	+	* Contra: Geoffrey Sneddon, Tomi Kaistila, David Zühlke
	* Note: This list was created by guessing (cvs name vs. real name) who has commit rights - please correct mistakes		* Note: This list was created by guessing (cvs name vs. real name) who has commit rights - please correct mistakes

rfc:spl-namespace

2008-07-21T15:18:03+00:00

1216716622		current
Line 2:		Line 2:
	* Version: 1.0		* Version: 1.0
	* Date: 2008-07-19		* Date: 2008-07-19
-	* Author: Baptiste Autin <fjas.at.free.fr>	+	* Author: Baptiste <fjas.at.free.fr>
-	* Status: Under Discussion	+	* Status: Abandonned
	* First Published at: http://wiki.php.net/rfc/spl-namespace		* First Published at: http://wiki.php.net/rfc/spl-namespace
	* Other formats ..		* Other formats ..

rfc:static-classes

2008-05-10T11:25:21+00:00

1210418193		current
Line 40:		Line 40:
	AbstractStaticClass2::staticMethod(); // Throws error, not allowed. Must be extended first		AbstractStaticClass2::staticMethod(); // Throws error, not allowed. Must be extended first
	</code>		</code>
		+


Line 53:		Line 54:
	* The current behaviour of abstract classes/non-static classes with static members would not change. This is important for backwards compatibility		* The current behaviour of abstract classes/non-static classes with static members would not change. This is important for backwards compatibility
	* ''%%__setStatic()%%'' and ''%%__getStatic()%%'' will provide functionality similiar to ''%%__get()%%'' and ''%%__set()%%''		* ''%%__setStatic()%%'' and ''%%__getStatic()%%'' will provide functionality similiar to ''%%__get()%%'' and ''%%__set()%%''
-	* It **will not be possible to create instances of static** classes	+	* Static classes **cannot be instantiated**
		+	* Static classes can implement interfaces containing only static methods

	===== Code =====		===== Code =====

rfc:streamline-phar-api

2008-03-28T16:02:36+00:00

1206718969		current
Line 28:		Line 28:
	=== Adding isWritable() method ===		=== Adding isWritable() method ===
	== Proposal ==		== Proposal ==
-	Add an isWritable() method to determine whether an archive can be written or not. Not being able to write an archive either means it is disabled in the php.ini (see Phar::canWrite()) or that PHP can't write to the requested location of the phar archive.	+	Add an isWritable() method to determine whether an archive can be written or not. Not being able to write an archive either means it is disabled in the php.ini (see Phar::canWrite()) or that PHP can't write to the requested location of the phar archive. PharFileInfo must overload the method in order to accomplish that.
	== Code ==		== Code ==
	<code php>		<code php>

rfc:svnexternals

2008-07-01T15:33:28+00:00

	current
Line 1:	Line 1:
	+	====== Request for Comments: How to write RFCs ======
	+	* Version: 1.0
	+	* Date: 2008-07-01
	+	* Author: Gwynne Raskind <gwynne@php.net>
	+	* Status: Under Discussion
	+	* First Published at: http://wiki.php.net/rfc/svnexternals
	+
	+	This RFC discusses the ways in which the old CVS modules can be translated into SVN externals.
	+
	+	===== Introduction =====
	+
	+	CVS uses a modules file in CVSROOT to provide aliases and directory grouping. When converting to SVN, there is no immediate equivelant for some of the constructs the old repository uses. There are various alternative possibilities, enumerated here.
	+
	+	===== Grouped modules =====
	+
	+	The most common use of the modules file was creating the "php-src" directory using the php-src module, the TSRM module, and the Zend or ZendEngine2 modules. This is accomplished effectively using an svn:externals property set on the php-src/trunk directory in the SVN repository. Different branches of php-src may use different externals, such as PHP 4 making use of Zend while PHP 5 makes use of ZendEngine2, and PHP 6 may in the future make use of a ZendEngine3 or similar. In practical terms there will never be a need for separate Zend modules in SVN and it might be sensible to merge them together, pasting ZendEngine2's newer data atop Zend's older files and continuing to use a single Zend module.
	+
	+	===== Pseudo-modules =====
	+
	+	The other common use of modules was the creation of pseudo-modules such as phpdoc-ja-only from the phpdoc-ja module, and even more the phpdoc-all module which includes all doc language modules. There is no equivelant to such modules in SVN, but there are several ways to achieve a similar effect:
	+
	+	- Create empty directories in the repository which link to the modules that they contain using svn:externals.
	+	* Pros
	+	* Most like the current system
	+	* Cons
	+	* Ugly, unsupported, and unnecessary.
	+	- Use a single combined phpdoc module and require client checkouts to use SVN 1.5's Sparse Directories feature.
	+	* Pros
	+	* Very clean, keeps the repository neat
	+	* Cons
	+	* Clients must remember to specify the appropriate --depth options or they'll check out much more than intended; sparseness can not be set on the server side
	+	- Maintain the documentation buildsystem and each set of language files separately.
	+	* Pros
	+	* Possibly the cleanest solution possible
	+	* Falls in line with the current line of development for the documentation build system, PhD
	+	* Cons
	+	* Represents a considerable change to the way things currently work
	+	* Requires support from the buildsystem before it can be implemented
	+
	+	===== Proposals that require discussion =====
	+
	+	Here is a summary of decisions that need making:
	+
	+	* Whether or not to merge ZendEngine2 into Zend and use a single Zend module (1/0)
	+	* Which method to use to replace pseudo-modules (1: 0/0; 2: 0/0; 3: 1/0)
	+
	+	===== Changelog =====
	+
	+	2008-07-01: Created

rfc:taint

2008-06-22T19:25:57+00:00

1215475482		current
Line 1:		Line 1:
	====== Taint support for PHP ======		====== Taint support for PHP ======

-	* Author: Wietse Venema (wietse@porcupine.org) \\ IBM T.J. Watson Research Center \\ Hawthorne, NY, USA	+	* Author: [[http://www.porcupine.org/wietse/\|Wietse Venema (wietse@porcupine.org)]] \\ IBM T.J. Watson Research Center \\ Hawthorne, NY, USA
	* Version: 20080622		* Version: 20080622
	* Source code: [[ftp://ftp.porcupine.org/pub/php/php-5.2.5-taint-20080622.tar.gz\|tar.gz]] ([[ftp://ftp.porcupine.org/pub/php/php-5.2.5-taint-20080622.tar.gz.sig\|pgp signature]])		* Source code: [[ftp://ftp.porcupine.org/pub/php/php-5.2.5-taint-20080622.tar.gz\|tar.gz]] ([[ftp://ftp.porcupine.org/pub/php/php-5.2.5-taint-20080622.tar.gz.sig\|pgp signature]])

rfc:template

2008-04-07T10:21:17+00:00

	current
Line 1:	Line 1:
	+	====== Request for Comments: How to write RFCs ======
	+	* Version: 1.0
	+	* Date: 2008-03-06
	+	* Author: Stefan Marr <php.at.stefan-marr.de>, Lukas Smith <smith@pooteeweet.org>
	+	* Status: Under Discussion
	+	* First Published at: http://wiki.php.net/rfc/traits
	+	* Other formats ..
	+
	+
	+	This RFC is a template other people can use to write their own RFCs.
	+
	+	===== Introduction =====
	+
	+	The purpose of RFCs are to work collaboratively towards a specification and finally an implementation of an idea.
	+
	+	==== Why do we need RFCs? ====
	+
	+	They serve to keep a summary of on going discussions. This way people can keep an overview of the state of the discussion. Even if never put into place in the end, they also serve as a historical log of discussions that is much easier to read compared to mailinglist threads.
	+
	+	===== Common Misconceptions =====
	+
	+	RFCs do not in any way replace discussions on the mailing list.
	+
	+	===== Proposal and Patch =====
	+
	+	Nothing needs to be patched here. Just use this template at your discretion.
	+
	+	==== Rejected Features ====
	+
	+	Automated voting system.
	+
	+	==== More about RFCs ====
	+
	+	http://en.wikipedia.org/wiki/Request_for_Comments
	+
	+	===== Changelog =====
	+
	+

rfc:tls

2008-08-26T19:04:37+00:00

1219760920		current
Line 34:		Line 34:
	Unfortunately the TLS model used in these tests was the static model, which is restrictive, and in particular does not allow to use it in shared libraries which will be loaded dynamically. (c.f [[tls#tls_internals\|TLS internals]] bellow).		Unfortunately the TLS model used in these tests was the static model, which is restrictive, and in particular does not allow to use it in shared libraries which will be loaded dynamically. (c.f [[tls#tls_internals\|TLS internals]] bellow).

-	For the PHP module to be able to be loaded at runtime in Apache or an other server with this patch enabled, it has to be built with the static TLS model (on gcc, -ftls-model=global-dynamic), which also requires to build position independent code. While the last makes a big difference on IA-32, this is the default on x86_64 and the results on bench.php on an unpatched PHP are the same as IA-32/PIC builds.	+	For the PHP module to be able to be loaded at runtime in Apache or an other server with this patch enabled, it has to be built with the dynamic TLS model (on gcc, -ftls-model=global-dynamic), which also requires to build position independent code. While the last makes a big difference on IA-32, this is the default on x86_64 and the results on bench.php on an unpatched PHP are the same as IA-32/PIC builds.

	Native TLS can be enabled with %%--with-tsrm-__thread-tls%% or %%--with-tsrm-full__thread-tls%%. The last declares globals statically instead of making them pointers.		Native TLS can be enabled with %%--with-tsrm-__thread-tls%% or %%--with-tsrm-full__thread-tls%%. The last declares globals statically instead of making them pointers.
Line 91:		Line 91:
	===== Windows =====		===== Windows =====

-	Dynamically loaded DLLs can use TLS starting with Windows Vista and Server 2008. But there is a restriction: TLS variables can't be exported, which means that they can't be accessed outside of the DLL. CLI and ISAPI SAPIs works with TLS enabled, but they must be built like this is done on other platforms, with all code embeded in the executable/library. The same apply for extension, they must be built statically in PHP.	+	Dynamically loaded DLLs can use TLS starting with Windows Vista and Server 2008. But there is a restriction: TLS variables can't be exported, which means that they can't be accessed outside of the DLL. CLI and ISAPI SAPIs works with TLS enabled, but they must be built like this is done on other platforms, with all code embeded in the executable/library (instead of a separate php5ts.dll linked by SAPIs). The same apply for extension, they must be built statically in PHP.

	===== TLS internals =====		===== TLS internals =====

rfc:traits

2009-10-15T13:26:21+00:00

1232298209		current
Line 504:		Line 504:

	This section collects proposals for alternative Traits syntaxes.		This section collects proposals for alternative Traits syntaxes.
		+
		+	==== Scala Synthax and practical example ====
		+
		+	This is inpired from [[http://www.scala-lang.org/node/117]].
		+
		+	<code php>
		+	trait User_Comments
		+	{
		+	function addComment($c)
		+	{
		+	$db = App::getDb();
		+	$db->Execute("INSERT INTO user_comments (type, type_id, user_id, text)VALUES ($c->type, $c->type_id, $c->uid, $c->text)");
		+	}
		+
		+	function getComments($filter)
		+	{
		+	return array();
		+	}
		+
		+	function removeComment($id)
		+	{
		+	$db = App::getDb();
		+	$db->Execute("DELETE FROM user_comments ... ");
		+	}
		+	}
		+
		+	class App_Email with User_Comments {}
		+
		+	class App_Document with User_Comments {
		+
		+	function removeComment($id)
		+	{
		+	$db = App::getDb();
		+	$db->Execute("DELETE FROM user_comments ... ");
		+
		+	$db->Execute("UPDATE app_documents SET comments_count = ... ");
		+	}
		+	}
		+	// PHP notice : 'User_Comments::removeComment() definition skipped in App_Document'
		+
		+	$doc = new App_Document;
		+
		+	echo is_a($doc, 'App_Document'); // true
		+	echo is_a($doc, 'User_Comments'); // false
		+	echo is_with($doc, 'User_Comments'); // true
		+	</code>
		+
		+	We deal with conflicting class definitions by simply ignoring them.
		+
		+	<code php>
		+	trait Conflict_Comments
		+	{
		+	function removeComment($id)
		+	{
		+	return false;
		+	}
		+	}
		+
		+	class App_Document_Conflict with User_Comments, Conflict_Comments {
		+
		+	function removeComment($id)
		+	{
		+	$db = App::getDb();
		+	$db->Execute("DELETE FROM user_comments ... ");
		+
		+	$db->Execute("UPDATE app_documents SET comments_count = ... ");
		+	}
		+	}
		+	// PHP notice : 'User_Comments::removeComment() definition skipped in App_Document_Conflict'
		+	// PHP notice : 'Conflict_Comments::removeComment() definition skipped in App_Document_Conflict'
		+
		+	$doc = new App_Document_Conflict;
		+
		+	echo is_a($doc, 'App_Document_Conflict');// true
		+	echo is_with($doc, 'User_Comments'); // true
		+	echo is_with($doc, 'Conflict_Comments'); // true
		+	</code>

	=== Alternative Keywords for use ===		=== Alternative Keywords for use ===

rfc:typechecking

2009-07-03T20:52:46+00:00

1246654315		current
Line 6:		Line 6:
	* [[rfc:typehint\|Return value and parameter type hint]] by Felipe		* [[rfc:typehint\|Return value and parameter type hint]] by Felipe
	* [[rfc:typecheckingstrictandweak\|Strict and weak parameter type checking]] by Lukas		* [[rfc:typecheckingstrictandweak\|Strict and weak parameter type checking]] by Lukas
-	* [[rfc:typecheckingstrictonly\|Optional Strict Type Checking for Scalars]] by Paul	+	* [[rfc:typecheckingstrictonly\|Optional Strict Type Checking for Scalars]] by Paul (Ilia's proposal)

rfc:typecheckingstrictandweak

2009-07-07T06:34:35+00:00

rfc:typecheckingstrictonly

2009-10-22T19:31:15+00:00

1256239875		current
Line 20:		Line 20:

	ReflectionParameter::isInt() - Returns whether parameter MUST be a long		ReflectionParameter::isInt() - Returns whether parameter MUST be a long
		+
	ReflectionParameter::isDouble() -Returns whether parameter MUST be a double		ReflectionParameter::isDouble() -Returns whether parameter MUST be a double
		+
	ReflectionParameter::isBool() - Returns whether parameter MUST be a boolean		ReflectionParameter::isBool() - Returns whether parameter MUST be a boolean
		+
	ReflectionParameter::isObject() - Returns whether parameter MUST be a boolean		ReflectionParameter::isObject() - Returns whether parameter MUST be a boolean
		+
	ReflectionParameter::isString() - Returns whether parameter MUST be a string		ReflectionParameter::isString() - Returns whether parameter MUST be a string
		+
	ReflectionParameter::isResource() - Returns whether parameter MUST be a resource		ReflectionParameter::isResource() - Returns whether parameter MUST be a resource
		+
	ReflectionParameter::getTypeHint() - Returns what type hint is defined for this parameter		ReflectionParameter::getTypeHint() - Returns what type hint is defined for this parameter

rfc:typecheckingweak

2009-07-12T15:43:07+00:00

1247469824		current
Line 116:		Line 116:
	The main 'contender' to this RFC is the Strict Typing RFC. Unlike Type Enforcement, Strict Typing is based on a strict comparison of the zval.type value. As such, it introduces an entirely new semantics to PHP, especially around parameter passing. Today, the zval.type is used only by a handful of functions (is_int() et al, gettype()), and the identity operator. These functions are much more rarely used than their more 'lax' siblings (is_numeric()) which are typically more appropriate; While the identity operator is typically used for specialized cases, e.g. when dealing with a function returning an integer, and having to tell boolean false apart. It is therefore argued that extending a zval.type-based checks into parameter passing - a center-piece of the language - will inadvertently change the theme of the language, and the expected 'lax' type checking behavior expected from it today.		The main 'contender' to this RFC is the Strict Typing RFC. Unlike Type Enforcement, Strict Typing is based on a strict comparison of the zval.type value. As such, it introduces an entirely new semantics to PHP, especially around parameter passing. Today, the zval.type is used only by a handful of functions (is_int() et al, gettype()), and the identity operator. These functions are much more rarely used than their more 'lax' siblings (is_numeric()) which are typically more appropriate; While the identity operator is typically used for specialized cases, e.g. when dealing with a function returning an integer, and having to tell boolean false apart. It is therefore argued that extending a zval.type-based checks into parameter passing - a center-piece of the language - will inadvertently change the theme of the language, and the expected 'lax' type checking behavior expected from it today.

-	In that context, it's important to mention that the two most common sources for data going into PHP - input data (_GET, _POST, etc.) and data coming from the database - are almost exclusively typed as strings. While some do type conversion during the input sanitizing phase - that is not always the case, especially with data coming from the database. Strict Typing is inherently incompatible with this concept, in the sense that it assumes the underlying data type (zval.type) is identical to the semantics of the value. It does not come to say that the two cannot be used together - but they are a pretty bad fit.	+	In that context, it's important to mention that the two most common sources for data going into PHP - input data (_GET, _POST, etc.) and data coming from external resources (e.g. databases, config files, memcached, etc.) - are almost exclusively typed as strings. While some do type conversion during the input sanitizing phase - that is not always the case, especially with data coming from the database. Strict Typing is inherently incompatible with this concept, in the sense that it assumes the underlying data type (zval.type) is identical to the semantics of the value. It does not come to say that the two cannot be used together - but they are a pretty bad fit.

	Furthermore - it is important to notice that the sole difference between Strict Typing and this proposed solution has to do with what happens outside the scope of the type-argumented function. In other words - all the benefits for the function code itself (readability, code reduction, optimization, etc.) is 100.0% identical. The semantics of what happens during the parameter-passing stage is what's different.		Furthermore - it is important to notice that the sole difference between Strict Typing and this proposed solution has to do with what happens outside the scope of the type-argumented function. In other words - all the benefits for the function code itself (readability, code reduction, optimization, etc.) is 100.0% identical. The semantics of what happens during the parameter-passing stage is what's different.

rfc:typehint

2008-04-17T16:59:52+00:00

1208443259		current
Line 4:		Line 4:
	* Author: Felipe Pena <felipensp@gmail.com>		* Author: Felipe Pena <felipensp@gmail.com>
	* Status: [[http://news.php.net/php.internals/37049\|Under Discussion]]		* Status: [[http://news.php.net/php.internals/37049\|Under Discussion]]
		+

	====== Details of implementation ======		====== Details of implementation ======
	Parameter type hint:		Parameter type hint:
-	- The behavior when the default parameter value is ''NULL'' was keeped.	+	- The behavior when the default parameter value is ''NULL'' was kept.
	Both:		Both:
	- Binary and unicode string are specified by ''string''.		- Binary and unicode string are specified by ''string''.

rfc:zendsignals

2009-11-21T05:59:59+00:00

1218573532		current
Line 5:		Line 5:
	* Status: Under Discussion		* Status: Under Discussion
	* First Proposed by: [[http://markmail.org/message/3jg6cwqfghdlydhy\|Rasmus Lerdorf]]		* First Proposed by: [[http://markmail.org/message/3jg6cwqfghdlydhy\|Rasmus Lerdorf]]
-	* Source code: [[http://sizzo.org/~screen/patches/php-5.3.0-alarms-0808121020.patch\|PHP_5_3_0 patch]] [[http://sizzo.org/~screen/patches/php-HEAD-alarms-0808121015.patch\|PHP_HEAD patch]] (08-12-2008).	+	* 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).

	===== Introduction =====		===== Introduction =====
Line 116:		Line 116:
	- 2008-08-05 Arnaud Le Blanc: Added zend_sigaction() and ported PCNTL to use it. ([[http://sizzo.org/~screen/patches/php-5.3.0-alarms-0808021704.patch\|PHP_5_3_0 prev patch]] [[http://sizzo.org/~screen/patches/php-HEAD-alarms-0808021832.patch\|PHP_HEAD prev patch]])		- 2008-08-05 Arnaud Le Blanc: Added zend_sigaction() and ported PCNTL to use it. ([[http://sizzo.org/~screen/patches/php-5.3.0-alarms-0808021704.patch\|PHP_5_3_0 prev patch]] [[http://sizzo.org/~screen/patches/php-HEAD-alarms-0808021832.patch\|PHP_HEAD prev patch]])
	- 2008-08-12 Lucas Nealan: Update patches to latest CVS, minor TWS fixes etc. ([[http://arnaud.lb.s3.amazonaws.com/php-5.3.0-alarms-0808051122.patch\|PHP_5_3_0 prev patc]] [[http://arnaud.lb.s3.amazonaws.com/php-HEAD-alarms-0808051122.patch\|PHP_HEAD prev patch]])		- 2008-08-12 Lucas Nealan: Update patches to latest CVS, minor TWS fixes etc. ([[http://arnaud.lb.s3.amazonaws.com/php-5.3.0-alarms-0808051122.patch\|PHP_5_3_0 prev patc]] [[http://arnaud.lb.s3.amazonaws.com/php-HEAD-alarms-0808051122.patch\|PHP_HEAD prev patch]])
		+	- 2009-11-20 Brian Shire: Updated patches for latest CVS with some fixes for bugs caused by another fix to the handling of signals during user-space shutdown functions. ([[http://sizzo.org/~screen/patches/php-5.3.0-alarms-0808121020.patch\|PHP_5_3_0 prev patch]] [[http://sizzo.org/~screen/patches/php-HEAD-alarms-0808121015.patch\|PHP_HEAD prev patch]])

1207563768		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]]	+	* Status: [[http://news.php.net/php.zend-engine.cvs/6597\|Accepted]] (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

1213730688		current
Line 54:		Line 54:
	\| FilesystemIterator \| Spl::Iterator::Filesystem \|		\| FilesystemIterator \| Spl::Iterator::Filesystem \|
	\| FilterIterator \| Spl::Iterator::Filter \|		\| FilterIterator \| Spl::Iterator::Filter \|
-	\| GlobIterator \| Spl::Iterator::Filter \|	+	\| GlobIterator \| Spl::Iterator::Glob \|
	\| InfiniteIterator \| Spl::Iterator::Infinite \|		\| InfiniteIterator \| Spl::Iterator::Infinite \|
	\| IteratorIterator \| Spl::Iterator::Iterator \|		\| IteratorIterator \| Spl::Iterator::Iterator \|

1246917991		current
Line 37:		Line 37:
	^ true (boolean) \| fail \| fail \| fail \| fail \| pass \| pass \| fail \|		^ true (boolean) \| fail \| fail \| fail \| fail \| pass \| pass \| fail \|
	^ false (boolean) \| fail \| fail \| fail \| fail \| pass \| pass \| fail \|		^ false (boolean) \| fail \| fail \| fail \| fail \| pass \| pass \| fail \|
-	^ 0 (integer) \| fail \| fail \| pass \| pass \| pass \| pass \| fail \|	+	^ 0 (integer) \| fail \| pass \| pass \| pass \| pass \| pass \| fail \|
	^ 1 (integer) \| fail \| pass \| pass \| pass \| pass \| pass \| fail \|		^ 1 (integer) \| fail \| pass \| pass \| pass \| pass \| pass \| fail \|
	^ 12 (integer) \| fail \| pass \| pass \| pass \| pass \| fail \| fail \|		^ 12 (integer) \| fail \| pass \| pass \| pass \| pass \| fail \| fail \|
-	^ 12 (double) \| fail \| pass \| pass \| pass \| pass \| fail \| fail \|	+	^ 12 (double) \| fail \| pass \| fail \| pass \| pass \| fail \| fail \|
	^ 12.34 (double) \| fail \| pass \| fail \| pass \| pass \| fail \| fail \|		^ 12.34 (double) \| fail \| pass \| fail \| pass \| pass \| fail \| fail \|
	^ 'true' (string) \| pass \| fail \| fail \| fail \| pass \| fail \| fail \|		^ 'true' (string) \| pass \| fail \| fail \| fail \| pass \| fail \| fail \|
Line 46:		Line 46:
	^ '0' (string) \| pass \| fail \| fail \| pass \| pass \| pass \| fail \|		^ '0' (string) \| pass \| fail \| fail \| pass \| pass \| pass \| fail \|
	^ '1' (string) \| pass \| fail \| fail \| pass \| pass \| pass \| fail \|		^ '1' (string) \| pass \| fail \| fail \| pass \| pass \| pass \| fail \|
-	^ '12' (string) \| pass \| pass \| pass \| pass \| pass \| fail \| fail \|	+	^ '12' (string) \| pass \| fail \| fail \| pass \| pass \| fail \| fail \|
	^ '12abc' (string) \| pass \| fail \| fail \| fail \| pass \| fail \| fail \|		^ '12abc' (string) \| pass \| fail \| fail \| fail \| pass \| fail \| fail \|
-	^ '12.0' (string) \| pass \| pass \| pass \| pass \| pass \| fail \| fail \|	+	^ '12.0' (string) \| pass \| fail \| fail \| pass \| pass \| fail \| fail \|
-	^ '12.34' (string) \| pass \| pass \| fail \| pass \| pass \| fail \| fail \|	+	^ '12.34' (string) \| pass \| fail \| fail \| pass \| pass \| fail \| fail \|
	^ 'foo' (string) \| pass \| fail \| fail \| fail \| pass \| fail \| fail \|		^ 'foo' (string) \| pass \| fail \| fail \| fail \| pass \| fail \| fail \|
	^ array () (array) \| fail \| fail \| fail \| fail \| fail \| fail \| pass \|		^ array () (array) \| fail \| fail \| fail \| fail \| fail \| fail \| pass \|