The main flaw in type conversion hinting is that it's nearly pointless.
Why convert the type at function call? PHP will automatically juggle the
type depending on the variable's destination, really no point in
converting it one more time when calling the function
Well that is not entirely
PHP 4 Bug Database summary - http://bugs.php.net
Num Status Summary (624 total including feature requests)
===[*Compile Issues]==
43389 Open configure ignoring --without-cdb flag
PHP 6 Bug Database summary - http://bugs.php.net
Num Status Summary (66 total including feature requests)
===[*General Issues]==
26771 Suspended register_tick_funtions crash under threaded webservers
There's a lot of confusion on php-internals about a proposal for
type hinting, so someone did a writeup on related terminology,
including something called popcorn WTF.
Wietse
- Forwarded message from Martin Alterisio -
Message-ID: [EMAIL PROTECTED]
Date: Sun, 6 Jan 2008 23:58:54
Sorry for the noise. That was meant to be forwarded off-list.
Wietse
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sam Barrow schrieb:
Well these errors can be handled like any other, as long as they don't
issue a fatal.
That's exactly my point. You need to handle them. So in pidgin PHP that
could look something like
function foo(int $foo) {}
try
{
foo($bar);
}
catch (WhateverException $e)
{
since
Dear all,
I'm trying to apply the php ldap EXOP patch from :
http://www.sys-net.it/~ando/Download/#PHP
The patch defines a zstr in ldap.c at line 1731 as obvious below. ZSTR
no longer appears to be defined anywhere in php or zend.h - can
somebody help me with this? Should i just define it
Hi Faraz,
On Mon, 2008-01-07 at 20:53 +0500, Faraz Khan wrote:
Dear all,
I'm trying to apply the php ldap EXOP patch from :
http://www.sys-net.it/~ando/Download/#PHP
The patch defines a zstr in ldap.c at line 1731 as obvious below. ZSTR
no longer appears to be defined anywhere in php
On Mon, 2008-01-07 at 15:19 +0100, Stefan Priebsch wrote:
Sam Barrow schrieb:
Well these errors can be handled like any other, as long as they don't
issue a fatal.
That's exactly my point. You need to handle them. So in pidgin PHP that
could look something like
function foo(int $foo)
On Jan 6, 2008 5:06 AM, Stefan Esser [EMAIL PROTECTED] wrote:
Hello Daniel,
It may be off-topic for the initial post, but I disagree
wholeheartedly with the above statement, Stefan. There are
innumerable reasons where $_REQUEST would be much more economic than
writing out all
Afternoon,
Wow, go away for a weekend and look what happens...
Personally I think the issue is that true scalar type hinting doesn't
make much sense with a dynamically typed language. Deciding if/when/how
to juggle a scalar typehint is going to make at least one person angry
and some new
Sam Barrow schrieb:
Keep in mind that your do_whatever would actually be a trigger error
with an error message including the name of the function and parameter
number.
I did not make the point of my code clear enough. do_whatever is not the
code that triggers the error, but the code that
On Mon, 2008-01-07 at 13:16 -0500, Elizabeth M Smith wrote:
Afternoon,
Wow, go away for a weekend and look what happens...
Personally I think the issue is that true scalar type hinting doesn't
make much sense with a dynamically typed language. Deciding if/when/how
to juggle a scalar
On Mon, 2008-01-07 at 19:21 +0100, Stefan Priebsch wrote:
Sam Barrow schrieb:
Keep in mind that your do_whatever would actually be a trigger error
with an error message including the name of the function and parameter
number.
I did not make the point of my code clear enough. do_whatever
On Mon, 2008-01-07 at 19:21 +0100, Stefan Priebsch wrote:
Sam Barrow schrieb:
Keep in mind that your do_whatever would actually be a trigger error
with an error message including the name of the function and parameter
number.
I did not make the point of my code clear enough. do_whatever
On Mon, 2008-01-07 at 13:33 -0500, Robert Cummings wrote:
On Mon, 2008-01-07 at 19:21 +0100, Stefan Priebsch wrote:
Sam Barrow schrieb:
Keep in mind that your do_whatever would actually be a trigger error
with an error message including the name of the function and parameter
number.
On Jan 7, 2008 1:34 PM, Sam Barrow [EMAIL PROTECTED] wrote:
On Mon, 2008-01-07 at 13:33 -0500, Robert Cummings wrote:
On Mon, 2008-01-07 at 19:21 +0100, Stefan Priebsch wrote:
Sam Barrow schrieb:
Keep in mind that your do_whatever would actually be a trigger error
with an error
Robert Cummings schrieb:
The onus should be on consumers of my API to use it properly, not on me
to jump through hoops to make sure they gave me the correct data at
every step of the way. I stopped holding hands in grade 3 or so.
Still you force any defensive coder to repeat explicit type
On Mon, 2008-01-07 at 19:45 +0100, Stefan Priebsch wrote:
Robert Cummings schrieb:
The onus should be on consumers of my API to use it properly, not on me
to jump through hoops to make sure they gave me the correct data at
every step of the way. I stopped holding hands in grade 3 or so.
More specifically I was thinking of starting with adding an SPL interface
called ArraySearchable,
and modifying php_search_array in ext/standard/array.c to accept an object that
implements that
interface, in which case the appropriate interface method is called.
What this interface would do?
I would like to propose we set this default value to something more
appropriate for a web app. It is currently 60 seconds. That is a
really long time for a web page to wait to find a mysql server, IMO.
And in the spirit of PHP being web first, I think it should be shorter.
The place where
21 matches
Mail list logo
