PHP Wiki

todo:php71 - ga date

krakjoe — 2016-11-22T19:20:16+01:00

1467747424		current
Line 24:		Line 24:
	\| Oct 27 2016 \| RC 5 \|		\| Oct 27 2016 \| RC 5 \|
	\| Nov 10 2016 \| RC 6 \|		\| Nov 10 2016 \| RC 6 \|
-	\| Nov 2? 2016 \| ? \|	+	\| Dec 1 2016 \| GA \|

	===== Release Managers =====		===== Release Managers =====

rfc:arrayiterator-improvements

wesnetmo — 2016-11-22T19:01:24+01:00

1479836108		current
Line 44:		Line 44:

	None yet.		None yet.
		+
		+	===== References =====
		+	[[http://externals.io/thread/510\|Discussion thread]]

rfc

wesnetmo — 2016-11-22T18:34:17+01:00

1479834232		current
Line 10:		Line 10:

	===== In voting phase =====		===== In voting phase =====
-
-	* [[rfc:arrayiterator-improvements\|ArrayIterator improvements]] \\ Proposes adding ''ArrayIterator::seekKey()'' and ''ArrayIterator::prev()'' (Created: 2016-11-21)

	===== On Hold =====		===== On Hold =====
Line 21:		Line 19:
	This section is for RFCs that have been announced on the PHP "internals" mail list.		This section is for RFCs that have been announced on the PHP "internals" mail list.

		+	* [[rfc:arrayiterator-improvements\|ArrayIterator improvements]] \\ Proposes adding ''ArrayIterator::seekKey()'' and ''ArrayIterator::prev()'' (Created: 2016-11-21)
	* [[rfc:parameter-no-type-variance\|Parameter No Type Variance]] \\ Allow subclasses to drop parameter type constraints. (Created: 2016-11-21)		* [[rfc:parameter-no-type-variance\|Parameter No Type Variance]] \\ Allow subclasses to drop parameter type constraints. (Created: 2016-11-21)
	* [[rfc:debugging_pdo_prepared_statement_emulation_v2\|Debugging PDO Prepared Statement Emulation v2]] \\ Another approach to allowing the output of this feature to be examined in userland. (Created: 2016-11-17)		* [[rfc:debugging_pdo_prepared_statement_emulation_v2\|Debugging PDO Prepared Statement Emulation v2]] \\ Another approach to allowing the output of this feature to be examined in userland. (Created: 2016-11-17)

rfc:typed-properties-v2 - created

bwoebi — 2016-11-21T15:38:46+01:00

	current
Line 1:	Line 1:
	+	====== PHP RFC: Typed Properties ======
	+	* Version: 2.0.0
	+	* Date: 2016-11-21
	+	* Author: Bob Weinand <bobwei9@hotmail.com>
	+	* Status: In Draft
	+	* Original RFC at: https://wiki.php.net/rfc/typed-properties by Joe Watkins <krakjoe@php.net>, Phil Sturgeon <philstu@php.net>
	+	* First published: https://wiki.php.net/rfc/typed-properties-v2

	+	Following the raging success of PHP 7.0 additions [[https://wiki.php.net/rfc/scalar_type_hints_v5\|scalar type hints]] and [[https://wiki.php.net/rfc/return_types\|return types]], the next logical step is to provide optional typed properties.
	+
	+	===== Introduction =====
	+
	+	Typed Properties allow for an optional identifier in the definition, after the visibility scope, which contains the type the property should allow.
	+
	+	===== Proposal =====
	+
	+	Properties can have the same types as parameters:
	+
	+	<code php>
	+	class Foo {
	+	public int $int = 1;
	+	public ?float $flt = null;
	+	public array $arr = [];
	+	public bool $bool = false;
	+	public string $string;
	+	public callable $callable;
	+	public stdClass $std;
	+	public OtherThing $other;
	+	public $mixed;
	+	}
	+	</code>
	+
	+	//Notice there is no support for void here, as that would make no sense for a property.//
	+
	+	This can be rather useful, as a lot of the job of setters is to ensure the values being passed in are the correct type.
	+
	+	There are two possible outcomes to type mismatches, as one check is done at compile time and another done at runtime.
	+
	+	===== Default Values =====
	+
	+	[[https://3v4l.org/EnGUI/rfc#tabs\|If an attempt is made to assign a value of an incorrect type at compile time, a fatal error will be raised:]]
	+
	+	<code php>
	+	<?php
	+	new class {
	+	public int $bar = "turtle";
	+	};
	+	</code>
	+
	+	<code>
	+	PHP Fatal error: Default value for properties with integer type can only be integer in turtle.php on line 3
	+	</code>
	+
	+	[[https://3v4l.org/gq95J#tabs\|This is consistent with default parameter values:]]
	+
	+	<code php>
	+	<?php
	+	$cb = function (int $bar = "42") {
	+
	+	};
	+	</code>
	+
	+	<code>
	+	Fatal error: Default value for parameters with a integer type can only be integer or NULL in /in/gq95J on line 2
	+	</code>
	+
	+	While parameters allow null to be accepted as the default value, null is only a valid value for nullable properties.
	+
	+	===== Coercion and Strictness =====
	+
	+	The rules for strictness and coercion here are identical to how things with with type hints for parameters. As outlined above, default values (which are checked and set during compile time) are always strict, as there is no reason why you'd need coercion for a value being hardcoded into a property.
	+
	+	At runtime however, strict_types will be respected.
	+
	+	[[https://3v4l.org/O4bdX/rfc#tabs\|In weak mode (default), a numeric string passed at runtime is considered a valid int:]]
	+
	+	<code php>
	+	var_dump(new class() {
	+	public int $bar;
	+
	+	public function __construct() {
	+	$this->bar = "42";
	+	}
	+	});
	+	</code>
	+
	+	<code>
	+	object(class@anonymous)#1 (1) {
	+	["bar"]=> int(42)
	+	}
	+	</code>
	+
	+	This is not a new rule for the language so should not be seen as a complication. It is using existing rules and logic.
	+
	+	===== TypeError =====
	+
	+	[[https://3v4l.org/obW7U/rfc#tabs\|Due to the usage of TypeError, you can catch runtime errors for mismatched types:]]
	+
	+	<code php>
	+	class Math {
	+	public int $x;
	+	public int $y;
	+
	+	public function __construct($x, $y) {
	+	$this->x = $x;
	+	$this->y = $y;
	+	}
	+
	+	public function add() {
	+	return $this->x + $this->y;
	+	}
	+	}
	+
	+	try {
	+	(new Math(3, "nonsense"))->add();
	+	} catch (Error $e) {
	+	echo "Look, I'm Python!";
	+	}
	+	</code>
	+
	+	<code>
	+	Look, I'm Python!
	+	</code>
	+
	+	===== Use before initialization =====
	+
	+	[[https://3v4l.org/cVkcj/rfc#tabs\|The implementation will raise an exception where a typed property is accessed before being initialized:]]
	+
	+	<code php>
	+	$foo = new class {
	+	public int $bar;
	+	};
	+
	+	var_dump($foo->bar);
	+	</code>
	+
	+	<code>
	+	Fatal error: Uncaught TypeError: Typed property class@anonymous::$bar must not be accessed before initialization in /in/cVkcj:7
	+	Stack trace:
	+	#0 {main} thrown in /in/cVkcj on line 7
	+	</code>
	+
	+	Some have voiced concern that, if an object has typed properties and the constructor does not set them, an exception should be raised because the object is in an invalid state.
	+
	+	However, lazy initialization of properties is a common idiom in PHP, that the authors of the RFC are not willing to restrict to untyped properties.
	+
	+	//No rules have been violated until the engine returns a value//, since any value returned is //always// of the correct type, we do not see the need to place further restrictions upon typed properties.
	+
	+	To put it another way: Type safety is the goal of this RFC, not validating objects. Currently developers are forced to do isset() and is_int() checks, but with the functionality provided in this RFC they will only need isset() if they are building classes that rely on lazy initialization. As such, developers relying on lazy initialization get a small benefit, and those building their objects "correctly" with fully initialized properties will not need any isset() boilerplate at all, as an exception will make it nice and clear to them that they're not building their objects as completely as they expected.
	+
	+	Nullable properties are not exempt from this rule, they too will raise an exception when accessed before initialization.
	+
	+	===== References =====
	+
	+	This RFC also allows (as opposed to the original v1 typed-properties RFC, where it was a major complaint) taking typed properties by reference.
	+
	+	References on properties may not be liked too much in PHP, but they are still present. Be it as a way to avoid circular references of the parent object, to allow sorting on an array in a property, array_pop and similar array modifications, or returning via <nowiki>&__get() for allowing $this->foo[] = $bar;</nowiki>.
	+
	+	Given these use cases and resulting necessity (without hacks of using temporary variables or even having to resort to untyped properties) of being able to reference typed properties, the patch allow this:
	+	<code php>
	+	<?php
	+	$foo = new class {
	+	public int $bar = 42;
	+	};
	+
	+	$reference = &$foo->bar;
	+	$reference /= 2;
	+	var_dump($foo->bar); // int(21)
	+	</code>
	+
	+	References to typed properties will only ever restrict the allowed types, e.g. when you assign a nullable integer reference to a typed property of integer, the reference will only accept integer afterwards.
	+
	+	<code php>
	+	$foo = new class {
	+	public int $bar = 42;
	+	public ?int $baz = 21;
	+	};
	+
	+	$reference = &$foo->bar;
	+	$foo->baz = &$reference; // shrinks reference type to integer
	+	var_dump($foo->bar); // int(21)
	+	unset($foo->bar); // this does not affect the reference type - reference types are never widened
	+	$reference = null; // Uncaught TypeError: Cannot assign null to reference of type integer
	+	</code>
	+
	+	This is partly due to implementational reasons, but also for practical reasons; if you assign a typed property by reference, you should code like the reference would persist.
	+
	+	===== Magic (__get) =====
	+
	+	[[https://3v4l.org/Lq5dA/rfc#tabs\|The magical __get method is not allowed to violate the declared type:]]
	+
	+	<code php>
	+	$foo = new class {
	+	public int $bar;
	+
	+	public function __construct() {
	+	unset($this->bar); # will result in the invocation of magic when $bar is accessed
	+	}
	+
	+	public function __get($name) {
	+	return "oh dear!";
	+	}
	+	};
	+
	+	var_dump($foo->bar);
	+	</code>
	+
	+	<code>
	+	Fatal error: Uncaught TypeError: Typed property class@anonymous::$bar must be integer, string used in /in/Lq5dA:15
	+	Stack trace:
	+	#0 {main} thrown in /in/Lq5dA on line 15
	+	</code>
	+
	+	This may seem counter intuitive, but it's consistent with how normal objects work.
	+
	+	When a normal objects property is unset, it will result in the invocation of magic get when subsequently accessed, as if the property had never been declared, but the engine does not actually remove the property; If the property is assigned a value, access will be controlled as the declaration defines on any subsequent read of the property.
	+
	+	Therefore, we allow the invocation of magic for unset properties, but do not allow the return value to violate the type declared.
	+
	+	===== Mixed Declarations =====
	+
	+	Given the following code:
	+
	+	<code php>
	+	new class {
	+	public int $foo, $bar;
	+	};
	+	</code>
	+
	+	The engine already makes the assumption that $bar is public, whether that is right or wrong is irrelevant; We can't change it.
	+
	+	To stay consistent with the way visibility is applied to the group, type is applied in the same way. Any property in this statement will be considered an int too.
	+
	+	Mixing type declarations in a grouped statement is not allowed, and will cause a parser error:
	+
	+	<code php>
	+	new class {
	+	public int $foo, string $bar;
	+	};
	+	</code>
	+
	+	<code>
	+	Parse error: syntax error, unexpected 'string' (T_STRING), expecting variable (T_VARIABLE)
	+	</code>
	+
	+	If you want to declare multiple properties with different types, use multiple statements.
	+
	+	===== Unset =====
	+
	+	It is possible to unset typed properties, and return them to the same state as a property that was never set. There are no special differences or rules around this.
	+
	+	<code php>
	+	$foo = new class {
	+	public int $bar;
	+
	+	public function __construct()
	+	{
	+	$this->bar = 12;
	+	}
	+	};
	+
	+	unset($foo->bar);
	+
	+	var_dump(isset($foo->bar));
	+
	+	var_dump($foo->bar * 2);
	+	</code>
	+
	+	<code>
	+	bool(false)
	+
	+	Fatal error: Uncaught TypeError: Typed property class@anonymous::$bar must not be accessed before initialization
	+	</code>
	+
	+	===== Reflection =====
	+
	+	[[https://3v4l.org/A6XZO/rfc#tabs\|A new ReflectionProperty::getType() method is provided.]]
	+
	+	<code php>
	+	class PropTypeTest {
	+	public int $int;
	+	public string $string;
	+	public array $arr;
	+	public callable $callable;
	+	public stdClass $std;
	+	public OtherThing $other;
	+	public $mixed;
	+	}
	+
	+	$reflector = new ReflectionClass(PropTypeTest::class);
	+
	+	foreach ($reflector->getProperties() as $name => $property) {
	+	if ($property->hasType()) {
	+	printf("type: %s $%s\n", $property->getType(), $property->getName());
	+	} else {
	+	printf("mixed: $%s\n", $property->getName());
	+	}
	+	}
	+	</code>
	+
	+	<code>
	+	type: int $int
	+	type: string $string
	+	type: array $arr
	+	type: callable $callable
	+	type: stdClass $std
	+	type: OtherThing $other
	+	mixed: $mixed
	+	</code>
	+
	+
	+	===== Similarities to HHVM =====
	+
	+	The type system in HHVM uses matching syntax.
	+
	+	In fact, an example taken from the [[https://docs.hhvm.com/hack/types/type-system\|HHVM Type System]] works perfectly with this implementation:
	+
	+	<code php>
	+	class A {
	+	protected float $x;
	+	public string $y;
	+
	+	public function __construct() {
	+	$this->x = 4.0;
	+	$this->y = "Day";
	+	}
	+	public function foo(bool $b): float {
	+	return $b ? 2.3 * $this->x : 1.1 * $this->x;
	+	}
	+	}
	+
	+	function bar(): string {
	+	// local variables are inferred, not explicitly typed
	+	$a = new A();
	+	if ($a->foo(true) > 8.0) {
	+	return "Good " . $a->y;
	+	}
	+	return "Bad " . $a->y;
	+	}
	+
	+	var_dump(bar()); // string(8) "Good Day"
	+	</code>
	+
	+	Whilst the syntax is almost identical, this works a little differently to Hack.
	+
	+	Hack a offers static analysis tools to detect mismatched types, but when the code is executed it will allow any type to be passed through. This implementation is done at compile time to avoid the need for this, and validates properties being set at runtime too. Static analysis tools and editors/IDEs will no doubt catch up.
	+
	+	===== Other Languages =====
	+
	+	Of course, while "But Xlang does it!" is never a strong reason to do anything, it is sometimes nice to know how our friends are doing it in other languages.
	+
	+	* [[https://docs.hhvm.com/hack/types/type-system\|\|Hack/HHVM]] - See similarities above.
	+	* [[https://en.wikipedia.org/wiki/Property_(programming)#C.23\|C#]]
	+	* [[https://en.wikipedia.org/wiki/Property_(programming)#C.2B.2B\|C++]]
	+	* [[https://en.wikipedia.org/wiki/Property_(programming)#D\|D]]
	+	* [[https://en.wikipedia.org/wiki/Property_(programming)#Delphi.2FFree_Pascal\|Delphi/Free Pascal]]
	+	* [[https://en.wikipedia.org/wiki/Property_(programming)#ActionScript_3.0\|ActionScript]]
	+	* [[https://en.wikipedia.org/wiki/Property_(programming)#Visual_Basic\|Visual Basic]]
	+
	+	===== Syntax =====
	+
	+	The authors of this RFC considered other syntax possibilities, however they were considered to be inferior for the following reasons.
	+
	+	One approach could be to match how return types are done with a colon after the name of the declaration, which is also how Delphi and ActionScript handle things:
	+
	+	<code php>
	+	public $bar: int;
	+	public $bar: int = 2;
	+	// or
	+	public $bar = 2: int;
	+	</code>
	+
	+	Maybe, but if a ternary was used it would be really hard to see what was happening:
	+
	+	<code>
	+	public $bar = Stuff::BAZ ? 20 : 30 : int;
	+	</code>
	+
	+	Another approach would be to copy VisualBasic:
	+
	+	<code php>
	+	public $bar as int;
	+	public $bar = 2 as int;
	+	</code>
	+
	+	That sticks out a bit, we don't do this anywhere else.
	+
	+	The current patch seems the most consistent with popular languages, avoids new reserved words, skips syntax soup and looks great regardless of assignment being used or not.
	+
	+	===== Static Properties =====
	+	Static properties are global variables as far as the engine is concerned, it uses the same opcode to assign a static property as it does to assign any other variable ZEND_ASSIGN, the only exception being instance variables which are assigned with ZEND_ASSIGN_OBJ - giving us opportunity to provide type safety.
	+
	+	In general, we need completely new opcodes for assigning them (by ref and normal assign) - I may still add them, but it will be some extra work. If it turns out to be too big of a change, it will need a separate patch and RFC.
	+
	+	===== Performance =====
	+
	+	The latest version of the proposed patch doesn't make visible performance change of real-life apps.
	+
	+	On Wordpress and Mediawiki it makes about 0.1% slowdown, that may be caused not by the additional checks but by the worse CPU cache utilization, because the size of PHP code was increased on 60KB.
	+
	+	However, [[https://gist.github.com/dstogov/33b0d79de779627bad810eb16d6156a5\|micro-benchmarks]] show significant slowdown (up to 20%) on primitive operations with untyped properties. Usage of typed properties makes additional slowdown. The following table shows relative slowdown of operations with properties in comparison to master branch.
	+
	+	^ ^ $o->p = $x; ^ $o->p +=2; ^ $x = ++$o->p; ^ $x= $o->p++; ^
	+	\| untyped property \| 15%\| 1%\| 7%\| 9%\|
	+	\| untyped property in class with typed properties \| 15%\| 1%\| 7%\| 9%\|
	+	\| typed property \| 24%\| 31%\| 8%\| 10%\|
	+
	+	In principle, knowing the type of a property may allow us to make further optimizations.
	+
	+	===== Backward Incompatible Changes =====
	+	None
	+
	+	===== Proposed PHP Version(s) =====
	+	PHP 7.2
	+
	+	===== RFC Impact =====
	+
	+	==== To Opcache ====
	+
	+	Opcache has been patched.
	+
	+	===== Future Scope =====
	+
	+	==== Typed Local Variables ====
	+
	+	This is an entirely different feature, and something not worth conflating into this RFC. The idea might be wanted, but to keep things simple it will not be discussed in this RFC.
	+
	+	==== Typed Constant Properties ====
	+
	+	There is currently no known value in adding a type to a constant. Seeing as constants cannot be modified, the type is just whatever the constant is set to, and seeing as it cannot change there is no chance for a constant to be assigned a invalid value afterwards.
	+
	+	===== Vote =====
	+
	+	Two weeks vote needing 2/3 supermajority.
	+
	+	<doodle title="Merge typed properties?" auth="bwoebi" voteType="single" closed="true">
	+	* Yes
	+	* No
	+	</doodle>
	+
	+	===== Patches and Tests =====
	+
	+	https://github.com/php/php-src/compare/master...bwoebi:typed_ref_properties
	+
	+	===== Changelog =====
	+
	+	* v2.0.0: Initial import

internals:windows:buildv2

kalle — 2016-11-21T14:54:10+01:00

1479698332		current
Line 42:		Line 42:
	+- ...		+- ...
	</code>		</code>
		+
		+	===== Extension Config Load Order =====
		+
		+	On the Unix build system, the config.m4 files allows a numeric order to be loaded in, this is done by adding a suffix to "config" with a value of 0-9 followed by the file extension, such as "config9.m4". The Windows build system does not offer such, and there are no plans to implement such in this proposal.

	===== Multi Compiler Support =====		===== Multi Compiler Support =====
Line 294:		Line 298:
	</code>		</code>

-	This makes the libraries much easier to handle and check and it provides the same flexibility as before in a more friendly interface.	+	This makes the libraries much easier to handle and check and it provides the same flexibility as before in a more friendly interface. Above example is just a small illustration of the API that can be used, the full API is described later in this document.
		+
		+	==== Extension dependencies ====
		+
		+	It is common for extensions to depend on others, these can either be optional, required or even semi depended on others, like the ext/curl extension that can depend on ZLib depending on how it was configured.
		+
		+	In the Extension constructor, the following methods are available for dependencies, the following example will use ext/pdo_sqlite:
		+
		+	<code javascript>
		+	public function pdo_sqlite()
		+	{
		+	this.Dependencies(['pdo']);
		+	};
		+	</code>
		+
		+	If the 'pdo' extension was not enabled prior to this, then an exception is thrown from the Dependencies() method, stopping the configure command.
		+
		+	An extension can also optionally depend on another, and if it is available, then an extension can take advantage of its utility:
		+
		+	<code javascript>
		+	public function test_ext()
		+	{
		+	// Works for both static and shared builds
		+	if(this.getExtension('json'))
		+	{
		+	this.Define('HAVE_JSON_SUPPORT', 1);
		+	}
		+
		+	// Or if static json is required
		+	if(this.getExtension('json', this.build_type.StaticBuild))
		+	{
		+	this.Define('HAVE_STATIC_JSON_SUPPORT', 1);
		+	}
		+	};
		+	</code>
		+
		+	==== Extensions that run external programs, such as parsers ====
		+
		+	Some extensions, or SAPIs run external programs before compiling for generating parsers or similar, such is also possible in the new build system:
		+
		+	<code javascript>
		+	public function json()
		+	{
		+	if(!this.FSO.FileExists('ext/json/json_scanner.c'))
		+	{
		+	PHPBuild.ExecuteBinary('re2c', '-t ext/json/php_json_scanner_defs.h --no-generation-date -bci -o ext/json/json_scanner.c ext/json/json_scanner.re');
		+	}
		+
		+	*/ ... /*
		+	};
		+	</code>
		+
		+	==== Extensions that adds additional configure arguments ====
		+
		+	It is very common for extensions to provide additional configurations from arguments, by default each declared extension will be supported by either:
		+
		+	* --with-<ext>
		+	* --enable-<ext>
		+
		+	This type is defined in the Extension.arg_type property to an enum value of either ArgType.WITH or ArgType.ENABLE. However extensions may also add their own, this is done in the property called 'config_args':
		+
		+	<code javascript>
		+	class test_ext extends Extension
		+	{
		+	public const name : string = 'Test Extension';
		+	public const short_name : string = 'test_ext';
		+
		+	public const arg_type : ArgType = ArgType.WITH;
		+	public const config_args : object = {
		+	'test-ext-debug': ArgType.ENABLE
		+	};
		+
		+	public shared : bool;
		+
		+	public const files : array = ['php_test_ext.c'];
		+
		+
		+	public function test_ext()
		+	{
		+	if(this.GetArg('test-ext-debug').isEnabled())
		+	{
		+	this.CFlag('/D HAVE_TEST_EXT_DEBUG');
		+	}
		+	}
		+	}
		+
		+	PHPBuild.AddExtension(new test_ext);
		+	</code>
		+
		+	The GetArg() method returns an 'BuildArgument' object, that contains helper methods, such as isEnabled() to quickly determine the value was turned by a manual --enable-test-ext-debug
		+
		+	==== Extensions that implements multiple build modess in one config file ====
		+
		+	There are some extensions that can be built in multiple ways, one such case is ext/pdo_dblib


	TODO		TODO
	* sapis		* sapis
		+	* consider changing 'new xxx' in calls, as they are executed directly
	* improve arg api for exts		* improve arg api for exts
	* multi build args for an ext		* multi build args for an ext
	* multi extensions per config, like pdo_dblib		* multi extensions per config, like pdo_dblib
-	* configX.m4 support, priority load order
	* talk about task size and target		* talk about task size and target
	* talk about design reasoning		* talk about design reasoning
	* API reference		* API reference
	* implementation stages(?)		* implementation stages(?)

rfc:parameter-no-type-variance - Add title

kelunik — 2016-11-21T10:33:47+01:00

1479720741		current
Line 1:		Line 1:
-	====== PHP RFC: Your Title Here ======	+	====== PHP RFC: Parameter No Type Variance ======
	* Version: 0.1.1		* Version: 0.1.1
	* Date: 2016-11-21		* Date: 2016-11-21

internals:windows:todo

kalle — 2016-11-21T00:48:09+01:00

1444493620		current
Line 17:		Line 17:
	===== Missing function implementations =====		===== Missing function implementations =====
	Core/Standard:		Core/Standard:
-	- [[http://docs.php.net/proc_nice\| proc_nice]] -- See: http://news.php.net/php.internals.win/633
	- [[http://docs.php.net/lchown\| lchown]]		- [[http://docs.php.net/lchown\| lchown]]
	- [[http://docs.php.net/lchgrp\| lchgrp]]		- [[http://docs.php.net/lchgrp\| lchgrp]]

rfc:voting

kalle — 2016-11-19T17:04:37+01:00

1479571458		current
Line 52:		Line 52:
	The proposal here is for two audiences to participate in the voting process:		The proposal here is for two audiences to participate in the voting process:
	* People with php.net VCS accounts that have contributed code to PHP		* People with php.net VCS accounts that have contributed code to PHP
-	* Representatives from the PHP community, that will be chosen by those with php.net SVN accounts	+	* Representatives from the PHP community, that will be chosen by those with php.net VCS accounts
	* Lead developers of PHP based projects (frameworks, cms, tools, etc.)		* Lead developers of PHP based projects (frameworks, cms, tools, etc.)
	* regular participant of internals discussions		* regular participant of internals discussions

rfc:abolish-narrow-margins - add topic

krakjoe — 2016-11-19T07:59:11+01:00

1479483581		current
Line 1:		Line 1:
	====== PHP RFC: Abolish Narrow Margins ======		====== PHP RFC: Abolish Narrow Margins ======
-	* Version: 0.2	+	* Version: 0.3
	* Date: 2016-11-17		* Date: 2016-11-17
	* Author: krakjoe		* Author: krakjoe
Line 27:		Line 27:
	* Suggestion that we should introduce quorum: this is not the topic of this RFC.		* Suggestion that we should introduce quorum: this is not the topic of this RFC.
	* Suggestion that we should change who can vote: this is not the topic of this RFC.		* Suggestion that we should change who can vote: this is not the topic of this RFC.
		+	* Suggestion that we should always require a reason to accompany a negative vote: this is not the topic of this RFC.

	===== References =====		===== References =====
	[[http://externals.io/thread/486\|Discussion]]		[[http://externals.io/thread/486\|Discussion]]

rfc:security-classification

krakjoe — 2016-11-18T08:51:05+01:00

1478868687		current
Line 3:		Line 3:
	* Date: 2016-11-10		* Date: 2016-11-10
	* Authors: Release Managers		* Authors: Release Managers
-	* Status: Voting	+	* Status: Accepted
	* First Published at: http://wiki.php.net/rfc/security-classification		* First Published at: http://wiki.php.net/rfc/security-classification

Line 23:		Line 23:
	Voting opened November 11th for one week, closing November 18th:		Voting opened November 11th for one week, closing November 18th:

-	<doodle title="Officially adopt the proposed security issue classification scheme ?" auth="krakjoe" voteType="single" closed="false">	+	<doodle title="Officially adopt the proposed security issue classification scheme ?" auth="krakjoe" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No

rfc:debugging_pdo_prepared_statement_emulation_v2 - created

adambaratz — 2016-11-17T23:09:20+01:00

	current
Line 1:	Line 1:
	+	====== PHP RFC: Debugging PDO Prepared Statement Emulation v2 ======
	+	* Version: 0.1
	+	* Date: 2016-11-17
	+	* Author: Adam Baratz adambaratz@php.net
	+	* Status: In Discussion
	+	* First Published at: https://wiki.php.net/rfc/debugging_pdo_prepared_statement_emulation_v2

	+	===== Introduction =====
	+	I previously submitted an [[rfc:debugging_pdo_prepared_statement_emulation\|RFC]] which was accepted and implemented. I had second thoughts about the implementation and would like to replace it with the approach described here. Please see the original RFC for a description of the underlying problem.
	+
	+	===== Proposal =====
	+	PDO already provides some debug functionality in the form of ''PDOStatement::debugDumpParams()''. This method would be extended to include the parsed query string:
	+
	+	<code php>
	+	/* Execute a prepared statement by binding PHP variables */
	+	$calories = 150;
	+	$colour = 'red';
	+
	+	$sth = $dbh->prepare('SELECT name, colour, calories
	+	FROM fruit
	+	WHERE calories < ? AND colour = ?');
	+	$sth->bindParam(1, $calories, PDO::PARAM_INT);
	+	$sth->bindValue(2, $colour, PDO::PARAM_STR);
	+	$sth->execute();
	+
	+	$sth->debugDumpParams();
	+
	+	/*
	+
	+	Output:
	+
	+	SQL: [82] SELECT name, colour, calories
	+	FROM fruit
	+	WHERE calories < ? AND colour = ?
	+	Parsed SQL: [88] SELECT name, colour, calories
	+	FROM fruit
	+	WHERE calories < 150 AND colour = 'red'
	+	Params: 2
	+	Key: Position #0:
	+	paramno=0
	+	name=[0] ""
	+	is_param=1
	+	param_type=1
	+	Key: Position #1:
	+	paramno=1
	+	name=[0] ""
	+	is_param=1
	+	param_type=2
	+
	+	*/
	+	</code>
	+
	+	The "Parsed SQL" section will only be shown if the prepared statement emulation is enabled. This would allow this information to be accessed without any API changes. If prepared statement emulation is removed, as some have suggested it should be, this feature would vanish seamlessly.
	+
	+	===== Backward Incompatible Changes =====
	+	The original RFC will be released with PHP 7.2. If this RFC is accepted in time for that release, there will be no BC breaks.
	+
	+	===== Proposed PHP Version(s) =====
	+	Next PHP 7.x.
	+
	+	===== Proposed Voting Choices =====
	+	This project requires a 50%+1 majority.

rfc:debugging_pdo_prepared_statement_emulation - old revision restored (2016/11/15 23:48)

adambaratz — 2016-11-17T17:27:14+01:00

1479337409		current
Line 1:		Line 1:
	====== PHP RFC: Debugging PDO Prepared Statement Emulation ======		====== PHP RFC: Debugging PDO Prepared Statement Emulation ======
-	* Version: 0.4	+	* Version: 0.3
	* Date: 2016-10-17		* Date: 2016-10-17
	* Author: Adam Baratz adambaratz@php.net		* Author: Adam Baratz adambaratz@php.net
-	* Status: In Discussion	+	* Status: Accepted
	* First Published at: https://wiki.php.net/rfc/debugging_pdo_prepared_statement_emulation		* First Published at: https://wiki.php.net/rfc/debugging_pdo_prepared_statement_emulation

Line 14:		Line 14:

	===== Proposal =====		===== Proposal =====
-	People who use emulated prepared statements should be able to debug them within userland, without using additional tools. PDO already provides some debug functionality in the form of ''PDOStatement::debugDumpParams()''. This method would be extended to include the parsed query string:	+	People who use emulated prepared statements should be able to debug them within userland, without using additional tools. PDO already provides some debug functionality in the form of ''PDOStatement::debugDumpParams()''. The goal would be to offer another slice on PDO internals, not to create another path for developers to communicate with a database. I propose a new method, ''PDOStatement::activeQueryString()'':

	<code php>		<code php>
-	*/ Execute a prepared statement by binding PHP variables /*	+	$db = new PDO(...);
-	$calories = 150;	+
-	$colour = 'red';	+

-	$sth = $dbh->prepare('SELECT name, colour, calories	+	// works with statements without bound values
-	FROM fruit	+	$stmt = $db->query('SELECT 1');
-	WHERE calories < ? AND colour = ?');	+	var_dump($stmt->activeQueryString()); // => string(8) "SELECT 1"
-	$sth->bindParam(1, $calories, PDO::PARAM_INT);	+
-	$sth->bindValue(2, $colour, PDO::PARAM_STR);	+
-	$sth->execute();	+

-	$sth->debugDumpParams();	+	$stmt = $db->prepare('SELECT :string');
		+	$stmt->bindValue(':string', 'foo');

-	/*	+	// returns unparsed query before execution
		+	var_dump($stmt->activeQueryString()); // => string(14) "SELECT :string"

-	Output:	+	// returns parsed query after execution
-		+	$stmt->execute();
-	SQL: [82] SELECT name, colour, calories	+	var_dump($stmt->activeQueryString()); // => string(11) "SELECT 'foo'"
-	FROM fruit	+
-	WHERE calories < ? AND colour = ?	+
-	Parsed SQL: [88] SELECT name, colour, calories	+
-	FROM fruit	+
-	WHERE calories < 150 AND colour = 'red'	+
-	Params: 2	+
-	Key: Position #0:	+
-	paramno=0	+
-	name=[0] ""	+
-	is_param=1	+
-	param_type=1	+
-	Key: Position #1:	+
-	paramno=1	+
-	name=[0] ""	+
-	is_param=1	+
-	param_type=2	+
-		+
-	*/	+
	</code>		</code>

-	The "Parsed SQL" section will only be shown if the prepared statement emulation is enabled.	+	Since this would be a debug tool, the method shouldn't affect the state of the ''PDOStatement'' instance. For example, this method shouldn't trigger parsing or errors. You usually don't know something went wrong with the parsing until after execution, anyway. This means the method simply retrieves a value that already exists in memory.

	===== Backward Incompatible Changes =====		===== Backward Incompatible Changes =====
Line 64:		Line 43:

	===== Future Scope =====		===== Future Scope =====
-	It's been suggested that PDO shouldn't allow prepare statement emulation. This new functionality would only engage if emulation is enabled, so it will self-destruct if emulation is dropped.	+	It's been suggested that PDO shouldn't allow prepare statement emulation. Since the mssql extension was deprecated in PHP 7 in favor of pdo_dblib, I don't think this is possible.
		+
		+	It's been suggested that this change would turn PDO into a leaky (or leakier) abstraction. I'd counter that this is strictly a tool that allows tests to expand their code coverage. If emulated prepared statements are being kept in PDO, we should be able to test the >700 LoC in the associated query parser.

	===== Proposed Voting Choices =====		===== Proposed Voting Choices =====
	This project requires a 50%+1 majority.		This project requires a 50%+1 majority.

-	<doodle title="Debugging PDO Prepared Statement Emulation v0.4" auth="abaratz" voteType="single" closed="false">	+	<doodle title="Debugging PDO Prepared Statement Emulation" auth="abaratz" voteType="single" closed="true">
	* Yes		* Yes
	* No		* No
	</doodle>		</doodle>
		+
		+	===== Patches and Tests =====
		+	A working implementation with tests: https://github.com/php/php-src/pull/2159

	===== References =====		===== References =====
-	Initial discussion of this proposal on the internals mailing list:	+	Initial discussion of this proposal on the internals mailing list: http://marc.info/?l=php-internals&m=147638162506291&w=2
-	* http://marc.info/?l=php-internals&m=147638162506291&w=2	+
-	* http://marc.info/?l=php-internals&m=147734024403899&w=2	+	===== Implementation =====
-	* http://marc.info/?l=php-internals&m=147673258418764&w=2	+	This feature was implemented in PHP 7.2 ([[https://github.com/php/php-src/commit/83086d9a72675bad2b2560c6f427d0c1f1d1eba0\|83086d9a72675bad2b2560c6f427d0c1f1d1eba0]]).

rfc:user_defined_session_serializer - Add more descriptions.

yohgaki — 2016-11-17T11:50:38+01:00

1479380469		current
Line 73:		Line 73:

	50%+1 majority is required to pass.		50%+1 majority is required to pass.
		+
		+	Vote starts: 2016-XX-XX Vote ends: 2016-XX-XX UTC 23:59:59

	<doodle title="Add user defined session serializer" auth="yohgaki" voteType="single" closed="true">		<doodle title="Add user defined session serializer" auth="yohgaki" voteType="single" closed="true">
Line 79:		Line 81:
	</doodle>		</doodle>

-	Vote starts: 2016-XX-XX
-
-	Vote ends: 2016-XX-XX UTC 23:59:59

	===== Patches and Tests =====		===== Patches and Tests =====

rfc:object-typehint

danack — 2016-11-15T23:49:29+01:00

1479250192		current
Line 1:		Line 1:
	====== PHP RFC: Object typehint ======		====== PHP RFC: Object typehint ======
-	* Version: 0.1	+	* Version: 1.1
	* Date: 2016-08-12		* Date: 2016-08-12
	* Author: Michał Brzuchalski <michal.brzuchalski@gmail.com>, Dan Ackroyd <danack@php.net>		* Author: Michał Brzuchalski <michal.brzuchalski@gmail.com>, Dan Ackroyd <danack@php.net>

rfc:davey_shafik_on_twitter_thinking_about_an_rfc_to_remove_pear_from_php_8_0_thoughts_.png - created

davey — 2016-09-01T18:45:51+01:00

	current

rfc:screenshot_from_2016-08-05_14-24-16.png - created

yohgaki — 2016-08-05T07:24:56+01:00

	current

rfc:screenshot_from_2016-08-05_11-25-01.png - created

yohgaki — 2016-08-05T04:30:36+01:00

	current

rfc:array_change_keys_bench1.png - created

colinodell — 2016-05-31T03:13:02+01:00

	current

rfc:array_change_keys_bench2.png - created

colinodell — 2016-05-31T03:13:02+01:00

	current

rfc:array_change_keys_benchmark.png - created

colinodell — 2016-05-29T14:49:48+01:00

	current