This is just not happening people. Please re-read all the past
conversations about it. If you come to some sort of epiphany that solves
all of the issues brought up in the past, please submit a patch.
Otherwise, a never ending thread about this *again* is pointless.
Thanks,
--
Brian.
The absolute minimum is, if you have objections, to be specific, or at
least provide concrete links to specific objections, instead of sending
people to hunt for the decisions manually.
So, anyone that comes on the list and wants to talk about some feature
should just do so without looking at
hi Brian,
On Tue, Oct 19, 2010 at 6:43 PM, Brian Moon br...@moonspot.net wrote:
The absolute minimum is, if you have objections, to be specific, or at
least provide concrete links to specific objections, instead of sending
people to hunt for the decisions manually.
So, anyone that comes on
On 10/15/2010 07:26 PM, G M wrote:
Okay so I am thinking about submitting a patch to PHP that would enable you to
call functions like this:
stuff(1, 2, 'separator' = 'br', 'clean' = true);
and define them like this:
/**
* function to do stuff
* @param integer $a
* @param integer $b
This is just not happening people. Please re-read all the past
conversations about it. If you come to some sort of epiphany that solves
all of the issues brought up in the past, please submit a patch.
Otherwise, a never ending thread about this *again* is pointless.
Thanks,
--
Brian.
On Mon, October 18, 2010 2:45 am, mathieu.suen wrote:
On 10/15/2010 07:26 PM, G M wrote:
Okay so I am thinking about submitting a patch to PHP that would
enable you to call functions like this:
stuff(1, 2, 'separator' = 'br', 'clean' = true);
When I suggested this to Ze'ev in PHP 3.x - 4.0
Am 15.10.2010 19:59, schrieb G M:
It's true that you can already do something similar -- although not as
easily.
I personally always use this pattern:
Is it not and your sample is one of the greatest mistakes you can do
* At this moment $options will be set to an empty array in the caller
What ARE you talking about?
On 10/16/10 5:55 AM, Reindl Harald wrote:
Am 15.10.2010 19:59, schrieb G M:
It's true that you can already do something similar -- although not as easily.
I personally always use this pattern:
Is it not and your sample is one of the greatest mistakes you can do
The topic are named parameters
Am 16.10.2010 17:07, schrieb Gregory:
What ARE you talking about?
On 10/16/10 5:55 AM, Reindl Harald wrote:
Am 15.10.2010 19:59, schrieb G M:
It's true that you can already do something similar -- although not as
easily.
I personally always use this
See below:
On 10/16/10 11:33 AM, Reindl Harald wrote:
The topic are named parameters
Am 16.10.2010 17:07, schrieb Gregory:
What ARE you talking about?
On 10/16/10 5:55 AM, Reindl Harald wrote:
Am 15.10.2010 19:59, schrieb G M:
It's true that you can already do something similar --
On 2010-10-16 11:55:40, Reindl Harald h.rei...@thelounge.net wrote:
What you can do to make your code readable is the following
function stuff($required1, $required2, /**$options*/array())
{
extract($options);
}
Huh?
This code cannot even compile?! What are you talking about?
--
Olivier
Okay so I am thinking about submitting a patch to PHP that would enable you to
call functions like this:
stuff(1, 2, 'separator' = 'br', 'clean' = true);
and define them like this:
/**
* function to do stuff
* @param integer $a
* @param integer $b
* @param string $separator
* Optional,
On Fri, Oct 15, 2010 at 10:26 AM, G M greg...@gregory.net wrote:
Okay so I am thinking about submitting a patch to PHP that would enable you
to call functions like this:
stuff(1, 2, 'separator' = 'br', 'clean' = true);
I don't like having the never ending growing list of arguments issue,
but
I was thinking about passing an array at first. But because of bloated handling
of correct type of each argument in the array I use an object for passing
additional setting variables.
Von meinem iPhone gesendet
Am 15.10.2010 um 19:28 schrieb Michael Shadle mike...@gmail.com:
On Fri, Oct 15,
It's true that you can already do something similar -- although not as easily.
I personally always use this pattern:
function stuff($required1, $required2, $options = array()) {
extract($options);
}
This still, however, makes everyone who call my functions have to do a lot of
extra typing:
This has been discussed to death. Please see the archives. It has been
turned down multiple times.
--
Brian.
http://brian.moonspot.net/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Rasmus - so what is the state of Named Parameters? We discussed it and the
sentiment seemed to be more or less positive about including it in PHP 6.3 .
Now what should happen?
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Think it's also important to keep the IDE factor in mind. By just
defining a catch-all at the end of your function declarations you
essentially cut short any effort that could be made to have IDE code
insight support for this language enhancement.
On 4/13/10, Jordi Boggiano j.boggi...@seld.be
On 13.04.2010 11:44, Tjerk Anne Meesters wrote:
Think it's also important to keep the IDE factor in mind. By just
defining a catch-all at the end of your function declarations you
essentially cut short any effort that could be made to have IDE code
insight support for this language
On 07.04.2010, at 16:16, Christian Schneider wrote:
my gut feeling also says that we shouldnt allow positional arguments after
named parameters.
just picking out one of your examples ..
foreach (new T_User('firstname' = $firstname, ORDER BY age) as $user)
couldnt this also be written as:
On 5.4.2010 00:45, Pierre Joye wrote:
On Mon, Apr 5, 2010 at 12:07 AM, Stanislav Malyshev s...@zend.com wrote:
3. Combining named and un-named params can get weird - i.e. foo(1,2,3) is
simple, foo(1, 2, bar = 3) is doable, but foo(1, 2, bar = 3, 4) would be
trouble, since it is not clear at
On Wed, Apr 7, 2010 at 8:27 AM, Martin Jansen mar...@divbyzero.net wrote:
On 5.4.2010 00:45, Pierre Joye wrote:
On Mon, Apr 5, 2010 at 12:07 AM, Stanislav Malyshev s...@zend.com wrote:
3. Combining named and un-named params can get weird - i.e. foo(1,2,3) is
simple, foo(1, 2, bar = 3) is
In the case whereby names parameters are plucked from the argument
list and passed as a hash to the function it really shouldn't matter
whether that's invalid in python; both (2, 'name' = 'test') and
('name' = 'test', 2) would yield the same results, albeit it's a
highly dubious way of passing
Tjerk Anne Meesters wrote:
In the case whereby names parameters are plucked from the argument
list and passed as a hash to the function it really shouldn't matter
whether that's invalid in python; both (2, 'name' = 'test') and
('name' = 'test', 2) would yield the same results, albeit it's a
On 02.04.2010, at 23:17, GM wrote:
Once again I'd love to create an RFC for this, but I don't think I have
permissions on the wiki to do that. What do I do to get those privileges
granted to my wiki account?
Hmm thought I already mailed you about this .. anyways the link is here (can be
Hi!
The problem however is when an function accepts varargs (usually named
...). if we however bring in strictct-ish naming convention I
don't see any immediate problems
Varargs shouldn't be a problem and we don't even need ... there - we can
just assume every function has implicit
Those are some good points. I would say with regard to 3, that we have
the same problem (sic) with defining arrays in PHP, in terms of it not
being clear what results from array(1, 2, 'a' = $b, 4). Although we
could perfectly copy the array definition semantics, I think you're
right, that
err, sorry, to correct my example:
function abc($a) {
var_export(func_get_args());
}
abc(4, 'a' = 3);
would output array(0 = 4, 'a' = 3)
Greg
Gregory wrote:
Those are some good points. I would say with regard to 3, that we have
the same problem (sic) with defining arrays in PHP, in terms of
hi,
On Mon, Apr 5, 2010 at 12:07 AM, Stanislav Malyshev s...@zend.com wrote:
3. Combining named and un-named params can get weird - i.e. foo(1,2,3) is
simple, foo(1, 2, bar = 3) is doable, but foo(1, 2, bar = 3, 4) would be
trouble, since it is not clear at all where 4 should go to. Moreover,
Hi,
I'm not fully convinced we really need it, I had some moments in the
past where I wished they existed, but always found good solutions.
That said:
On Sun, 2010-04-04 at 18:28 -0400, Gregory wrote:
The question I have is if we are not copying the array semantics
anymore, whether we should
A small comment: I don't think named parameters should seriously affect
performance if we check for their presence during the call. That is to
say, if a call has no named parameters, use what we use now. Otherwise,
push an extra hash variable on to the end of the stack. Creating this
hash
Hi!
http://diveintopython.org/power_of_introspection/optional_arguments.html
This approach could work too, except that simple literal means constant
in PHP, unlike Python. So array syntax might be more natural, but both
can work I guess.
--
Stanislav Malyshev, Zend Software Architect
I really doubt named parameters would have much of an impact on
anything, but I'd be willing to consider it if a clean implementation
was to show up.
I think they'd allow to manage complex parameter sets more efficiently
than with those $options arrays. But that'd probably require changing
the
I don't think thad would require thad much work. we allready have arginfo
that does type hinting...
Modifieing that to support rewrtiting param order based on reflection Info
shouldn't be that hard...
The problem however is when an function accepts varargs (usually named
...). if we however
I was hoping to start some discussion regarding named parameters. I'm
sorry if it's frowned upon to re-post or re-paste something, but I'm
thinking that perhaps my email (with the subject Re: Hi) was
overlooked on the list in whatever readers, so I'm going to post it
again, this time with
On 04/02/2010 02:17 PM, GM wrote:
What do you guys think? I really want PHP 6 to rock and have an even
better reputation among businesses, programmers, etc.
I really doubt named parameters would have much of an impact on
anything, but I'd be willing to consider it if a clean implementation
was
Hi!
I really doubt named parameters would have much of an impact on
anything, but I'd be willing to consider it if a clean implementation
was to show up.
I think they'd allow to manage complex parameter sets more efficiently
than with those $options arrays. But that'd probably require
On 2010-04-02, at 9:02 PM, Stanislav Malyshev wrote:
I think they'd allow to manage complex parameter sets more efficiently than
with those $options arrays. But that'd probably require changing the way how
parameters are passed, since the stack won't work too good anymore for it.
FWIW,
Hendy Irawan wrote:
I think it's nice to have a risk your life PHP version that merges
all available patches that never got into the official PHP.
Does something like this already exist?
Take a look at http://www.zend.com/zend/week/pat/ . It's a list of
not-yet-accepted patches. It's not so
Does anybody want named parameters?
These are handy as template functions (like in Smarty), and these are
achievable since the oldest PHP by using associative arrays. It's
purely syntactic sugar, but it's a very convenient thing I guess (and
promotes long, long lists of parameters as well ;-)
--
On Mon, 2005-04-18 at 12:40, Hendy Irawan wrote:
Does anybody want named parameters?
These are handy as template functions (like in Smarty), and these are
achievable since the oldest PHP by using associative arrays. It's
purely syntactic sugar, but it's a very convenient thing I guess (and
On 4/18/05, Robert Cummings [EMAIL PROTECTED] wrote:
On Mon, 2005-04-18 at 12:40, Hendy Irawan wrote:
Does anybody want named parameters?
These are handy as template functions (like in Smarty), and these are
achievable since the oldest PHP by using associative arrays. It's
purely
On Mon, 2005-04-18 at 13:02, Hendy Irawan wrote:
On 4/18/05, Robert Cummings [EMAIL PROTECTED] wrote:
On Mon, 2005-04-18 at 12:40, Hendy Irawan wrote:
Does anybody want named parameters?
These are handy as template functions (like in Smarty), and these are
achievable since the
the power features of Power-PHP (not that it could be called Power-PHP
without the blessing of Zend :)
The PHP Group, not Zend.
--Wez.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Mon, 2005-04-18 at 13:34, Wez Furlong wrote:
the power features of Power-PHP (not that it could be called Power-PHP
without the blessing of Zend :)
The PHP Group, not Zend.
My bad and my apologies to the PHP Group.
Cheers,
Rob.
--
On Mon, 18 Apr 2005, Hendy Irawan wrote:
Does anybody want named parameters?
These are handy as template functions (like in Smarty), and these are
achievable since the oldest PHP by using associative arrays. It's
purely syntactic sugar, but it's a very convenient thing I guess (and
Derick Rethans wrote:
On Mon, 18 Apr 2005, Hendy Irawan wrote:
Does anybody want named parameters?
These are handy as template functions (like in Smarty), and these are
achievable since the oldest PHP by using associative arrays. It's
purely syntactic sugar, but it's a very convenient thing I
47 matches
Mail list logo
