Bart de Boer wrote:
Stefan Walk wrote:
Just a small suggestion - what do you all think of creating an array
implicitely on function calls like db_connect('host' => $host, 'port'
=>$port), or funcname($param1, $param2, 'foo' => 'bar'). Those parts
would have to be on the very end of the argument
Stefan Walk wrote:
Just a small suggestion - what do you all think of creating an array
implicitely on function calls like db_connect('host' => $host, 'port'
=>$port), or funcname($param1, $param2, 'foo' => 'bar'). Those parts
would have to be on the very end of the argument list. Would eliminate
On 15/01/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
> mysqli_connect( array( 'host' => $host, 'port' => $port ) );
> (except that it's a bit more to type).
Just a small suggestion - what do you all think of creating an array
implicitely on function calls like db_connect('host' => $host, 'port'
Derick Rethans wrote:
> You do know that that means that we have to consistently name all
> parameters to our 4000+ functions, right?
On this note, and to throw in my 2c on the issue (from a doc
standpoint): there are places in the manual where I've (personally)
deliberately changed the parameter
Brian Moon wrote:
> PHP will grow to a situation where half the
I agree that if implemented this feature should be all or nothing. If
its only userland, it is confusing to new users. But, I really to find
it upsetting to see so many people saying that this feature will
fracture the PHP com
> PHP will grow to a situation where half the
people are doing A and half the people are doing B. I fear that would be
very much for the worse.
Where were all these arguments when PHP was changed to become Java Jr.?
I agree that if implemented this feature should be all or nothing. If
its on
web designing
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Fri, 13 Jan 2006, Ron Korving wrote:
> I think everybody should be open to a new way of dealing with functions. The
> advantages apply to many many functions. Take for example:
>
> mysqli mysqli_connect ( [string host [, string username [, string passwd [,
> string dbname [, int port [, stri
Ron Korving wrote:
mysqli mysqli_connect ( [string host [, string username [, string passwd [,
string dbname [, int port [, string socket]] )
*cough*PDO*cough* (
http://us3.php.net/manual/en/ref.pdo-mysql.connection.php )
David Hall
--
PHP Internals - PHP Runtime Development Mailin
I was just browsing the PHP source and I noticed something apparently amiss.
The top of do_bind_inherited_class() in Zend/zend_compile.c reads:
found_ce = zend_u_hash_find(class_table, Z_TYPE(opline->op1.u.constant),
Z_UNIVAL(opline->op1.u.constant), Z_UNILEN(opline->op1.u.constant), (void
**)
Antony Dovgal wrote:
> What exactly are you trying to fix?
Confusing, misdocumented code. I'm sorry, am I wasting bandwidth? I felt
duty-bound to report it.
-- Tim Starling
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I guess adding named arguments of internal functions would enable Reflection to
properly reflect on function and method parameters
of internal functions. Which would be nicer than the inconsistent state that
exists now.
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscr
Zeev, I agree with you that if this is implemented throughout the engine, it
would actually not make things better. Some people will be doing
strpos(needle: $needle, haystack: $haystack) and others will be doing
strpos($haystack, $needle) and PHP will grow to a situation where half the
people are d
What exactly are you trying to fix?
On 15.01.2006 16:15, Tim Starling wrote:
I was just browsing the PHP source and I noticed something apparently amiss.
The top of do_bind_inherited_class() in Zend/zend_compile.c reads:
found_ce = zend_u_hash_find(class_table, Z_TYPE(opline->op1.u.constant
At 12:37 15/01/2006, Rasmus Lerdorf wrote:
Zeev Suraski wrote:
At 09:51 15/01/2006, Rasmus Lerdorf wrote:
Aidan Lister wrote:
Are the PHP group prepared to accept and implement a named
parameters patch?
As far as I am concerned it would depend on the patch. If you can
come up with a way to
On Sat, 14 Jan 2006, Rasmus Lerdorf wrote:
> Aidan Lister wrote:
> > Are the PHP group prepared to accept and implement a named parameters patch?
>
> As far as I am concerned it would depend on the patch. If you can come up
> with a way to do it with requiring rewriting all 4000+ functions out t
Zeev Suraski wrote:
At 09:51 15/01/2006, Rasmus Lerdorf wrote:
Aidan Lister wrote:
Are the PHP group prepared to accept and implement a named parameters
patch?
As far as I am concerned it would depend on the patch. If you can
come up with a way to do it with requiring rewriting all 4000+
f
Aidan,
People often mention the 20/80 rule, we're so far away from there
that it's not even funny. It's more like the 1/99 rule, not to
mention 0.0001 / 99. rule. That means that even if we could come
up with a way to improve that tiny fraction of cases, it would be
highly debatable whe
At 09:51 15/01/2006, Rasmus Lerdorf wrote:
Aidan Lister wrote:
Are the PHP group prepared to accept and implement a named parameters patch?
As far as I am concerned it would depend on the patch. If you can
come up with a way to do it with requiring rewriting all 4000+
functions out there, g
19 matches
Mail list logo
