Imported from /home/lorry/working-area/delta_php2/php-5.4.13.tar.bz2.HEADphp-5.4.13master

3 files changed, 377 insertions, 0 deletions

diff --git a/Zend/RFCs/001.txt b/Zend/RFCs/001.txt
new file mode 100644
index 0000000..bf1d847
--- /dev/null
+++ b/Zend/RFCs/001.txt
@@ -0,0 +1,136 @@
+Revamped object model using object handles
+===========================================
+
+Background
+----------
+
+In the Zend Engine 1.0 (and its predecessor the PHP 3 scripting
+engine) the object model's design is that instantiated objects are
+language values. This means that when programmers are performing
+operations, such variable assignment and passing parameters to
+functions, objects are handled very similarly to the way other
+primitive types are handled such as integers and strings.
+Semantically this means that the whole object is being copied. The
+approach Java takes is different where one refers to objects by handle
+and not by value (one can think of a handle as an objects' ID).
+
+Need
+----
+
+Unfortunately, the approach taken up to now has severely limited the
+Zend Engine's object oriented model, both feature and simplicity
+wise. One of the main problems with the former approach is that object
+instantiation and duplication is very hard to control, a problem which
+can not only lead to inefficient development but also often to strange
+run-time behavior. Changing the object model to a handle oriented
+model will allow the addressing of many needs such as destructors,
+de-referencing method return values, tight control of object
+duplication and more.
+
+Overview
+--------
+
+The proposed object model is very much influenced by the Java
+model. In general, when you create a new object you will be getting a
+handle to the object instead of the object itself. When this handle is
+sent to functions, assigned and copied it is only the handle which is
+copied/sent/assigned. The object itself is never copied nor
+duplicated. This results in all handles of this object to always point
+at the same object making it a very consistent solution and saving
+unnecessary duplication and confusing behavior.
+
+Functionality
+-------------
+
+After this change the basic use of objects will be almost identical to
+previous versions of the scripting engine.  However, you won't bump
+into awkward and confusing copying & destructing of objects.  In order
+to create and use a new object instance you will do the following:
+$object = new MyClass(); $object->method();
+
+The previous code will assign $object the handle of a new instance of
+the class MyClass and call one of its methods.
+
+ 
+Consider the following code:
+
+1	class MyClass
+2	{
+3		function setMember($value)
+4		{
+5			$this->member = $value;
+6		}
+7	
+8		function getMember()
+9		{
+10			return $this->member;
+11		}
+12	}
+13	
+14	function foo($obj)
+15	{
+16		$obj->setMember("foo");
+17	}
+18	
+19	$object = new MyClass();
+20	$object->setMember("bar");
+21	foo($object);
+22	print $object->getMember();
+
+Without the new Java-like handles, at line 20 the objects' data member
+member is set to the string value of "bar".  Because of the internal
+representation of objects in the Zend Engine 1.0, the object is marked
+as a reference, and when it is sent by value to the function foo, it
+is duplicated (!).  Therefore, the call to foo() on line 21 will
+result in the $obj->setMember("foo") call being called on a duplicate
+of $object. Line 22 will then result in "bar" being printed.
+
+This is how the scripting engine has worked until today. Most
+developers are probably unaware of the fact that they aren't always
+talking to the same object but often duplicates; others may have
+realized this can usually be solved by always passing objects by
+reference (unless a replica is actually desired, which is uncommon).
+
+The new object model will allow for a much more intuitive
+implementation of the code.  On line 21, the object's handle (ID) is
+passed to foo() by value. Inside foo(), the object is fetched
+according to this handle and, therefore, the setMember() method is
+called on the originally instantiated object and not a copy.  Line 22
+will therefore result in "foo" being printed.  This approach gives
+developers tighter control of when objects are created and duplicated.
+An additional not-as-important benefit is that the object handle will
+be passed to foo() by value, which most probably will also save
+unnecessary duplication of the value containing the ID itself and thus
+additionally improving run-time performance.
+
+This was just a simple description of why the new object model solves
+awkward behavior and makes object handling much easier, intuitive and
+efficient.  The importance of this change goes far beyond what is
+mentioned in this section as you will see in further sections which
+describe new features with a majority of them being based on this
+change.
+
+Compatibility Notes
+--------------------
+
+Many PHP programmers aren't even aware of the copying quirks of the
+current object model and, therefore, there is a relatively good chance
+that the amount of PHP applications that will work out of the box or
+after a very small amount of modifications would be high.
+
+To simplify migration, version 2.0 will support an optional
+'auto-clone' feature, which will perform a cloning of the object
+whenever it would have been copied in version 1.0.  Optionally, it
+will also be possible to request that the engine will emit an E_NOTICE
+message whenever such an automatic clone occurs, in order to allow
+developers to gradually migrate to the version 2.0-style behavior
+(without automatic clones).
+
+Dependencies
+------------
+
+The new object model is not dependent on other features.  Many of the
+other Zend Engine 2.0 features, such as the $foo->bar()->barbara()
+syntax, destructors and others completely rely on this new object
+model.
+
diff --git a/Zend/RFCs/002.txt b/Zend/RFCs/002.txt
new file mode 100644
index 0000000..613ce9d
--- /dev/null
+++ b/Zend/RFCs/002.txt
@@ -0,0 +1,169 @@
+Title:           Zend 2.0 Namespaces
+Version:         $Id: 7d7cb885d85b5ffc3f7e14171bb226b1e3c711a4 $
+Status:          declined
+Maintainer:      Stig S. Bakken <ssb@php.net>
+Created:         2001-09-08
+Modified:        2001-09-08
+                  
+
+1. Background/Need
+==================
+
+PHP and Zend 1.0 have come to a point where a lot of reusable code is
+being written; from simple functions and classes to entire application
+frameworks.  It is becoming increasingly difficult to avoid symbol
+name collisions with the current scoping methods.
+
+The symbol scopes available in Zend 1.0 are the global scope, the
+class scope and the function scope.  All scopes but classes may
+contain variables, only the class and global scopes may contain
+functions, while only the global scope may contain constants and
+classes.  This means that all of Zend 1.0's scoping methods are
+inherently limited for solving symbol name collision problems.
+
+
+2. Overview
+===========
+
+Namespaces in Zend 2.0 provide a way to manage the symbol collision
+problem by making it possible to define multiple symbol tables able to
+contain all types of symbols.  Zend will get the notion of a current
+namespace, defaulting to the current global one.  The current name
+space may be changed on a file-by-file basis.  Symbols in other name
+spaces than the current one may be referenced using a new namespace
+operator.  It will be possible to "import" symbols from one namespace
+into another.
+
+
+3. Functionality
+================
+
+3.1. Namespace Syntax
+=====================
+
+The namespace operator ":" is used to refer to symbols in other
+namespaces than the current one:
+
+Class:          Namespace:class
+Function:       Namespace:function
+Static method:  Namespace:class::method
+Variable:       $Namespace:variable
+Constant:       Namespace:CONSTANT
+Class variable: $Namespace:class::variable
+
+To refer to symbols in the global namespace, symbols are prefixed with
+only the namespace operator:
+
+Class:          :class
+Function:       :function
+Static method:  :class::method
+Variable:       $:variable
+Constant:       :CONSTANT
+Class variable: $:class::variable
+
+Note: $:variable will effectively be just another syntax for
+$GLOBALS['variable'].
+
+A namespace may have a name containing a ":", it is always the last
+":" character in the symbol qualifier that is the actual namespace
+operator:
+
+Class:          Name:Space:class
+Function:       Name:Space:function
+Static method:  Name:Space:class::method
+Variable:       $Name:Space:variable
+Constant:       Name:Space:CONSTANT
+Class variable: $Name:Space:class::variable
+
+(Here, the ":" between "Name" and "Space" is part of the name, it is
+the one after "Space" that is the namespace operator.)
+
+
+3.2. Defining Namespaces
+========================
+
+Individual files may define a namespace that will apply to the entire
+file.  If no "namespace" operator occurs in the file, it will be in
+the global namespace:
+
+ 1 namespace HTML;
+ 2 
+ 3 class Form {
+ 4     function Form() {
+ 5         // constructor
+ 6     }
+ 7     // ...
+ 8 }
+
+Or with the "nested" name syntax:
+
+ 1 namespace HTML:Form;
+ 2 
+ 3 class Image {
+ 4     var $src;
+ 5     function Image($src) {
+ 6         $this->src = $src;
+ 7     }
+ 8     // ...
+ 9 }
+
+Code executed within the "HTML" namespace may refer to the Form class
+as just "Form".  Code executed from within other namespaces has to
+refer to it as "HTML:Form".  The "namespace" statement must occur
+before any other statements in the file.
+
+# [ssb 2001-09-08]:
+# Should it be possible to "add" symbols to a namespace by including a
+# second file with the same namespace statement?
+
+
+3.3. Importing Symbols
+======================
+
+It is possible to import symbols from another namespace into the
+current one with the "import" statement:
+
+  import * from HTML;          // all symbols
+
+  import Form from HTML;       // single symbols
+
+  import Form,Table from HTML; // multiple symbols
+
+There is a potential for name clashes between symols of different
+types that have the same qualifier syntax.  These are resolved in this
+order: class, function, constant.
+
+Optionally, the symbol type may be explicitly given to import (as
+"class", "function", "variable" or "constant"):
+
+  import class Form from HTML;
+
+And finally, you may import all symbols of a given type:
+
+  import constant * from HTML:Table;
+
+The namespace with its symbols must already be defined before using
+"import".
+
+
+4. Compatibility Notes
+======================
+
+Old code that does not take advantage of namespaces will run without
+modifications.
+
+
+5. Dependencies
+===============
+
+The class variable syntax depends on this class variables being
+implemented in the new ZE2 object model.
+
+
+6. Acknowledgements
+===================
+
+Andi Gutmans <andi@zend.com> and Zeev Suraski <zeev@zend.com> for
+initial ZE2 namespaces proposal
+
+Dean Hall <php@apt7.com> for the initial symbol qualification syntax
diff --git a/Zend/RFCs/003.txt b/Zend/RFCs/003.txt
new file mode 100644
index 0000000..d844f8a
--- /dev/null
+++ b/Zend/RFCs/003.txt
@@ -0,0 +1,72 @@
+Title:           Loose type requirements for functions
+Version:         $Id: 30fb4cec4912f30d0600d45fda082d7eadf58521 $
+Status:          draft
+Maintainer:      Brian Moon <brianm@dealnews.com>
+Created:         2001-09-17
+Modified:        2001-09-17
+
+
+1. Background/Need
+==================
+
+Many internal function of PHP will reject parameters because of their
+type (the array and variable function come to mind).  For userland
+this is not an easy task as there is no uniform way to do it.  An
+addition to the engine for requiring loose types would allow
+delevopers to know that the data passed to their functions is of the
+correct type and reduce the need for duplicating the same code in
+every function to check for the type of data.
+
+
+2. Overview
+===========
+
+Loose typing mostly means evaluating the contents of the variable and
+not the type of the variable itself.  The requirements for this would
+and should work much like several of the is_* functions do now.
+
+The typing of parameters would be optional and those not typed would
+simply continue to be treated as they are now.
+
+3. Functionality
+================
+
+3.1. Allowed Types
+==================
+
+Only loose types should be needed to ensure the data is usable by the
+function.  Duplicating the functionallity of is_scalar, is_resource,
+is_array and is_object should give developers all the information they
+need to use a variable correctly.
+
+3.2. Syntax
+===========
+
+The current function syntax should be expanded to allow typing of
+variables inline in a C style.
+
+function foo ($var){
+}
+
+could be changed to require an array such as:
+
+function foo (array $var){
+}
+
+3.3. Errors
+===========
+
+Mis-matches in type should be reported as fatal errors and should halt
+the execution of a script as that function can not be run and code
+following could not reliably run.
+
+
+4. Compatibility Notes
+======================
+
+Old code that does not take advantage of this will run without
+modifications.
+
+
+
+