From: Brian Moon Date: Mon, 17 Sep 2001 16:01:20 +0000 (+0000) Subject: adding RFC for loose type requirements for functions X-Git-Tag: PRE_SUBST_Z_MACROS~80 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=b285fae0bc7724b7c66ab0859b527ed4f528b848;p=php adding RFC for loose type requirements for functions --- diff --git a/Zend/RFCs/003.txt b/Zend/RFCs/003.txt new file mode 100644 index 0000000000..aa90691b19 --- /dev/null +++ b/Zend/RFCs/003.txt @@ -0,0 +1,72 @@ +Title: Loose type requirements for functions +Version: $Revision$ +Status: draft +Maintainer: Brian Moon +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. + + + +