Re: [PHP-DEV] [PATCH] Two bugs in variable destruction
Hello Vesselin, Wednesday, October 22, 2003, 8:43:39 AM, you wrote: > Hello. > There are two bugs that show when code is executed from an object destructor and > PHP is compiled in debug mode. Both bugs cause the zend_hash_find() to fail in the > IS_CONSISTENT() macro. [...] > And here is a patch that fixes these two bugs: [...] Besides your quick and dirty patch here's a patch that allows the destructors to do their job correctly: http://marcus-boerger.de/php/ext/ze2/ze2-shutdown-20031002.diff.txt -- Best regards, Marcusmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] request for thread safety advice
netcat wrote: Hi, internals. Please send me (post here i mean) a few links about 1. thread safety in general 2. thread saftey in php 3. I'm doing wrapper for librep wich is not thread safe (so mailing archives say). Do I need to know something special ? After doing some googling i found thise for #1 http://www.unix.org/version2/whatsnew/threads.html http://www.unix.org/version2/whatsnew/threadsref.html is that a good reading ? any better suggestions for google requests than thise : c thread safety -mail -archive -lists c thread safety tutor ? I couldn't find anything for #2 but it's not less important than #1 :) Thanks for all the replies. I will probably have more questions when i'll have the time to continue working on the project. -- NetCat FREE 10MB email + Antivirus + AntiSpam + POP3 + more Get it at http://www.doal.co.il:81/free/?c=both -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Two bugs in variable destruction
Hello. I looked at your patch but why is it better than current code? In both cases (current code and your code) the symtable and all objects are destroyed. What is the difference? - http://www.Elmaz.com - Запознанства -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] database driver: no more rows
Hi, I would appreciate it if the database extensions would no longer return false when no rows are left in the result set but instead return null. The current way of returning false creates a level of ambiguity which can lead to serious issue in error handling. For example in mysql there is no way in knowing if you get false and then check for an error if the error was actually created by the fetch call or if the error was created by some other call to any of the mysql functions. Please see this bug for another example: http://bugs.php.net/bug.php?id=22328 Regards, Lukas Smith [EMAIL PROTECTED] ___ BackendMedia www.backendmedia.com [EMAIL PROTECTED] Linn Zwoch Smith GbR Pariser Str. 44 D-10707 Berlin Tel +49 30 83 22 50 00 Fax +49 30 83 22 50 07 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] database driver: no more rows
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I wouldn't mind such a change myself, however what about all the installations where people do while (*fetch_row() !== false) ? Ilia -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/lrviLKekh381/CERAigRAJ0fRN4pB7YotuUscTQPZIHalgJcaACfel/2 12EFNHs3rQT+/C7w02mDxGs= =RvvP -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] database driver: no more rows
> From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 22, 2003 7:18 PM > To: Lukas Smith; 'PHP Development' > Subject: Re: [PHP-DEV] database driver: no more rows > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I wouldn't mind such a change myself, however what about all the > installations > where people do while (*fetch_row() !== false) ? Yeah ... php5 would be a good time to make this change. I don't assume that a lot of people will actually do !== since in those methods you either get an array or false .. Regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] database driver: no more rows
I wouldn't mind such a change myself, however what about all the installations where people do while (*fetch_row() !== false) ? Wouldn't it be a lot easier to do it the other way around ? I mean, the semantics of returning false when a fetch cannot be executed because aren't any rows left is perfectly clear, and returning NULL when the result cannot be determined (because of an error) is also better than returning any other value (like 'false'). This would also be easier to carry out while maintaining BC. -- Ard -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] database driver: no more rows
> From: Ard Biesheuvel [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 22, 2003 7:56 PM > To: [EMAIL PROTECTED] > Subject: Re: [PHP-DEV] database driver: no more rows > > >>I wouldn't mind such a change myself, however what about all the > >>installations > >>where people do while (*fetch_row() !== false) ? > > Wouldn't it be a lot easier to do it the other way around ? > I mean, the semantics of returning false when a fetch cannot be executed > because aren't any rows left is perfectly clear, and returning NULL when > the result cannot be determined (because of an error) is also better > than returning any other value (like 'false'). > > This would also be easier to carry out while maintaining BC. Err .. I don't agree. Null means no data False means error. Regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Proposal: Dangling comma in function call parameters
Hello everybody,
just joined the internals list (after being absent from php developers
lists for a while) so excuse my ignorance if any topic I bring up has
been discussed already. I checked the archives but couldn't find anything...
Proposal: Allow dangling commas in function call parameters.
Reasoning: We use some handy vararg tool functions and it's nice to be
able to write
foo(
1,
2,
3,
);
since it's then easy to add a new parameter without having to add a
comma to the previous list.
This would be symmetrical to the array() syntax. The patch for zend
(php4 from cvs) would be minimal and I can't see any
backwards-compatibility issues right now (patch attached).
Any opinions?
Regards,
- Chris
Index: Zend/zend_language_parser.y
===
RCS file: /repository/Zend/Attic/zend_language_parser.y,v
retrieving revision 1.23
diff -u -r1.23 zend_language_parser.y
--- Zend/zend_language_parser.y 4 Aug 2002 06:39:44 - 1.23
+++ Zend/zend_language_parser.y 22 Oct 2003 21:28:45 -
@@ -336,7 +336,7 @@
function_call_parameter_list:
- non_empty_function_call_parameter_list { $$ = $1; }
+ non_empty_function_call_parameter_list possible_comma { $$ = $1; }
| /* empty */ { $$.u.constant.value.lval =
0; }
;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] database driver: no more rows
Err .. I don't agree. Null means no data False means error. Maybe historically (PHP-wise) it does. But the way I see it, every fetch() can 'fail' for two reasons: an expected well-defined reason (eof), and an unexpected undefined reason (error). Labelling the well-defined reason as 'false' and the undefined reason as 'null' is really quite defendable. -- Ard -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] database driver: no more rows
At 11:49 PM 10/22/2003 +0200, Ard Biesheuvel wrote: Err .. I don't agree. Null means no data False means error. Maybe historically (PHP-wise) it does. But the way I see it, every fetch() can 'fail' for two reasons: an expected well-defined reason (eof), and an unexpected undefined reason (error). Labelling the well-defined reason as 'false' and the undefined reason as 'null' is really quite defendable. This isn't something I'd like to see changed. I actually think there are probably lots of people who do !== false and we could screw up a lot of scripts. I see the advantage of being able to tell the difference but I think it's not big enough to change it now. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] database driver: no more rows
> From: Andi Gutmans [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 22, 2003 11:58 PM > At 11:49 PM 10/22/2003 +0200, Ard Biesheuvel wrote: > >>Err .. I don't agree. > >>Null means no data > >>False means error. > > > >Maybe historically (PHP-wise) it does. > >But the way I see it, every fetch() can 'fail' for two reasons: an > >expected well-defined reason (eof), and an unexpected undefined reason > >(error). Labelling the well-defined reason as 'false' and the undefined > >reason as 'null' is really quite defendable. > > > This isn't something I'd like to see changed. I actually think there are > probably lots of people who do !== false and we could screw up a lot of > scripts. I see the advantage of being able to tell the difference but I > think it's not big enough to change it now. Not even in php5? Regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: Dangling comma in function call parameters
At 11:32 PM 10/22/2003 +0200, Christian Schneider wrote: Hello everybody, just joined the internals list (after being absent from php developers lists for a while) so excuse my ignorance if any topic I bring up has been discussed already. I checked the archives but couldn't find anything... Proposal: Allow dangling commas in function call parameters. Reasoning: We use some handy vararg tool functions and it's nice to be able to write foo( 1, 2, 3, ); since it's then easy to add a new parameter without having to add a comma to the previous list. This would be symmetrical to the array() syntax. The patch for zend (php4 from cvs) would be minimal and I can't see any backwards-compatibility issues right now (patch attached). Any opinions? The only reason array() supports this is because there are some cases where people auto-generate initialization files which have a huge array() construct and it makes it slightly easier (don't have the last element problem). In this case I don't see the same advantage and I see a disadvantage in readability and the possibility for PHP to give such an empty argument a meaning in future (although I doubt that'll happen). So -1 from me. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] database driver: no more rows
At 12:00 AM 10/23/2003 +0200, Lukas Smith wrote: > From: Andi Gutmans [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 22, 2003 11:58 PM > At 11:49 PM 10/22/2003 +0200, Ard Biesheuvel wrote: > >>Err .. I don't agree. > >>Null means no data > >>False means error. > > > >Maybe historically (PHP-wise) it does. > >But the way I see it, every fetch() can 'fail' for two reasons: an > >expected well-defined reason (eof), and an unexpected undefined reason > >(error). Labelling the well-defined reason as 'false' and the undefined > >reason as 'null' is really quite defendable. > > > This isn't something I'd like to see changed. I actually think there are > probably lots of people who do !== false and we could screw up a lot of > scripts. I see the advantage of being able to tell the difference but I > think it's not big enough to change it now. Not even in php5? Nope. It should be as easy as possible for people to migrate from PHP 4 to PHP 5, and this change isn't one of those blow up in your face things. It'll probably add all sorts of subtle bugs which are hard to find to existing applications. Anyway, I am hoping for no more major changes after I get beta 2 out of the door next week except for bug fixes and adapting extensions to ZE2. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] database driver: no more rows
In a message dated 10/22/2003 6:00:11 PM Eastern Daylight Time, [EMAIL PROTECTED] writes: At 11:49 PM 10/22/2003 +0200, Ard Biesheuvel wrote: >>Err .. I don't agree. >>Null means no data >>False means error. > >Maybe historically (PHP-wise) it does. >But the way I see it, every fetch() can 'fail' for two reasons: an >expected well-defined reason (eof), and an unexpected undefined reason >(error). Labelling the well-defined reason as 'false' and the undefined >reason as 'null' is really quite defendable. This isn't something I'd like to see changed. I actually think there are probably lots of people who do !== false and we could screw up a lot of scripts. I see the advantage of being able to tell the difference but I think it's not big enough to change it now. Andi Well, this would be my first time contributing to any discussion on this list since I joined, but I have a question. It was suggested that this be implemented in PHP 5.0.0. Isn't PHP 5 so much different than PHP 4 that scripts would have to be somewhat rewritten for it anyway? (I'm not saying that PHP 5 is totally different, just different enough.) I don't think I've had any experince with those functions returning FALSE for me, but I think it's more logical that they differentiate between the FALSE and the NULL for the reasons stated above. Gordon Hemsley
Re: [PHP-DEV] database driver: no more rows
At 06:04 PM 10/22/2003 -0400, [EMAIL PROTECTED] wrote: Well, this would be my first time contributing to any discussion on this list since I joined, but I have a question. It was suggested that this be implemented in PHP 5.0.0. Isn't PHP 5 so much different than PHP 4 that scripts would have to be somewhat rewritten for it anyway? (I'm not saying that PHP 5 is totally different, just different enough.) For PHP applications which are mostly functional there will be very little which will need to be fixed (if at all). Many OOP applications will also work and only some will need fixing. There will hopefully be a relative small amount of BC problems, and where BC was broken it was usually only when it was crucial. I don't think I've had any experince with those functions returning FALSE for me, but I think it's more logical that they differentiate between the FALSE and the NULL for the reasons stated above. How is this dealt with today? Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] database driver: no more rows
> From: Andi Gutmans [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 23, 2003 12:06 AM > >I don't think I've had any experince with those functions returning FALSE > >for me, but I think it's more logical that they differentiate between the > >FALSE and the NULL for the reasons stated above. > > How is this dealt with today? Well when you get a return value of false you check if there is an error. But in some ext there is no way in easily determining if an error was created by the fetch call or by some other function call to the ext. run query that works run query that doesn't now when you fetch the rows of the first query you will usually determine if you hit the end if the result set by checking if you don't get an array returned if you don't get an array you check for an error and in several ext you will get the error created by the second query. This is also caused by the fact that the error checking simply returns the last error which cant be cleared appearently. this effectively means that for example in the mysql, mssql, sybase (maybe some other drivers) in PEAR DB we had to remove error checking in the fetch method. But I guess you are right .. this is just a minor limitation and if you are reluctant to accept a BC break to clean up minor limitations then its not something that will ever get fixed (it could of course be fixed in new extensions). Regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 4.3.4 compile on BIND9 systems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On October 20, 2003 09:06 am, Marko Karppinen wrote: > 1. I'll add BIND_8_COMPAT to the darwin-specific part of > configure.in, so its nature as a darwin hack is clear to everyone. > > 2. In exchange for introducing this APPLE-SPECIFIC SHIT, > I'll remove some non-needed Darwin crud from ext/standard/dns.c. Sounds great where is the patch? :) We are already starting to get bug reports on this issue and I think it would be imperative that 4.3.4 due shortly will have this fix. Otherwise user may need to wait until PHP 5.0 for this fix. Ilia -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/lw3YLKekh381/CERAqxgAJ0b21UQWfqJSXZTEDzV36ZKHNCYFQCeLv81 NHAaeSkKRbqCmcozJCl21us= =mb2T -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] overload extension
The methods of an object that has been passed to the overload()
function lose their ability to have parameters passed by reference. For
example:
class Foo
{
function hello(&$array)
{
$array[] = "hello";
}
}
$array = null;
$foo = & new foo();
$foo->hello($array);
print_r($array)
Output:
Array
(
[0] => hello
)
class Foo extends PEAR_Autoloader
{
function hello(&$array)
{
$array[] = "hello";
}
}
$array = null;
$foo = & new foo();
$foo->hello($array);
print_r($array)
Output:
Nothing!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: ZendEngine2 / zend_default_classes.c zend_interfaces.c zend_interfaces.h php-src/tests/classes iterators_001.phpt iterators_002.phpt iterators_003.phpt iterators_004.phpt iterators_005.phpt
/home/sarag/cvs/php5/Zend/zend_default_classes.c:508: undefined reference to `zend_register_interfaces' Looks like zend_interfaces.o isn't being bulit/linked. Does this belong in an autoconf file somewhere? "Marcus Boerger" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > helly Wed Oct 22 16:04:48 2003 EDT > > Added files: > /php-src/tests/classes iterators_001.phpt iterators_002.phpt > iterators_003.phpt iterators_004.phpt > iterators_005.phpt > /ZendEngine2 zend_interfaces.c zend_interfaces.h > > Modified files: > /ZendEngine2 zend_default_classes.c > Log: > Impement userspace iterator interfaces and tests. See tests for details > on the names. > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] overload extension
Hi,
> The methods of an object that has been passed to the overload()
> function lose their ability to have parameters passed by
> reference. For
> example:
>
> class Foo
> {
> function hello(&$array)
> {
> $array[] = "hello";
> }
> }
>
> $array = null;
> $foo = & new foo();
> $foo->hello($array);
> print_r($array)
>
> Output:
> Array
> (
> [0] => hello
> )
>
> class Foo extends PEAR_Autoloader
> {
> function hello(&$array)
> {
> $array[] = "hello";
> }
> }
>
> $array = null;
> $foo = & new foo();
> $foo->hello($array);
> print_r($array)
>
> Output:
>
> Nothing!
I'm not into this topic, but I suppose you should send a bug
report about it (visit http://bugs.php.net and enter info there).
This should then enable the php internal people to refer to that
bug when fixing the problem and committing the changes needed.
Regards
Dennis
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: ZendEngine2 / zend_default_classes.c zend_interfaces.c zend_interfaces.h php-src/tests/classes iterators_001.phpt iterators_002.phpt iterators_003.phpt iterators_004.phpt iterators_005.phpt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Already fixed. Ilia On October 22, 2003 07:38 pm, Sara Golemon wrote: > /home/sarag/cvs/php5/Zend/zend_default_classes.c:508: undefined reference > to `zend_register_interfaces' > > Looks like zend_interfaces.o isn't being bulit/linked. Does this belong in > an autoconf file somewhere? > > "Marcus Boerger" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > > helly Wed Oct 22 16:04:48 2003 EDT > > > > Added files: > > /php-src/tests/classes iterators_001.phpt iterators_002.phpt > > iterators_003.phpt iterators_004.phpt > > iterators_005.phpt > > /ZendEngine2 zend_interfaces.c zend_interfaces.h > > > > Modified files: > > /ZendEngine2 zend_default_classes.c > > Log: > > Impement userspace iterator interfaces and tests. See tests for details > > on the names. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/lxflLKekh381/CERAivCAJ9Pb8cRE1zqnsKQcjAay0FIrTStggCeOBz+ q97bbIRX/gWmE+f4HWXhAtw= =ITWn -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: ZendEngine2 / zend_default_classes.c zend_interfaces.c zend_interfaces.h php-src/tests/classes iterators_001.phpt iterators_002.phpt iterators_003.phpt iterators_004.phpt iterators_005.phpt
Not to be pedantic about it, but where? My checkout is still broken (despite a total scrubdown and rebuild), and (while I'm not a makefile expert) I should think that /ZendEngine2/Makefile.am would have had to be updated more recently than 3 months ago -Sara http://cvs.php.net/co.php/ZendEngine2/Makefile.am > Already fixed. > > Ilia > > On October 22, 2003 07:38 pm, Sara Golemon wrote: > > /home/sarag/cvs/php5/Zend/zend_default_classes.c:508: undefined reference > > to `zend_register_interfaces' > > > > Looks like zend_interfaces.o isn't being bulit/linked. Does this belong in > > an autoconf file somewhere? > > > > "Marcus Boerger" <[EMAIL PROTECTED]> wrote in message > > news:[EMAIL PROTECTED] > > > > > helly Wed Oct 22 16:04:48 2003 EDT > > > > > > Added files: > > > /php-src/tests/classes iterators_001.phpt iterators_002.phpt > > > iterators_003.phpt iterators_004.phpt > > > iterators_005.phpt > > > /ZendEngine2 zend_interfaces.c zend_interfaces.h > > > > > > Modified files: > > > /ZendEngine2 zend_default_classes.c > > > Log: > > > Impement userspace iterator interfaces and tests. See tests for details > > > on the names. > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.0.7 (GNU/Linux) > > iD8DBQE/lxflLKekh381/CERAivCAJ9Pb8cRE1zqnsKQcjAay0FIrTStggCeOBz+ > q97bbIRX/gWmE+f4HWXhAtw= > =ITWn > -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: ZendEngine2 / zend_default_classes.c zend_interfaces.c zend_interfaces.h php-src/tests/classes iterators_001.phpt iterators_002.phpt iterators_003.phpt iterators_004.phpt iterators_005.phpt
The fix is inside php-src/configure.in, the zend_interfaces.c was not being compiled. Ilia On October 22, 2003 08:31 pm, Sara Golemon wrote: > Not to be pedantic about it, but where? > > My checkout is still broken (despite a total scrubdown and rebuild), and > (while I'm not a makefile expert) I should think that > /ZendEngine2/Makefile.am would have had to be updated more recently than 3 > months ago > > -Sara > > http://cvs.php.net/co.php/ZendEngine2/Makefile.am > > > Already fixed. > > > > Ilia > > > > On October 22, 2003 07:38 pm, Sara Golemon wrote: > > > /home/sarag/cvs/php5/Zend/zend_default_classes.c:508: undefined > > reference > > > > to `zend_register_interfaces' > > > > > > Looks like zend_interfaces.o isn't being bulit/linked. Does this > > > belong > > in > > > > an autoconf file somewhere? > > > > > > "Marcus Boerger" <[EMAIL PROTECTED]> wrote in message > > > news:[EMAIL PROTECTED] > > > > > > > helly Wed Oct 22 16:04:48 2003 EDT > > > > > > > > Added files: > > > > /php-src/tests/classes iterators_001.phpt iterators_002.phpt > > > > iterators_003.phpt iterators_004.phpt > > > > iterators_005.phpt > > > > /ZendEngine2 zend_interfaces.c zend_interfaces.h > > > > > > > > Modified files: > > > > /ZendEngine2 zend_default_classes.c > > > > Log: > > > > Impement userspace iterator interfaces and tests. See tests for > > details > > > > > on the names. > > > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1.0.7 (GNU/Linux) > > > > iD8DBQE/lxflLKekh381/CERAivCAJ9Pb8cRE1zqnsKQcjAay0FIrTStggCeOBz+ > > q97bbIRX/gWmE+f4HWXhAtw= > > =ITWn > > -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] overload extension
There is already a bug report on it, however It sounds like it's
unlikely to be fixed in PHP4...
Regards
Alan
[EMAIL PROTECTED] wrote:
The methods of an object that has been passed to the overload() function
lose their ability to have parameters passed by reference. For example:
class Foo
{
function hello(&$array)
{
$array[] = "hello";
}
}
$array = null;
$foo = & new foo();
$foo->hello($array);
print_r($array)
Output:
Array
(
[0] => hello
)
class Foo extends PEAR_Autoloader
{
function hello(&$array)
{
$array[] = "hello";
}
}
$array = null;
$foo = & new foo();
$foo->hello($array);
print_r($array)
Output:
Nothing!
--
Can you help out?
Need Consulting Services or Know of a Job?
http://www.akbkhome.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] overload extension
This may be where the problem:
zend_get_parameters_array_ex(ZEND_NUM_ARGS(), args);
Would this do the trick?
zend_get_parameters_array(ZEND_NUM_ARGS(), args);
On Wednesday, Oct 22, 2003, at 20:47 America/New_York, Alan Knowles
wrote:
There is already a bug report on it, however It sounds like it's
unlikely to be fixed in PHP4...
Regards
Alan
[EMAIL PROTECTED] wrote:
The methods of an object that has been passed to the overload()
function lose their ability to have parameters passed by reference.
For example:
class Foo
{
function hello(&$array)
{
$array[] = "hello";
}
}
$array = null;
$foo = & new foo();
$foo->hello($array);
print_r($array)
Output:
Array
(
[0] => hello
)
class Foo extends PEAR_Autoloader
{
function hello(&$array)
{
$array[] = "hello";
}
}
$array = null;
$foo = & new foo();
$foo->hello($array);
print_r($array)
Output:
Nothing!
--
Can you help out?
Need Consulting Services or Know of a Job?
http://www.akbkhome.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: msiddiqui77
web Development with php scripting because i know about the ASP,HTML javascript but i toward on the php scripting.so please guide me proper to how can i used php. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
