[PHP-DOC] #38011 [NEW]: suggest $foo = &new Bar(); for PHP4
From: joliver at gmx dot at
Operating system: all
PHP version: Irrelevant
PHP Bug Type: Documentation problem
Bug description: suggest $foo = &new Bar(); for PHP4
Description:
Please provide an advice to PHP4 users to use
$foo = &new Bar();
instead of $foo = new Bar();
Contrary to the examples in the documentation, in PHP4
instances of objects should be initialisised with
$foo = &new Bar();
because here $foo is a reference to the created instance
of Bar, while for
$foo = new Bar();
$foo is a copy(!) of the instance.
Appart from performance and memory issues, in the second
case parameters in the constructors will be copied to,
because the whole object is copied. That means for
example, that for:
$foo = new Bar($this)
$foo is an instance of Bar where $this is not the owner of
that instance any more, because $foo is a copy of the
newly created instance.
Good example in german:
http://www.usegroup.de/software/phptutorial/klassen_und_objekte.html#ref_owner
Reproduce code:
---
greeting;
}
function myC1()
{
$this->greeting="Howdy";
$this->theC2=new myC2($this);
}
}
class myC2
{
var $owner;
function myC2(&$owner)
{
$this->owner=&$owner;
$this->owner->greeting="bah";
}
function something()
{
$this->owner->greeting="hulla";
// This is supposed to change myC1's greeting to hulla, overwriting
"bah".
}
}
$test=new myC1(); //$test=&new myC1();
$test->theC2->something();
$test->sayHello();
?>
Expected result:
$test=&new myC1();
returns the excepted result in PHP4. Please provide that
advice for PHP4 users in the documentation.
Actual result:
--
As described above, $test=new myC1(); returns a copy of
the instance, therefore $this in myC1 gets lost.
An advice for PHP4 users would be helpful, in my opinion
in PHP4
$foo=&new Bar(); should be used instead of
$foo=new Bar(;), which is not mentioned anywhere in the
documentation.
(of course i know in PHP5 this as been fixed because
objects are passed by reference.)
Thank you!
Oliver
--
Edit bug report at http://bugs.php.net/?id=38011&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38011&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38011&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38011&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38011&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38011&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38011&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38011&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38011&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38011&r=support
Expected behavior:http://bugs.php.net/fix.php?id=38011&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38011&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38011&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38011&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38011&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38011&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38011&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38011&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38011&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38011&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38011&r=mysqlcfg
[PHP-DOC] cvs: phpdoc /en/reference/expect/functions expect-expectl.xml
michael Tue Jul 4 14:50:10 2006 UTC Modified files: /phpdoc/en/reference/expect/functions expect-expectl.xml Log: Add last prototype change into changelog. http://cvs.php.net/viewvc.cgi/phpdoc/en/reference/expect/functions/expect-expectl.xml?r1=1.8&r2=1.9&diff_format=u Index: phpdoc/en/reference/expect/functions/expect-expectl.xml diff -u phpdoc/en/reference/expect/functions/expect-expectl.xml:1.8 phpdoc/en/reference/expect/functions/expect-expectl.xml:1.9 --- phpdoc/en/reference/expect/functions/expect-expectl.xml:1.8 Tue Jul 4 08:26:08 2006 +++ phpdoc/en/reference/expect/functions/expect-expectl.xml Tue Jul 4 14:50:10 2006 @@ -1,5 +1,5 @@ - + expect_expectl @@ -108,6 +108,30 @@ EXP_FULLBUFFER + + &reftitle.changelog; + + + + + + &Version; + &Description; + + + + + 0.2.1 + + Prior to version 0.2.1, in match parameter a match string was returned, + not an array of match substrings. + + + + + + + &reftitle.examples;
Re: [PHP-DOC] cvs: phpdoc /en/reference/expect/functions expect-expectl.xml
On 7/4/06, Michael Spector <[EMAIL PROTECTED]> wrote: Where should I add changelog? http://doc.php.net/php/dochowto/chapter-skeletons.php See the first example. Document the fact that prior to expect 0.2.1 $match was string, not an array... -Hannes Hannes Magnusson wrote: > On 7/4/06, Michael Spector <[EMAIL PROTECTED]> wrote: >> michael Tue Jul 4 08:26:08 2006 UTC >> >> Modified files: >> /phpdoc/en/reference/expect/functions expect-expectl.xml >> Log: >> Fix function prototype, according to latest changes. >> >> >> http://cvs.php.net/viewvc.cgi/phpdoc/en/reference/expect/functions/expect-expectl.xml?r1=1.7&r2=1.8&diff_format=u >> >> Index: phpdoc/en/reference/expect/functions/expect-expectl.xml >> diff -u phpdoc/en/reference/expect/functions/expect-expectl.xml:1.7 >> phpdoc/en/reference/expect/functions/expect-expectl.xml:1.8 >> --- phpdoc/en/reference/expect/functions/expect-expectl.xml:1.7 Tue >> Mar 7 12:07:16 2006 >> +++ phpdoc/en/reference/expect/functions/expect-expectl.xml Tue >> Jul 4 08:26:08 2006 >> @@ -1,5 +1,5 @@ >> >> - >> + >> >> >>expect_expectl >> @@ -13,15 +13,18 @@ >> mixedexpect_expectl >> >> resourceexpect >> >> >> arraycases >> >> - string> role="reference">match >> + array> role="reference">match > > This is just evil. Why don't you add changelog? -- Michael Spector, Software Developer Zend Technologies +972-3-6139665 ext.223 ICQ: 7279639 AIM: spektom972 Yahoo: spektom MSN: [EMAIL PROTECTED]
Re: [PHP-DOC] cvs: phpdoc /en/reference/expect/functions expect-expectl.xml
Where should I add changelog? Hannes Magnusson wrote: On 7/4/06, Michael Spector <[EMAIL PROTECTED]> wrote: michael Tue Jul 4 08:26:08 2006 UTC Modified files: /phpdoc/en/reference/expect/functions expect-expectl.xml Log: Fix function prototype, according to latest changes. http://cvs.php.net/viewvc.cgi/phpdoc/en/reference/expect/functions/expect-expectl.xml?r1=1.7&r2=1.8&diff_format=u Index: phpdoc/en/reference/expect/functions/expect-expectl.xml diff -u phpdoc/en/reference/expect/functions/expect-expectl.xml:1.7 phpdoc/en/reference/expect/functions/expect-expectl.xml:1.8 --- phpdoc/en/reference/expect/functions/expect-expectl.xml:1.7 Tue Mar 7 12:07:16 2006 +++ phpdoc/en/reference/expect/functions/expect-expectl.xml Tue Jul 4 08:26:08 2006 @@ -1,5 +1,5 @@ - + expect_expectl @@ -13,15 +13,18 @@ mixedexpect_expectl resourceexpect arraycases - stringrole="reference">match + arrayrole="reference">match This is just evil. Why don't you add changelog? -- Michael Spector, Software Developer Zend Technologies +972-3-6139665 ext.223 ICQ: 7279639 AIM: spektom972 Yahoo: spektom MSN: [EMAIL PROTECTED]
Re: [PHP-DOC] cvs: phpdoc /en/reference/expect/functions expect-expectl.xml
On 7/4/06, Michael Spector <[EMAIL PROTECTED]> wrote: michael Tue Jul 4 08:26:08 2006 UTC Modified files: /phpdoc/en/reference/expect/functions expect-expectl.xml Log: Fix function prototype, according to latest changes. http://cvs.php.net/viewvc.cgi/phpdoc/en/reference/expect/functions/expect-expectl.xml?r1=1.7&r2=1.8&diff_format=u Index: phpdoc/en/reference/expect/functions/expect-expectl.xml diff -u phpdoc/en/reference/expect/functions/expect-expectl.xml:1.7 phpdoc/en/reference/expect/functions/expect-expectl.xml:1.8 --- phpdoc/en/reference/expect/functions/expect-expectl.xml:1.7 Tue Mar 7 12:07:16 2006 +++ phpdoc/en/reference/expect/functions/expect-expectl.xml Tue Jul 4 08:26:08 2006 @@ -1,5 +1,5 @@ - + expect_expectl @@ -13,15 +13,18 @@ mixedexpect_expectl resourceexpect arraycases - stringmatch + arraymatch This is just evil. Why don't you add changelog?
Re: [PHP-DOC] ext/mysql return types
On Tue, 04 Jul 2006, Nuno Lopes wrote: The answer to your questions are answered in our howto. Mainly here: http://doc.php.net/php/dochowto/chapter-conventions.php Quoting the important part (for now): "Do not use mixed, if the return value is of a certain (not boolean) type, and FALSE only on error. Provide the primary return type as the return type of the function, and write down in the explanation, that it returns FALSE on error. Use &return.success; if the function returns TRUE on success, and FALSE on failure. " Oh, okay. Seems I missed this part. So 2) '"mixed" return values on error paths" is clearly a "no". yep But what about 1) '"mixed" return values in normal usage', for example mysql_query(), which may return TRUE in normal usage? Or mysql_fetch_array() which returns FALSE if there are no more rows -- should this be considered an error condition? At least the mysql_query() issue confused someone on IRC today. if the function returns different return types on normal usage you should use mixed. Don't forget to carefully document that. (btw, while you are at it, you may consider upgrading the files you touch to the "new" doc style, which is simpler to maintain IMHO. take a look at http://wiki.phpdoc.info/DocSkel) (Besides this, I still consider my corrections 3) as valid.) yes, yes. see the link above. Thanks for your contributions, Nuno Kind regards, Horst - Original Message - >Hi, > >I just noticed that the return types of some ext/mysql functions are not >correct, or at least misleading. > > >1) "mixed" return values in normal usage > > >In the description of mysql_query(), the interface is shown as >follows: > >resource mysql_query ( string query [, resource link_identifier] ) > >But the "Return Values" section makes clear that the return type could >also be a boolean; shouldn't the return type be "mixed" instead of >"resource", as for example in the documentation to mysqli_query() -- or >has this been documented this way for a reason? > >All ext/mysql functions which return mixed types but are not >properly documented to do so: >* mysql_query >* mysql_db_query >* mysql_fetch_array >* mysql_fetch_assoc >* mysql_fetch_field (here the docs even lack "or FALSE if there are no > more rows" in the "Return Values" section) >* mysql_fetch_object >* mysql_fetch_row >* mysql_unbuffered_query > > >2) "mixed" return values on error paths >--- > >Similarly this is true for mysql_connect(), although here FALSE is only >returned on failure; the "normal" return type is "resource". Is this >intentional, or should it also be corrected to "mixed"? (I'd vote for >the former.) > >All ext/mysql functions which return FALSE on failure but are not >documented to do so in the "Description": >mysql_connect, mysql_db_name, mysql_fetch_lengths, mysql_field_flags, >mysql_field_len, mysql_field_name, mysql_field_table, mysql_field_type, >mysql_get_host_info, mysql_get_proto_info, mysql_get_server_info, >mysql_info, mysql_insert_id, mysql_list_dbs, mysql_list_fields, >mysql_list_processes, mysql_list_tables, mysql_num_fields, >mysql_num_rows, mysql_pconnect, mysql_real_escape_string, mysql_result, >mysql_stat (returns NULL on failure, not FALSE), mysql_tablename, >mysql_thread_id. > > >3) minor corrections > > >Beyond this, >* mysql_field_seek needs a "Return Values" section (although it is > intuitive that it returns TRUE on success and FALSE on failure). >* mysql_field_table and mysql_field_type need "returns FALSE on failure" > to be documented. > > >Any comments/objections to these corrections? If nobody vetoes, I would >starting to fix 1) and 3) the next days. > >Kind regards, >Horst -- PGP-Key 0xD40E0E7A
Re: [PHP-DOC] ext/mysql return types
On Tue, 04 Jul 2006, Nuno Lopes wrote: > The answer to your questions are answered in our howto. Mainly here: > http://doc.php.net/php/dochowto/chapter-conventions.php > > Quoting the important part (for now): > "Do not use mixed, if the return value is of a certain (not boolean) type, > and FALSE only on error. Provide the primary return type as the return type > of the function, and write down in the explanation, that it returns FALSE > on error. Use &return.success; if the function returns TRUE on success, and > FALSE on failure. " Oh, okay. Seems I missed this part. So 2) '"mixed" return values on error paths" is clearly a "no". But what about 1) '"mixed" return values in normal usage', for example mysql_query(), which may return TRUE in normal usage? Or mysql_fetch_array() which returns FALSE if there are no more rows -- should this be considered an error condition? At least the mysql_query() issue confused someone on IRC today. (Besides this, I still consider my corrections 3) as valid.) Kind regards, Horst > - Original Message - > >Hi, > > > >I just noticed that the return types of some ext/mysql functions are not > >correct, or at least misleading. > > > > > >1) "mixed" return values in normal usage > > > > > >In the description of mysql_query(), the interface is shown as > >follows: > > > >resource mysql_query ( string query [, resource link_identifier] ) > > > >But the "Return Values" section makes clear that the return type could > >also be a boolean; shouldn't the return type be "mixed" instead of > >"resource", as for example in the documentation to mysqli_query() -- or > >has this been documented this way for a reason? > > > >All ext/mysql functions which return mixed types but are not > >properly documented to do so: > >* mysql_query > >* mysql_db_query > >* mysql_fetch_array > >* mysql_fetch_assoc > >* mysql_fetch_field (here the docs even lack "or FALSE if there are no > > more rows" in the "Return Values" section) > >* mysql_fetch_object > >* mysql_fetch_row > >* mysql_unbuffered_query > > > > > >2) "mixed" return values on error paths > >--- > > > >Similarly this is true for mysql_connect(), although here FALSE is only > >returned on failure; the "normal" return type is "resource". Is this > >intentional, or should it also be corrected to "mixed"? (I'd vote for > >the former.) > > > >All ext/mysql functions which return FALSE on failure but are not > >documented to do so in the "Description": > >mysql_connect, mysql_db_name, mysql_fetch_lengths, mysql_field_flags, > >mysql_field_len, mysql_field_name, mysql_field_table, mysql_field_type, > >mysql_get_host_info, mysql_get_proto_info, mysql_get_server_info, > >mysql_info, mysql_insert_id, mysql_list_dbs, mysql_list_fields, > >mysql_list_processes, mysql_list_tables, mysql_num_fields, > >mysql_num_rows, mysql_pconnect, mysql_real_escape_string, mysql_result, > >mysql_stat (returns NULL on failure, not FALSE), mysql_tablename, > >mysql_thread_id. > > > > > >3) minor corrections > > > > > >Beyond this, > >* mysql_field_seek needs a "Return Values" section (although it is > > intuitive that it returns TRUE on success and FALSE on failure). > >* mysql_field_table and mysql_field_type need "returns FALSE on failure" > > to be documented. > > > > > >Any comments/objections to these corrections? If nobody vetoes, I would > >starting to fix 1) and 3) the next days. > > > >Kind regards, > >Horst -- PGP-Key 0xD40E0E7A
Re: [PHP-DOC] ext/mysql return types
The answer to your questions are answered in our howto. Mainly here: http://doc.php.net/php/dochowto/chapter-conventions.php Quoting the important part (for now): "Do not use mixed, if the return value is of a certain (not boolean) type, and FALSE only on error. Provide the primary return type as the return type of the function, and write down in the explanation, that it returns FALSE on error. Use &return.success; if the function returns TRUE on success, and FALSE on failure. " Nuno - Original Message - Hi, I just noticed that the return types of some ext/mysql functions are not correct, or at least misleading. 1) "mixed" return values in normal usage In the description of mysql_query(), the interface is shown as follows: resource mysql_query ( string query [, resource link_identifier] ) But the "Return Values" section makes clear that the return type could also be a boolean; shouldn't the return type be "mixed" instead of "resource", as for example in the documentation to mysqli_query() -- or has this been documented this way for a reason? All ext/mysql functions which return mixed types but are not properly documented to do so: * mysql_query * mysql_db_query * mysql_fetch_array * mysql_fetch_assoc * mysql_fetch_field (here the docs even lack "or FALSE if there are no more rows" in the "Return Values" section) * mysql_fetch_object * mysql_fetch_row * mysql_unbuffered_query 2) "mixed" return values on error paths --- Similarly this is true for mysql_connect(), although here FALSE is only returned on failure; the "normal" return type is "resource". Is this intentional, or should it also be corrected to "mixed"? (I'd vote for the former.) All ext/mysql functions which return FALSE on failure but are not documented to do so in the "Description": mysql_connect, mysql_db_name, mysql_fetch_lengths, mysql_field_flags, mysql_field_len, mysql_field_name, mysql_field_table, mysql_field_type, mysql_get_host_info, mysql_get_proto_info, mysql_get_server_info, mysql_info, mysql_insert_id, mysql_list_dbs, mysql_list_fields, mysql_list_processes, mysql_list_tables, mysql_num_fields, mysql_num_rows, mysql_pconnect, mysql_real_escape_string, mysql_result, mysql_stat (returns NULL on failure, not FALSE), mysql_tablename, mysql_thread_id. 3) minor corrections Beyond this, * mysql_field_seek needs a "Return Values" section (although it is intuitive that it returns TRUE on success and FALSE on failure). * mysql_field_table and mysql_field_type need "returns FALSE on failure" to be documented. Any comments/objections to these corrections? If nobody vetoes, I would starting to fix 1) and 3) the next days. Kind regards, Horst -- PGP-Key 0xD40E0E7A
[PHP-DOC] cvs: phpdoc /en/install ini.xml
nlopess Tue Jul 4 11:03:22 2006 UTC Modified files: /phpdoc/en/install ini.xml Log: exchange the PHPRC var and the registry key order for php 5.2 http://cvs.php.net/viewvc.cgi/phpdoc/en/install/ini.xml?r1=1.13&r2=1.14&diff_format=u Index: phpdoc/en/install/ini.xml diff -u phpdoc/en/install/ini.xml:1.13 phpdoc/en/install/ini.xml:1.14 --- phpdoc/en/install/ini.xml:1.13 Thu May 11 09:38:23 2006 +++ phpdoc/en/install/ini.xml Tue Jul 4 11:03:22 2006 @@ -1,5 +1,5 @@ - + Runtime Configuration @@ -27,13 +27,14 @@ - HKEY_LOCAL_MACHINE\SOFTWARE\PHP\IniFilePath - (Windows Registry location) + The PHPRC environment variable. Before PHP 5.2.0 + this was checked after the registry key mentioned below. - The PHPRC environment variable + HKEY_LOCAL_MACHINE\SOFTWARE\PHP\IniFilePath + (Windows Registry location)
[PHP-DOC] cvs: phpdoc /en/reference/pgsql/functions pg-result-error.xml
nlopess Tue Jul 4 11:13:25 2006 UTC Modified files: /phpdoc/en/reference/pgsql/functionspg-result-error.xml Log: fix return value, per user note http://cvs.php.net/viewvc.cgi/phpdoc/en/reference/pgsql/functions/pg-result-error.xml?r1=1.9&r2=1.10&diff_format=u Index: phpdoc/en/reference/pgsql/functions/pg-result-error.xml diff -u phpdoc/en/reference/pgsql/functions/pg-result-error.xml:1.9 phpdoc/en/reference/pgsql/functions/pg-result-error.xml:1.10 --- phpdoc/en/reference/pgsql/functions/pg-result-error.xml:1.9 Wed Nov 30 04:06:54 2005 +++ phpdoc/en/reference/pgsql/functions/pg-result-error.xml Tue Jul 4 11:13:25 2006 @@ -1,5 +1,5 @@ - + @@ -53,7 +53,8 @@ &reftitle.returnvalues; - &return.success; + Returns a string if there is an error associated with the + result parameter, &false; otherwise.
[PHP-DOC] ext/mysql return types
Hi, I just noticed that the return types of some ext/mysql functions are not correct, or at least misleading. 1) "mixed" return values in normal usage In the description of mysql_query(), the interface is shown as follows: resource mysql_query ( string query [, resource link_identifier] ) But the "Return Values" section makes clear that the return type could also be a boolean; shouldn't the return type be "mixed" instead of "resource", as for example in the documentation to mysqli_query() -- or has this been documented this way for a reason? All ext/mysql functions which return mixed types but are not properly documented to do so: * mysql_query * mysql_db_query * mysql_fetch_array * mysql_fetch_assoc * mysql_fetch_field (here the docs even lack "or FALSE if there are no more rows" in the "Return Values" section) * mysql_fetch_object * mysql_fetch_row * mysql_unbuffered_query 2) "mixed" return values on error paths --- Similarly this is true for mysql_connect(), although here FALSE is only returned on failure; the "normal" return type is "resource". Is this intentional, or should it also be corrected to "mixed"? (I'd vote for the former.) All ext/mysql functions which return FALSE on failure but are not documented to do so in the "Description": mysql_connect, mysql_db_name, mysql_fetch_lengths, mysql_field_flags, mysql_field_len, mysql_field_name, mysql_field_table, mysql_field_type, mysql_get_host_info, mysql_get_proto_info, mysql_get_server_info, mysql_info, mysql_insert_id, mysql_list_dbs, mysql_list_fields, mysql_list_processes, mysql_list_tables, mysql_num_fields, mysql_num_rows, mysql_pconnect, mysql_real_escape_string, mysql_result, mysql_stat (returns NULL on failure, not FALSE), mysql_tablename, mysql_thread_id. 3) minor corrections Beyond this, * mysql_field_seek needs a "Return Values" section (although it is intuitive that it returns TRUE on success and FALSE on failure). * mysql_field_table and mysql_field_type need "returns FALSE on failure" to be documented. Any comments/objections to these corrections? If nobody vetoes, I would starting to fix 1) and 3) the next days. Kind regards, Horst -- PGP-Key 0xD40E0E7A
[PHP-DOC] cvs: phpdoc /en/reference/mysql/functions mysql-info.xml
hsc Tue Jul 4 10:29:34 2006 UTC Modified files: /phpdoc/en/reference/mysql/functionsmysql-info.xml Log: style; missing period added http://cvs.php.net/viewvc.cgi/phpdoc/en/reference/mysql/functions/mysql-info.xml?r1=1.9&r2=1.10&diff_format=u Index: phpdoc/en/reference/mysql/functions/mysql-info.xml diff -u phpdoc/en/reference/mysql/functions/mysql-info.xml:1.9 phpdoc/en/reference/mysql/functions/mysql-info.xml:1.10 --- phpdoc/en/reference/mysql/functions/mysql-info.xml:1.9 Thu Mar 31 07:47:25 2005 +++ phpdoc/en/reference/mysql/functions/mysql-info.xml Tue Jul 4 10:29:34 2006 @@ -1,5 +1,5 @@ - + mysql_info @@ -31,8 +31,8 @@ Returns information about the statement on success, or &false; on failure. See the example below for which statements provide information, - and what the returned value may look like. Statements that aren't listed - will return &false; + and what the returned value may look like. Statements that are not listed + will return &false;.
[PHP-DOC] cvs: phpdoc /en/reference/expect/functions expect-expectl.xml
michael Tue Jul 4 08:26:08 2006 UTC Modified files: /phpdoc/en/reference/expect/functions expect-expectl.xml Log: Fix function prototype, according to latest changes. http://cvs.php.net/viewvc.cgi/phpdoc/en/reference/expect/functions/expect-expectl.xml?r1=1.7&r2=1.8&diff_format=u Index: phpdoc/en/reference/expect/functions/expect-expectl.xml diff -u phpdoc/en/reference/expect/functions/expect-expectl.xml:1.7 phpdoc/en/reference/expect/functions/expect-expectl.xml:1.8 --- phpdoc/en/reference/expect/functions/expect-expectl.xml:1.7 Tue Mar 7 12:07:16 2006 +++ phpdoc/en/reference/expect/functions/expect-expectl.xml Tue Jul 4 08:26:08 2006 @@ -1,5 +1,5 @@ - + expect_expectl @@ -13,15 +13,18 @@ mixedexpect_expectl resourceexpect arraycases - stringmatch + arraymatch Waits until the output from a process matches one of the patterns, a specified time period has passed, or an EOF is seen. - If match is provided, then it is filled with the - result of search. + If match is provided, then it is filled with the result of search. + The matched string can be found in match[0]. + The match substrings (according to the parentheses) in the original pattern can be found + in match[1], match[2], and so + on, up to match[9] (the limitation of libexpect).
