Just to throw in my two cents since every one else has (not that my 2
cents is worth anything more than just that), but isn't it as easy as
doing something like the following:
(using pseudo example from above)
function db_connect($params) {
$host = 'localhost';
$user = 'root';
On 1/15/06, Zeev Suraski [EMAIL PROTECTED] wrote:
In those rare occurrences where named parameters have true benefits,
please live with the drawbacks of using array().
I do, though code completion, type hinting, etc. would be nice. It
would nice if it was consistenly added so that built-in
Just to throw in my two cents since every one else has (not that my 2
cents is worth anything more than just that), but isn't it as easy as
doing something like the following:
(using pseudo example from above)
function db_connect($params) {
$host = 'localhost';
$user = 'root';
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
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+
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 there,
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
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
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
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
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 [, string
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
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
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'
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
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
Hartmut Holzgraefe wrote:
Jared White wrote:
While ideally it'd be nice to have named parameters used in the core
of PHP, I realize that's probably an impossible task at the moment. So
I agree that the main goal is to allow users to define APIs in PHP
using this feature. If that's all we had,
Ron Korving wrote:
Another nice use case is querybuilders:
$query = buildQuery(select: $columns, from: $tables, leftjoin: $leftjoins,
limit: 10);
We've seen a large number of cases where named parameters would be
extremely useful. To each case, there has been a half baked attempt to
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, go for it.
-Rasmus
--
PHP Internals - PHP
Andi Gutmans wrote:
In my opinion, as Ilia stated passing an associative array does the job
quite well for the use-case where named arguments would be useful.
Sure it might be a tad-bit sexier that you don't have to write array()
but the truth is that the implementation would probably still use
On Fri, 13 Jan 2006, Lukas Smith wrote:
Now obviously there would have to be someone to implement it, but I see no
design reason to not allow this feature in.
But I see no reason to add it either...
regards,
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
Let me summarize it for you then.
Advantages of named parameters over associative arrays:
- cleaner syntax
- support for type hints
- difference between required and optional parameters
- generating documentation (whether with something like phpDoc or an IDE)
- ...
Can anyone summarize the
Ron Korving wrote:
Let me summarize it for you then.
Advantages of named parameters over associative arrays:
- cleaner syntax
- support for type hints
- difference between required and optional parameters
- generating documentation (whether with something like phpDoc or an IDE)
- ...
Can
That's a good point. But for PHP6, wouldn't everything have to be revised
anyway? Another option is to make named parameter support optional per
function. If a user calls a function with named parameters which the
function doesn't support, the engine can trigger an error. This way internal
On 13.01.2006 14:25, Ron Korving wrote:
That's a good point. But for PHP6, wouldn't everything have to be revised
anyway? Another option is to make named parameter support optional per
function. If a user calls a function with named parameters which the
function doesn't support, the engine can
Hartmut Holzgraefe wrote:
- all internal and PECL functions need to be recoded as the API
right now doesn't know any concept of parameter names at all
I was thinking that this would a userland only feature.
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To
Lukas Smith wrote:
- all internal and PECL functions need to be recoded as the API
right now doesn't know any concept of parameter names at all
I was thinking that this would a userland only feature.
do we really want to add even more inconsistencies to the language?
--
Hartmut
Hartmut Holzgraefe wrote:
Lukas Smith wrote:
- all internal and PECL functions need to be recoded as the API
right now doesn't know any concept of parameter names at all
I was thinking that this would a userland only feature.
do we really want to add even more inconsistencies to the
Lukas Smith wrote:
Its sole purpose is to deal with situations where you have a
considerable number of parameters.
well, i for one would love to write something like
$pos = strpos(haystack=$str, needle=foobar);
instead of looking up parameter orders all the time :)
--
Hartmut Holzgraefe,
Hartmut Holzgraefe wrote:
Lukas Smith wrote:
Its sole purpose is to deal with situations where you have a
considerable number of parameters.
well, i for one would love to write something like
$pos = strpos(haystack=$str, needle=foobar);
instead of looking up parameter orders all the time
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 [, string socket]] )
It would be nice to be able to
While ideally it'd be nice to have named parameters used in the core
of PHP, I realize that's probably an impossible task at the moment.
So I agree that the main goal is to allow users to define APIs in PHP
using this feature. If that's all we had, it'd be good enough I
think. (At least,
Guys,
It's not going to happen. Please move on. We've discussed it lots of
times in the past. Many times we've come to the conclusion that for a
few cases it's not worth it.
If you have functions with lots of parameters (probably 3-4 in a
whole application) then just use array()'s. It's
At 12:08 AM 1/13/2006, Lukas Smith wrote:
Andi Gutmans wrote:
In my opinion, as Ilia stated passing an associative array does the
job quite well for the use-case where named arguments would be useful.
Sure it might be a tad-bit sexier that you don't have to write
array() but the truth is that
Hartmut Holzgraefe wrote:
Ron Korving wrote:
Let me summarize it for you then.
Advantages of named parameters over associative arrays:
- cleaner syntax
- support for type hints
- difference between required and optional parameters
- generating documentation (whether with something like
Brad Fisher wrote:
Thus no need to rework internal parameter passing API at all. Perhaps
I'm missing something?
you missed that the parameter name information is just not available
for internal functions, the api works by parameter positions only
right now, so at some level you *have to* add
Jared White wrote:
While ideally it'd be nice to have named parameters used in the core of
PHP, I realize that's probably an impossible task at the moment. So I
agree that the main goal is to allow users to define APIs in PHP using
this feature. If that's all we had, it'd be good enough I
Hartmut Holzgraefe wrote:
Brad Fisher wrote:
Thus no need to rework internal parameter passing API at all.
Perhaps I'm missing something?
you missed that the parameter name information is just not available
for internal functions, the api works by parameter positions only
right now, so at
Hi,
On Friday 13 January 2006 21:41, Hartmut Holzgraefe wrote:
you missed that the parameter name information is just not available
for internal functions, the api works by parameter positions only
right now, so at some level you *have to* add this information for
all the 4,000+ extension
This isn't a waste of bandwidth. This is about the future of the language
and about the fact that PHP is missing a crucial feature that several
other languages have had for years and others are working on -- PHP's
competition, in other words.
Please explain to me how using an array is a solution.
Each programming scripting language has its strengths and areas of
focus. Just because another language implements a feature, does not mean
the rest should follow suit. What you fail to realize that every feature
adds to the language complexity, making it more difficult to use, harder
to debug
Ilia Alshanetsky wrote:
Each programming scripting language has its strengths and areas of
focus. Just because another language implements a feature, does not mean
the rest should follow suit. What you fail to realize that every feature
adds to the language complexity, making it more difficult
Lukas Smith wrote:
compared to the many features recently added. But then again it seems
that the bulk of people who have the power to actively stear PHP
disagree. So I see little reason to continue this discussion.
Nice try, but you forgot Quirk's exception ;-)
- Chris
--
PHP Internals -
Ilia Alshanetsky wrote:
Each programming scripting language has its strengths and areas of
focus. Just because another language implements a feature, does not mean
the rest should follow suit. What you fail to realize that every feature
adds to the language complexity, making it more difficult
On Thu, 2006-01-12 at 01:25, Jason Garber wrote:
Hello Aidan,
I think named parameters would be a useful feature... I'll leave it
at that.
Here is a coding idea for you, in case you hadn't considered it...
function highlight($text=NULL, $needle=NULL, $strip_links=NULL, ...)
On 1/12/06, Robert Cummings [EMAIL PROTECTED] wrote:
On Thu, 2006-01-12 at 01:25, Jason Garber wrote:
Hello Aidan,
I think named parameters would be a useful feature... I'll leave it
at that.
Here is a coding idea for you, in case you hadn't considered it...
function
Jason Garber wrote:
Here is a coding idea for you, in case you hadn't considered it...
function highlight($text=NULL, $needle=NULL, $strip_links=NULL, ...)
{
is_null($text) $text = SOME DEFAULT VALUE;
is_null($needle) $text = SOME DEFAULT VALUE;
is_null($strip_links)
Andrei Zmievski wrote:
On Jan 9, 2006, at 4:09 AM, Aidan Lister wrote:
As useful functions tend to increase in complexity over
time, often
so does the number of parameters.
It soon gets to the point where function calls look like:
foo(true, false, false, false, false, true)
Aidan Lister wrote:
As useful functions tend to increase in complexity over time, often so
does the number of parameters.
It soon gets to the point where function calls look like:
foo(true, false, false, false, false, true)
The rest of the parameters being required to be supplied, with
If you have too many parameters that you want to start omitting
parameters when calling a function, its probably time to refactor.
And if you have many parameters to functions you still need to look at the
definition (or documentation) to figure out what parameters the function
takes. It's
On Thu, 2006-01-12 at 03:58, Michael Walter wrote:
To quote Jason, In [the] way, [that] the user doesn't have to
remember the default values,
just the offsets..
*slaps self* Duh :)
Cheers,
Rob.
--
..
| InterJinn Application
I think that's a poor example. I see a highlighting problem split into multiple classes.
The rule in my projects and at work is don't make a new function/method
unless it is going to be reused. So, making multiple functions just so
you don't have to pass a lot of stuff to one function is
Frank M. Kromann wrote:
And if you have many parameters to functions you still need to look at the
definition (or documentation) to figure out what parameters the function
takes. It's not a big problem to look at the order at the same time.
lets face the opposite direction for a second:
all
Hartmut, there are only 2 or 3 of those functions where the order
differs.
-Andrei
On Jan 12, 2006, at 8:49 AM, Hartmut Holzgraefe wrote:
Frank M. Kromann wrote:
And if you have many parameters to functions you still need to
look at the
definition (or documentation) to figure out what
Andrei Zmievski wrote:
Hartmut, there are only 2 or 3 of those functions where the order differs.
but it's the fact that it differs at all that counts ...
--
Hartmut Holzgraefe, Senior Support Engineer.
MySQL AB, www.mysql.com
--
PHP Internals - PHP Runtime
Another nice use case is querybuilders:
$query = buildQuery(select: $columns, from: $tables, leftjoin: $leftjoins,
limit: 10);
It's nice to be able to stick to what matters, and omit everything that
doesn't matter (ordinary joins, where, group by, having).
With func_get_args() returning an
On Jan 12, 2006, at 7:22 AM, Ilia Alshanetsky wrote:
Aidan Lister wrote:
As useful functions tend to increase in complexity over time,
often so
does the number of parameters.
It soon gets to the point where function calls look like:
foo(true, false, false, false, false, true)
The rest of
Hello Jared,
JW PHP is all about using a simple means to an end and getting the job
JW done. Named parameters makes coding easier, not harder.
Well stated.
--
Best regards,
Jasonmailto:[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To
In my opinion, as Ilia stated passing an associative array does the
job quite well for the use-case where named arguments would be useful.
Sure it might be a tad-bit sexier that you don't have to write
array() but the truth is that the implementation would probably still
use an array. Unlike
Hello Andi,
I think the sexy syntax is a significant plus, even if associative
arrays were used in the implementation. Is it a complex thing to
implement?
--
Best regards,
Jasonmailto:[EMAIL PROTECTED]
Thursday, January 12, 2006, 6:44:59 PM, you wrote:
AG
On Jan 9, 2006, at 4:09 AM, Aidan Lister wrote:
As useful functions tend to increase in complexity over time, often so
does the number of parameters.
It soon gets to the point where function calls look like:
foo(true, false, false, false, false, true)
The rest of the parameters being required
Andrei Zmievski wrote:
On Jan 9, 2006, at 4:09 AM, Aidan Lister wrote:
As useful functions tend to increase in complexity over time, often so
does the number of parameters.
It soon gets to the point where function calls look like:
foo(true, false, false, false, false, true)
The rest of the
Hello Aidan,
I think named parameters would be a useful feature... I'll leave it
at that.
Here is a coding idea for you, in case you hadn't considered it...
function highlight($text=NULL, $needle=NULL, $strip_links=NULL, ...)
{
is_null($text) $text = SOME DEFAULT VALUE;
Andrei Zmievski wrote:
If you get to the point where your function has a dozen parameters, I
would suggest re-thinking the purpose and design of such a function,
because you are likely trying to make it do too much.
Obviously for most methods you should not require more than say 5
64 matches
Mail list logo
