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';
$passw
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';
$passwo
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 f
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
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 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
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
passed to the function.
From: Aidan Lister <[EMAIL PROTECTED]>
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: Named arguments revisited
Date: Sun, 15 Jan 2006 18:17:28 +1100
Ron Korving wrote:
Another nice use case is querybuilders:
$query = buildQuery(select: $columns, from: $
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
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
dismiss
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,
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 - PH
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
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 an
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.
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
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
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 think
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 t
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 phpDoc
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 t
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 actual
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, it
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 d
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
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:
- 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 langua
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 Holzgraefe,
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 unsubscri
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
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
func
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 anyone
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 disadv
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, v
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
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>
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 Ada
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
T
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 the
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 assoc
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 Develop
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 par
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 th
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 sill
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 F
>
> 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'
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
> 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, fa
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) &
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...
> >
>
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, .
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
parameters
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;
i
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 pa
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
67 matches
Mail list logo
