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
Hello!
The PHP Development Team would like to announce the immediate release of
PHP 4.4.2. This is a maintenance release that addresses a number of
minor security problems and fixes a few regressions that shown up in PHP
4.4.1. All users of PHP 4 are recommended to upgrade to PHP 4.4.2.
A sepa
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
I was wondering if anyone had any ideas about this:
I had extended the DOM classes to make my own xDocument object. Now, I want to
be able to specify a new DTD in the document by default. The problem is, that
the DOMImplementation only returns a dom document. Now I want to be able to
get my xDocum
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
27 matches
Mail list logo
