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 a
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
Okay so I am thinking about submitting a patch to PHP that would enable you to
call functions like this:
stuff(1, 2, 'separator' => '', 'clean' => true);
and define them like this:
/**
* function to do stuff
* @param integer $a
* @param integer $b
* @param string $separator
* Optional, y
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 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 changin
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, n
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 w
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
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 abc(
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
hi,
On Mon, Apr 5, 2010 at 12:07 AM, Stanislav Malyshev 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,
> catchi
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 shoul
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 varia
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
s...@
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
On 5.4.2010 00:45, Pierre Joye wrote:
> On Mon, Apr 5, 2010 at 12:07 AM, Stanislav Malyshev 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
On Wed, Apr 7, 2010 at 8:27 AM, Martin Jansen wrote:
> On 5.4.2010 00:45, Pierre Joye wrote:
>> On Mon, Apr 5, 2010 at 12:07 AM, Stanislav Malyshev 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
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
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
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 wrote:
> On 13.04.2010
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 enhancem
On Fri, Oct 15, 2010 at 10:26 AM, 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' => '', 'clean' => true);
I don't like having the never ending growing list of arguments issue,
but I just use
fun
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" :
> On Fri, Oct 15, 2010 at 10:26
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
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 call
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 alwa
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 -- alth
On 2010-10-16 11:55:40, Reindl Harald 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
--
PHP Internal
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' => '', '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' => '', 'clean' => true);
When I suggested this to Ze'ev in PHP 3
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.
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 t
hi Brian,
On Tue, Oct 19, 2010 at 6:43 PM, Brian Moon 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 the list and
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 (a
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
> pr
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 gues
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
> > p
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
On 4/19/05, Robert Cummings <[EMAIL PROTECTED]> wrote:
> Not that I know of. I think such a concept would be interesting though,
> not as a RYL package, but as a power feature package-- especially if it
> had a mandate to maintain 100% compatibility with normal PHP. Then power
> users could use all
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
> 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.
--
.
48 matches
Mail list logo