PHP Wiki

rfc:zendsignals - Updated patches.

shire — 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]])

internals:windows:libs:ibm_db2 - created

ambrish — 2009-11-20T12:45:58+00:00

	current
Line 1:	Line 1:
	+	====== ibm_db2 (IBM DB2 PHP driver) Windows, How to compile ======

	+
	+	===== Building ibm_db2 =====
	+
	+	==== Requirements =====
	+	* ibm_db2 sources ([[http://pecl.php.net/get/ibm_db2]] )
	+
	+	==== Dependencies ====
	+	* IBM DB2 DataServer Driver ([[https://www.ibm.com/services/forms/preLogin.do?source=swg-idsdpds]])
	+
	+	==== Compile =====

internals:windows:libs - added ibm_db2

ambrish — 2009-11-20T12:21:46+00:00

1253559966		current
Line 223:		Line 223:
	Third party libraries are not available in our repositories. The reason are the miscellaneous restricted licenses and non open sources code. However, we are authorized to distribute them with our PHP releases but not their SDK.		Third party libraries are not available in our repositories. The reason are the miscellaneous restricted licenses and non open sources code. However, we are authorized to distribute them with our PHP releases but not their SDK.

		+	* ibm_db2 - [[internals:windows:libs:ibm_db2\| ibm_db2]]
	* msql - [[http://www.hughes.com.au/ \| Mini SQL]]		* msql - [[http://www.hughes.com.au/ \| Mini SQL]]
	* mssql/pdo_dblib - ntwdblib, only available with Microsoft SQL Server 2000 or earlier		* mssql/pdo_dblib - ntwdblib, only available with Microsoft SQL Server 2000 or earlier
	* oci8/pdo_oci - [[internals:windows:libs:oracle\| oracle]]		* oci8/pdo_oci - [[internals:windows:libs:oracle\| oracle]]
	* sybase_ct - [[http://www.sybase.com/products/databasemanagement/adaptiveserverenterprise \| Sybase Adaptive Server Enterprise]]		* sybase_ct - [[http://www.sybase.com/products/databasemanagement/adaptiveserverenterprise \| Sybase Adaptive Server Enterprise]]
		+


Line 248:		Line 250:
	\| gettext \| [[internals:windows:libs:gettext\| libintl]] \| [[http://www.php.net/gettext\|]] \| No \|		\| gettext \| [[internals:windows:libs:gettext\| libintl]] \| [[http://www.php.net/gettext\|]] \| No \|
	\| gmp\| [[internals:windows:libs:gmp\| libgmp]] or [[internals:windows:libs:mpir\| mpir]] \| [[http://www.php.net/gmp\|]] \| No \|		\| gmp\| [[internals:windows:libs:gmp\| libgmp]] or [[internals:windows:libs:mpir\| mpir]] \| [[http://www.php.net/gmp\|]] \| No \|
		+	\| ibm_db2\| [[internals:windows:libs:ibm_db2\|ibm_db2]] \| [[http://www.php.net/ibm_db2\|]] \| Yes \|
	\| imap \| [[internals:windows:libs:cclient\|cclient]] \| [[http://www.php.net/imap\|]] \| No \|		\| imap \| [[internals:windows:libs:cclient\|cclient]] \| [[http://www.php.net/imap\|]] \| No \|
	\| interbase \| [[internals:windows:libs:interbase\|ibase]] \| [[http://www.php.net/interbase\|]] \| No \|		\| interbase \| [[internals:windows:libs:interbase\|ibase]] \| [[http://www.php.net/interbase\|]] \| No \|

internals:pdo:brainstorming - pdo relation to the native extensions questions

lsmith — 2009-11-19T23:22:53+00:00

1258669865		current
Line 12:		Line 12:
	* How do we deal with different error handling? Like some RDBMS create throw errors during the prepare stage, others at the first execute.		* How do we deal with different error handling? Like some RDBMS create throw errors during the prepare stage, others at the first execute.
	* How do we deal with different behavior like transaction errors causing a rollback on some RDBMS but not on others.		* How do we deal with different behavior like transaction errors causing a rollback on some RDBMS but not on others.
		+	* How to deal with missing functionality available inside the native extensions? Is the goal to eventually replace the native extensions? Is there any chance to share connections between PDO and the native extensions?

rfc:customfactories - Clarified the example for using the custom factory

robertlemke — 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/
-

pear:qa:mentoring - created

kguest — 2009-11-17T13:40:19+00:00

		current
Line 1:		Line 1:
		+	{{{INSIGHTFUL TEXT HERE}}}

rfc:closures:object-extension - updated rfc

cseiler — 2009-11-16T19:11:02+00:00

1232633259		current
Line 1:		Line 1:
	====== Closures: Object extension ======		====== Closures: Object extension ======

-	Recently, efforts were made to go beyond the scope of the original Closures proposal ([[rfc/closures]]) in order to allow the extension of objects dynamically, take the following example code:	+	Efforts were made to go beyond the scope of the original Closures proposal ([[rfc/closures]]) in order to allow the extension of objects dynamically, take the following example code:

	<code php>		<code php>
Line 41:		Line 41:

	Please: Before reading, keep in mind that the definition of "closure" is simply an object then saves the scope that there is at creation time. Since closures come from functional programming (i.e. lambda calculus), the way closures and OOP interact is up to the programming language that combines both. Different programming languages that implement both have different approaches to this topic that are tailored to the specific language.		Please: Before reading, keep in mind that the definition of "closure" is simply an object then saves the scope that there is at creation time. Since closures come from functional programming (i.e. lambda calculus), the way closures and OOP interact is up to the programming language that combines both. Different programming languages that implement both have different approaches to this topic that are tailored to the specific language.
		+
		+	===== History =====
		+
		+	For PHP 5.3 $this support for Closures was removed because no consensus could be reached how to implement it in a sane fashion. This RFC describes the possible roads that can be taken to implement it in PHP 6.

	===== Approaches to $this binding =====		===== Approaches to $this binding =====
		+
		+	==== (0) Proposal: Keep as-is, no $this support in closures ====
		+
		+	In PHP 5.3 $this is not supported in closures - the simplest solution is to ensure HEAD (PHP 6.0) exhibits the same behaviour as 5.3 and make lamdas/closures a purely functional and non-OOP tool.

	==== (A) Original proposal: Bind $this to the object scope at creation (if existing) ====		==== (A) Original proposal: Bind $this to the object scope at creation (if existing) ====
Line 136:		Line 144:
	\| 0 \| 1 \| 2 \| 3 \| 4 \| 5 \| 6		\| 0 \| 1 \| 2 \| 3 \| 4 \| 5 \| 6
	==+===+===+===+===+===+===+===		==+===+===+===+===+===+===+===
		+	0 \| # \| # \| - \| # \| - \| # \| #
		+	--+---+---+---+---+---+---+---
	A \| 1 \| 1 \| - \| 1 \| - \| 1 \| 1		A \| 1 \| 1 \| - \| 1 \| - \| 1 \| 1
	--+---+---+---+---+---+---+---		--+---+---+---+---+---+---+---
Line 272:		Line 282:
	- Try to find a property in the property table with the name and if it is a closure, call the closure.		- Try to find a property in the property table with the name and if it is a closure, call the closure.
	- Use __call		- Use __call
-	- No not use __get	+	- Do not use __get

	NOTE This appears to be the conensus on this issue as far as I can see on-list. If this should be not the case, please correct this section.		NOTE This appears to be the conensus on this issue as far as I can see on-list. If this should be not the case, please correct this section.
Line 336:		Line 346:
	- Always use the class scope of the object that bindTo() is called for		- Always use the class scope of the object that bindTo() is called for
	- Always use the class scope of the function that calls bindTo()		- Always use the class scope of the function that calls bindTo()
		+	- Add a parameter to bindTo() to specify this.
		+	- Add some syntax to the closure definition to specify this.
		+	- Always use a dummy class scope so only public properties are accessible.

	This is still to be discussed.		This is still to be discussed.
Line 348:		Line 361:

	This may still be subject to discussion.		This may still be subject to discussion.
-
-	==== Important: Timeline ====
-
-	In order to be able to proceed to PHP 5.3 beta 1 quickly, I suggest the following timeline:
-
-	- For beta1, we make sure that proposal A (no closure-property-calling, no rebinding) is in CVS.
-	- post-beta1, we add those features to PHP after the details that are not entirely clear are discussed. If the discussion takes too long, we don't include that feature in PHP 5.3 but instead we wait for the next version (5.3.1 or 5.4 or 6.0 or whatever)
-
-	Important observation: If we have closure-property-calling but we DO NOT have rebinding, then this will certainly cause confusion among users coming from Javascript. Thus we should consider them a unit and only add them both or none at all.
-
-	===== Alternative, if no consensus can be reached =====
-
-	If no consensus regarding this can be reached, we could revert closures to be non-OOP-aware objects, i.e. that $this is never available inside closures. This would be a major step back in my eyes, but it would at least leave it open for discussion how to actually implement $this without breaking BC while being able to release PHP 5.3 without that support.

web:redesign:mockups - Added latest mock-ups.

stewartlord — 2009-11-16T07:04:50+00:00

1257317189		current
Line 2:		Line 2:

	Here are a few mockups/proposals made by people. Feedback and discussions take place on the webmaster mailing list (php-webmaster@lists.php.net) but here are links to (hopefully all) mockups:		Here are a few mockups/proposals made by people. Feedback and discussions take place on the webmaster mailing list (php-webmaster@lists.php.net) but here are links to (hopefully all) mockups:
		+
		+	Nov 14 by Daniel:
		+	* http://www.whitelands.com/daniel/php/alt-header-4a-daniel.png
		+
		+	Nov 3 by Stewart:
		+	* http://ambitious.ca/php/alt-header-4a.png

	Nov 1 by Stewart:		Nov 1 by Stewart:

rfc:autoload_include - add note about issues with byte code caches with the resource alternative proposal

lsmith — 2009-11-10T22:28:37+00:00

1257892117		current
Line 54:		Line 54:
	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".

-	2. 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 patch. The later would be superior since it would also enable the optional feature mentioned above. It would still however require file system access twice (unless the user implements a caching solution) and does not solve the edge case of a race condition.	+	2. 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 (unless the user implements a caching solution) and does not solve the edge case of a race condition.

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

1253559966		current
Line 223:		Line 223:
	Third party libraries are not available in our repositories. The reason are the miscellaneous restricted licenses and non open sources code. However, we are authorized to distribute them with our PHP releases but not their SDK.		Third party libraries are not available in our repositories. The reason are the miscellaneous restricted licenses and non open sources code. However, we are authorized to distribute them with our PHP releases but not their SDK.

		+	* ibm_db2 - [[internals:windows:libs:ibm_db2\| ibm_db2]]
	* msql - [[http://www.hughes.com.au/ \| Mini SQL]]		* msql - [[http://www.hughes.com.au/ \| Mini SQL]]
	* mssql/pdo_dblib - ntwdblib, only available with Microsoft SQL Server 2000 or earlier		* mssql/pdo_dblib - ntwdblib, only available with Microsoft SQL Server 2000 or earlier
	* oci8/pdo_oci - [[internals:windows:libs:oracle\| oracle]]		* oci8/pdo_oci - [[internals:windows:libs:oracle\| oracle]]
	* sybase_ct - [[http://www.sybase.com/products/databasemanagement/adaptiveserverenterprise \| Sybase Adaptive Server Enterprise]]		* sybase_ct - [[http://www.sybase.com/products/databasemanagement/adaptiveserverenterprise \| Sybase Adaptive Server Enterprise]]
		+


Line 248:		Line 250:
	\| gettext \| [[internals:windows:libs:gettext\| libintl]] \| [[http://www.php.net/gettext\|]] \| No \|		\| gettext \| [[internals:windows:libs:gettext\| libintl]] \| [[http://www.php.net/gettext\|]] \| No \|
	\| gmp\| [[internals:windows:libs:gmp\| libgmp]] or [[internals:windows:libs:mpir\| mpir]] \| [[http://www.php.net/gmp\|]] \| No \|		\| gmp\| [[internals:windows:libs:gmp\| libgmp]] or [[internals:windows:libs:mpir\| mpir]] \| [[http://www.php.net/gmp\|]] \| No \|
		+	\| ibm_db2\| [[internals:windows:libs:ibm_db2\|ibm_db2]] \| [[http://www.php.net/ibm_db2\|]] \| Yes \|
	\| imap \| [[internals:windows:libs:cclient\|cclient]] \| [[http://www.php.net/imap\|]] \| No \|		\| imap \| [[internals:windows:libs:cclient\|cclient]] \| [[http://www.php.net/imap\|]] \| No \|
	\| interbase \| [[internals:windows:libs:interbase\|ibase]] \| [[http://www.php.net/interbase\|]] \| No \|		\| interbase \| [[internals:windows:libs:interbase\|ibase]] \| [[http://www.php.net/interbase\|]] \| No \|