Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV]Release process
On Thu, 3 May 2001, Andi Gutmans wrote:
At 08:53 AM 5/3/2001 -0500, Andrei Zmievski wrote:
Um, but some db extensions return NULL values as part of the array, so
if column 'foo' is NULL in the db, you'd want the result array to have
NULL under key 'foo' - it just won't do to have that column be missing.
Yeah but you can use === NULL for those.
You might be right but I remember we decided it's problematic.
With all due respect Andi, you can't. There is a difference between a
field being null and that field not existing at all that neither isset,
empty nor === will detect.
david@papaya:~$ php
?
$arr['field'] = null;
$r1 = ($arr['field'] === null);
$r2 = ($arr['blah'] === null);
var_dump($r1);
var_dump($r2);
$r1 = (isset($arr['field']));
$r2 = (isset($arr['blah']));
var_dump($r1);
var_dump($r2);
$r1 = (empty($arr['field']));
$r2 = (empty($arr['blah']));
var_dump($r1);
var_dump($r2);
$r1 = (key_exists('field', $arr));
$r2 = (key_exists('blah', $arr));
var_dump($r1);
var_dump($r2);
?
Out of the four, only key_exists makes the distinction.
I know you had mentioned a problem with Zend not being able to unset
certain fields and instead setting them to null. May I suggest instead
that be attended to - if nothing else, by adding a new 'does not exist'
marker to the bucket that the zend_hash_ functions will recognize.
In the meantime a very large note can be added to the documentation if you
are able to determine exactly what circumstances cause this behaviour.
Cheers,
David
--
| /+\ \| | |
David Croft
Infotrek
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV]Release process
In my humble opinion 'null' is a 'pseudovalue' that has been made available for some time. If it was never intended for a script to be able to use it, it should never have been exposed. But it has been and many people, myself included, are using it. It is particularly useful to mark a value that has not yet been filled. The same way NULL is used in SQL. If you take out this behaviour there is no 'pseudo-value' to indicate the absence of value and we will go back to using 0 or constants, a hack at best. Also, I see a distinction semantically between isset and key_exists. Isset asks whether it is set to a tangible value. Key_exists asks whether the array contains an entry, any entry, for that key. My 2 cents, David -- | /+\ \| | | David Croft Infotrek On Thu, 3 May 2001, Zeev Suraski wrote: At 17:20 3/5/2001, Cynic wrote: I very much agree with Andrei on this. Please, keep the existing functionality. Although, I'm not familiar with any issues possibly connected with this. Does it hurt anything? Yes, it requires adding of functions that duplicate isset()'s behavior in a way that may change in the future (implementation dependent). Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] MySQL problems at bugs.php.net
Also unable to fork errors on the search page, and it's been VERY slow recently. -- | /+\ \| | | David Croft Infotrek On Sun, 29 Apr 2001, Zak Greant wrote: Hello All, I just noted a problem at bugs.php.net: bWarning/b: MySQL Connection Failed: Can't create a new thread (errno 11). If you are not out of available memory, you can consult the manual for a possible OS-dependent bug in b/local/Web/sites/phpweb/bugs.php/b on line b77/bbr Unable to connect to SQL server. Ciao, --zak -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] key_exists from php
There doesn't seem to be any way for a php script to determine whether a given key exists in an array. isset($arr['x']) fails when it exists but has a null value. I know there are ways around it like using foreach or array_keys but these don't seem very efficient. I would like to add a function key_exists, with the following proto: bool key_exists(array search, string key) Please let me know if this is inappropriate or I have missed something obvious, otherwise I shall add this tomorrow. Thanks, David. -- | /+\ \| | | David Croft Infotrek -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] key_exists from php
On Sun, 29 Apr 2001, Andrei Zmievski wrote: Key may be a number as well. -Andrei should that be separate e.g. index_exists? -- | /+\ \| | | David Croft Infotrek -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] function table
Hello, I'm implementing an extension that allows user callbacks. The Zend API document suggests using the Compiler globals to access the function table. However I see the XML extension is using Executor globals. Which is correct? is there a difference? If I were to take a wild guess I'd say the CG only had global functions and EG has functions currently in scope - is that right? Thanks, David -- | /+\ \| | | David Croft Infotrek -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] function table / hashes
Thank you Andi and Andrei.
I have noticed that object method callbacks are consistently faster than
global function callbacks, and was wondering why:
1.3135770559311 seconds for 10 runs - with no function callback
6.9758139848709 seconds for 10 runs - with object method callback
7.9048730134964 seconds for 10 runs - with global function callback
This is somewhat strange for me as I would expect objects to be slower if
it has to look up the class and then locate the function table?
I'm exploring hashes now. I find code like this in php_imap.c:
if (zend_hash_find(Z_ARRVAL_PP(envelope), remail,
sizeof(remail), (void **) pvalue)== SUCCESS) {
convert_to_string_ex(pvalue);
env-remail=cpystr(Z_STRVAL_PP(pvalue));
}
Is that legal? It seems that it would alter the original array by forcing
conversion to string.
Lastly, I am trying to see the difference between zend_hash_find and
zend_hash_quick_find. Would I be correct in assuming quick_find only looks
at string keys, and it would be safe to use this if the function expects
only associative arrays?
Thanks again!
David
--
| /+\ \| | |
David Croft
Infotrek
On Thu, 26 Apr 2001, Andi Gutmans wrote:
At 02:16 PM 4/26/2001 -0400, David Croft wrote:
Hello, I'm implementing an extension that allows user callbacks.
The Zend API document suggests using the Compiler globals to access the
function table. However I see the XML extension is using Executor globals.
During execution the correct table to use is the executor globals one,
i.e., EG(function_table).
Andi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: PHP 4.0 Bug #9307 Updated: Numeric-looking arraykeys are forced to be integers
So what about a string key that breaks when someone enters a string that can be autoconverted. Zend turns it into a number and hey presto nothing works any more. Can we have a construct to *force* it not to convert these things? On Tue, 6 Mar 2001, Stanislav Malyshev wrote: DC Even for array keys that are *not numbers*? How do I get a DC string for my array key in this case? If they are not numbers, they are not interpreted as numbers. So, $a[0] is the same as $a['0'], but different from $a["foo"]. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: PHP 4.0 Bug #9307 Updated: Numeric-looking arraykeys are forced to be integers
function some_generic_function($myarray)
{
foreach ($myarray as $k = $v) {
if (is_string($k)) {
/* some behaviour for associative array element */
}
else {
/* some behaviour for indexed array element */
}
}
}
On Tue, 6 Mar 2001, Stanislav Malyshev wrote:
DC So what about a string key that breaks when someone enters a
DC string that can be autoconverted. Zend turns it into a number
DC and hey presto nothing works any more. Can we have a construct
DC to *force* it not to convert these things?
I don't get what you are talking about. Can you give me an example
(script)?
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Midgard
Midgard extension contains 200k of vanity images. This is unreasonable bloat to the core of PHP. Can you please remove them? David -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] File upload error - no mime boundary found after start of file header
I am working on a site that handles a lot of file uploads. Occasionally the following error will be thrown: shell httpd: PHP Warning: File Upload Error - No Mime boundary found after start of file header in Unknown on line 0 Now I figured this was probably a browser bug rather than a PHP bug but a grep of the last few log entries shows a variety of browsers (see end of this message) The guts of the form is: form enctype="multipart/form-data" action="genie_upload.php" method="post" name="uploadform" input type="file" name="userfile" size="30" input type="submit" value="Upload" onClick="return validateform()" /form Any ideas what could be wrong please? rfc1867.c makes no sense to me. Thanks. David recent browsers: Mozilla/4.73 [en]C-SYMPA (Win95; U) Mozilla/4.06 [en]C-gatewaynet (Win98; I) Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt) Mozilla/4.0 (compatible; MSIE 4.01; Windows 98) Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt; MSN 6.0) Mozilla/4.0 (compatible; MSIE 5.0; AOL 6.0; Windows 98; DigExt) Mozilla/4.0 (compatible; MSIE 5.0; Windows 98)::ELNSB50::4110028001e0027a016c0503002a Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; Win 9x 4.90) Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; Win 9x 4.90) Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt) Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt; AIRF) Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) Mozilla/4.0 (compatible; MSIE 4.01; Windows 98) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] DOM XML errors
DOM XML functions write errors to apache's error_log, not very helpful. Any reason for this? any workarounds? Any reason it shouldn't trigger a PHP error? David -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
