Re: [PHP-DEV] Named parameters
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, can we please not do that. Many things that have been rejected multiple times have made it into PHP, including closures and namespaces. Things are not static, and the rationale for a feature may change in time. 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. Stan Vass -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Named parameters
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 the history of the topic? That seems backwards to me. This group is open to new ideas. But, drudging up old ideas over and over and over is not productive. This topic gets brought up once per year minimum and never gets traction. But here, I will do the work for you this once. It took 10 seconds to search Google. http://www.php.net/~derick/meeting-notes.html#named-parameters Have a look at the attendee list on that meeting. If you can convice all those people, most of which are all still very active, go for it. But, the emails I have seen are the same emails I have seen before. Nothing new. Just trying to save people some wasted time. -- Brian. http://brian.moonspot.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Named parameters
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 the list and wants to talk about some feature should just do so without looking at the history of the topic? It does not justify this kind of reply, like stop it, it won't happen.. However you are right, reading the archive helps. Now that we have RFC, it is easier to track past proposals than digging some random discussions. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Named parameters
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
* @param string $separator
* Optional, you can override the separator
* @param boolean $clean
* Optional, if true then things are done more cleanly
* @param integer $cool
* Optional. Overrides the default coolness level of 7.
*/
function stuff($a, $b)
{
var_export(func_get_args());
}
Why not change the parser to accept also this:
function stuff($a, $b, optional($separator = 1, $clean = false))
{
}
so that the call
stuff(1, 2, 'separator' = 'br', 'clean' = true)
will output
array(1, 2, 'separator' = 'br', 'clean' = true)
see the consistency? :)
The way I plan to do this is by changing the parser to notice arguments passed
like 'a' = 'b' at the end of the argument list, and pass a hidden array
variable on the stack, so when func_get_args() is called, it will merge this array
on top of what func_get_args would return. I also want to make another function,
func_extract_args which will basically extract the optional arguments, so I can
more easily refer to them as $separator, $clean, etc.
What do you guys think of this? Would it be useful to you? I really hope for
this feature to make it into PHP 6, so I might sit down and code it myself, to
show it can be done.
The reason I really want this to make it into PHP 6 is because I noticed that
function parameter lists just grow with time, and they provide a poor mechanism
for designing nice interfaces. For example I'd hate to write this:
stuff(1, 2, null, 'br', true, null)
as it provides no clue as to what the values are for, and also there are lots of extra
null values I had to pass just so I can specify some optional values. And if
the function had defaults like this:
stuff($a, $b, $c = null, $separator = \n, $clean = false, $cool = 7, $more =
array())
then that would be even worse, as I'd have to re-type the non-null, and if they
ever changed, I'd be out of luck.
All this is solved in a way that extends the array( ) syntax to function
calling (well, almost ... I think it would be cleaner to put all optional
arguments at the end of the argument list, as opposed to interspersing them).
What do you guys think? Would this be useful to you? I personally would use it
all the time and wonder how PHP was without it, but perhaps other people
couldn't care less? Maybe it has some negative side effects that I haven't
thought ot?
Greg
-- Mathieu Suen
Re: [PHP-DEV] Named parameters
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. http://brian.moonspot.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Named parameters
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 days, I believe his response ran along the lines of running away screaming into the night... After a decade of reflection, I think it over-complicates PHP, which we don't really need. Just pass in an array with whatever parameters you want, and tear it apart in the function. You can @document that array in any way you choose, naming all the valid keys, and what they ought to be. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Named parameters
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
* You must use the correct order because $options does not matter
* The sample is dangerous for performance and side-effects
function stuff($required1, $required2, $options = array())
{
extract($options);
}
What you can do to make your code readable is the following
function stuff($required1, $required2, /**$options*/array())
{
extract($options);
}
signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] Named parameters
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
* At this moment $options will be set to an empty array in the caller
* You must use the correct order because $options does not matter
* The sample is dangerous for performance and side-effects
function stuff($required1, $required2, $options = array())
{
extract($options);
}
What you can do to make your code readable is the following
function stuff($required1, $required2, /**$options*/array())
{
extract($options);
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Named parameters
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 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
* You must use the correct order because $options does not matter
* The sample is dangerous for performance and side-effects
function stuff($required1, $required2, $options = array())
{
extract($options);
}
What you can do to make your code readable is the following
function stuff($required1, $required2, /**$options*/array())
{
extract($options);
}
--
Mit besten Grüßen, Reindl Harald
the lounge interactive design GmbH
A-1060 Vienna, Hofmühlgasse 17
CTO / software-development / cms-solutions
p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40
icq: 154546673, http://www.thelounge.net/
signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] Named parameters
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 -- 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
Are you implying that calling stuff($a, b) will now set $options =
array() in the CALLER?
So now I can use $options?
* You must use the correct order because $options does not matter
What does this mean, $options does not matter? You must pass parameters
in the correct order, that's really the whole point of this pattern --
sometimes you don't want this.
* The sample is dangerous for performance and side-effects
Dangerous? Which part, default parameters are dangerous, or extract() is
dangerous? If the latter, don't use extract().
function stuff($required1, $required2, $options = array())
{
extract($options);
}
What you can do to make your code readable is the following
function stuff($required1, $required2, /**$options*/array())
{
extract($options);
}
Wait, this is *more* readable than $options = array()?
And does this even compile?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Named parameters
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Named parameters
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 just use
function foo($args = array()) {
# first pass to normalize, check, scrub data
$bar = isset($args['whatever']) ? intval($args['whatever']) : 0;
# second pass to do sanity checking or business logic...
if($bar 0) {
...
}
}
Looks like Drupal 7 is taking this approach with some things too.
I am not sure the language itself needs anything to change, it can be
done today and seems like an additional feature to shortcut something
already available.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Named parameters
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, 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 just use
function foo($args = array()) {
# first pass to normalize, check, scrub data
$bar = isset($args['whatever']) ? intval($args['whatever']) : 0;
# second pass to do sanity checking or business logic...
if($bar 0) {
...
}
}
Looks like Drupal 7 is taking this approach with some things too.
I am not sure the language itself needs anything to change, it can be
done today and seems like an additional feature to shortcut something
already available.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Named parameters
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:
stuff(1, 2, array('a' = 'b')) // well, not a lot but they have to type array(
) EVERY TIME
instead, wouldn't it be nice if
a) Every function ever written could become extensible
b) People would be able to use that really easily: stuff(1, 2, 'a' = 'b', $c
= $d)?
PS: Please let's NOT make it stuff(1, 2, a = 'b', c = $d) as it would take
away the option of having variable key names, which we can have in array().
Also it would create slight ambiguity with constants.
On Oct 15, 2010, at 1:27 PM, Michael Shadle wrote:
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 just use
function foo($args = array()) {
# first pass to normalize, check, scrub data
$bar = isset($args['whatever']) ? intval($args['whatever']) : 0;
# second pass to do sanity checking or business logic...
if($bar 0) {
...
}
}
Looks like Drupal 7 is taking this approach with some things too.
I am not sure the language itself needs anything to change, it can be
done today and seems like an additional feature to shortcut something
already available.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Named parameters
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
Re: [PHP-DEV] Named Parameters
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 wrote:
On 13.04.2010 01:30, Pierre Joye wrote:
On Tue, Apr 13, 2010 at 1:28 AM, Stanislav Malyshev s...@zend.com wrote:
I think that's the idea in general, now how it looks like - be it 'opt1'
=
'no-foo' or opt1: 'no-foo' - that's the decision we need to take. I
personally still don't have the favorite, but in every case we still have
the full params list, otherwise the whole story is kind of useless - we
can
pass arrays as arrays now.
I'd to go with opt1: 'value', I really don't the idea of having to use
quotes for the name of the argument.
Same here, although quoted means that we could potentially use dynamic
values (pending approval from parser gurus). I don't care for it, but I
know people will ask..
As for the passing arrays, in some cases, I think if we introduce named
parameters we might as well take the occasion to implement the rest
operator. In actionscript3 you can do the following (written in php):
function foo($a, $b, ... $stuff) {
print_r($stuff);
}
foo(1, 2, foo: FOO, bar: BAR);
// array('foo' = 'FOO', 'bar' = 'BAR')
Now you only get args that weren't defined but still passed in this
magic array. In AS3 you don't have named params so it's a bit of a
func_get_args() + array_shift() equivalent, but here it would allow you
to pass arbitrary values as an array without having to use the whole
array syntax, which while we're at it would make the
array-shorthand-please camp happy too I believe.
Another use for that operator, as I had requested a few years ago, would
be to allow extending/implementing a function with potentially more args
than the minimal interface requires, without hacking it with
func_get_args(), i.e. this:
interface foo {
function bar($a);
}
class fooimpl implements foo {
function bar($a, $b) {
}
// Fatal error: Declaration of fooimpl::bar() must be compatible with
that of foo::bar()
While using rest arg without/after a var name would allow extending the
arg signature:
interface foo {
function bar($a ...);
}
class fooimpl implements foo {
function bar($a, $b) {
}
// Happily declared
Cheers,
Jordi
--
--
Tjerk
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Named Parameters
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 enhancement. Well, it's obviously made for those cases when you need very high amount of parameters, or just dynamically named ones, and I don't see what's the problem of doing it with a catch-all arg versus passing an array (which is what people do now), both will screw the IDEs over since accepted parameters are not statically defined. Cheers, Jordi signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Named Parameters
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:
foreach (new T_User('firstname' = $firstname, ORDERBY = age) as $user)
of course it would be a bit more work when constructing the final query, but
its tons clearer in terms of knowing how to use the API with just reading one
use of the API and not the actual implementation.
in the above code what is the purpose of the positional argument? can i just
append what I want? aka is the idea of the API to also support
foreach (new T_User('firstname' = $firstname, LIMIT 100) as $user)
and
foreach (new T_User('firstname' = $firstname, ORDER BY age LIMIT 100) as
$user)
in that case it would still be better to then do:
foreach (new T_User('firstname' = $firstname, 'append' = ORDER BY age) as
$user)
.. of course its a few more characters, but its definitely easier to grasp
whats going on, then having to parse what is named and what is positional.
i am trying to remember what killed the discussion last time around. i think it
was concerns over having to convert all internal functions, but i guess that
was before we unified the parameter parsing API. IIRC hartmut was quite
involved in the discussion back then .. maybe he remembers.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Named Parameters
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 all where 4 should go to. Moreover, If we introduce named argument, mixing them should not be weird. An argument can have both a name and a position, allowing combination of normal or named arguments. Python's way to do it is very nice and handy: http://diveintopython.org/power_of_introspection/optional_arguments.html Just to be clear about this: Python does not allow using an unnamed parameter after a named parameter occurred, i.e. foo(bar = 3, 2) is not valid there. I would go as far as disallowing mixing of named and unnamed parameters completely. But that's probably just me. - Martin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Named Parameters
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 doable, but foo(1, 2, bar = 3, 4) would be trouble, since it is not clear at all where 4 should go to. Moreover, If we introduce named argument, mixing them should not be weird. An argument can have both a name and a position, allowing combination of normal or named arguments. Python's way to do it is very nice and handy: http://diveintopython.org/power_of_introspection/optional_arguments.html Just to be clear about this: Python does not allow using an unnamed parameter after a named parameter occurred, i.e. foo(bar = 3, 2) is not valid there. Right, the doc is clear about that and makes the whole thing less confusing. I would go as far as disallowing mixing of named and unnamed parameters completely. But that's probably just me. That would defeat the main purposes of named arguments. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Named Parameters
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 arguments ;-)
On 4/7/10, 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 doable, but foo(1, 2, bar = 3, 4) would
be
trouble, since it is not clear at all where 4 should go to. Moreover,
If we introduce named argument, mixing them should not be weird. An
argument can have both a name and a position, allowing combination of
normal or named arguments. Python's way to do it is very nice and
handy:
http://diveintopython.org/power_of_introspection/optional_arguments.html
Just to be clear about this: Python does not allow using an unnamed
parameter after a named parameter occurred, i.e. foo(bar = 3, 2) is not
valid there.
I would go as far as disallowing mixing of named and unnamed parameters
completely. But that's probably just me.
- Martin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
--
Tjerk
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Named Parameters
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
highly dubious way of passing arguments ;-)
Actually we use positional (scalar) both after and before named
(associative) parameters a lot for HTML generation and DB queries:
$html = table('class' = beautiful,
tr(
td(foo), td(bar),
),
tr(
td(qux), td(quux),
),
);
foreach (new T_User('firstname' = $firstname, ORDER BY age) as $user)
...
$bar = it::replace('Foo' = Bar, $foo, 'casesensitive' = true);
So any solution restricting named parameters to any of
- declared named parameters only
- not allowing alternating named/positional parameter sets while
maintaining these sets and order
would not fit our needs.
As a result our patch (and syntax converter in both directions for
unpatched webservers) uses a simple but somewhat limited approach:
Any sequence of key = value pairs in a function call are surrounded by
array() (done at compile time). This means functions accepting
interleaved named/non-named parameters need to do some varargs parsing
and sometimes you need to still manually add array() if you want to
separate two sets of named parameters (but that's a questionable API in
most cases).
More info: http://cschneid.com/php/INFO_README
Patch and manual converter: http://cschneid.com/php/
Autoloader with automatic syntax conversion: http://itools.search.ch/
I know I've mentioned this here before but I still think its pros and
cons should be taken into consideration when talking about this subject,
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Named Parameters
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 found by clicking on login on the lower right navi bar): http://wiki.php.net/start?do=register regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Named Parameters
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 ... at the end (more or less what we are doing now). We have the following issues to overcome now: 1. We don't keep the name information on the receiving end. It should be pretty easy to fix - the parser knows the variable names. So instead of a number RECV opcode can just get a name, or maybe have separate name table that corresponds to numbers. 2. We don't have a way to pass the name information on the sending end - right now we use stack, which would not go well with named params. We'd probably have to switch to a hashtable - which would require substantial change to parameter change/receive code - but should be doable. Though introducing a hashtable may have performance impact there. 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, catching this situation can be non-trivial, as right now parsing nested function calls may not keep enough context for this. 4. varargs can be dealt with by either extending func_get_args() to provide name information or maybe by having some function that returns only those args that do not have matching names (that would make generic options easier to do). -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Named Parameters
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(1, 2, 'a' = $b, 3) is not really useful in the first
place. So with that in mind, we could stop perfectly duplicating array
definition semantics, and instead have the following:
a) Regular parameters cannot appear after named parameters, i.e. abc(1,
2, 'a' = $b) is fine but abc(1, 'a' = $b, 2) is not
b) Because of this, we can easily see where the named parameters start
(and indeed if they are present in the call). Then, you can implicitly
add a variable to the end of the stack which points to a hash, which
contains the named parameters.
c) Then, func_get_args would be extended to check for the presence of
this hash, and when it's there, simply merge it on top of the array it
would have returned. Thus, if the function was abc($a) and I called it
with abc(4, 'a' = 3) then func_get_args() inside abc would give array(0
= 3, 'a' = 3).
The question I have is if we are not copying the array semantics
anymore, whether we should have abc('a' = 3) or abc(a = 3). I
personally would prefer 'a' = 3 because that allows for variable
parameter names.
Greg
Stanislav Malyshev wrote:
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 ... at the end (more or
less what we are doing now). We have the following issues to overcome
now:
1. We don't keep the name information on the receiving end. It should
be pretty easy to fix - the parser knows the variable names. So
instead of a number RECV opcode can just get a name, or maybe have
separate name table that corresponds to numbers.
2. We don't have a way to pass the name information on the sending end
- right now we use stack, which would not go well with named params.
We'd probably have to switch to a hashtable - which would require
substantial change to parameter change/receive code - but should be
doable. Though introducing a hashtable may have performance impact there.
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, catching this situation can be non-trivial, as right now
parsing nested function calls may not keep enough context for this.
4. varargs can be dealt with by either extending func_get_args() to
provide name information or maybe by having some function that returns
only those args that do not have matching names (that would make
generic options easier to do).
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Named Parameters
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 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(1, 2, 'a' = $b, 3) is not really useful in the first
place. So with that in mind, we could stop perfectly duplicating
array definition semantics, and instead have the following:
a) Regular parameters cannot appear after named parameters, i.e.
abc(1, 2, 'a' = $b) is fine but abc(1, 'a' = $b, 2) is not
b) Because of this, we can easily see where the named parameters start
(and indeed if they are present in the call). Then, you can implicitly
add a variable to the end of the stack which points to a hash, which
contains the named parameters.
c) Then, func_get_args would be extended to check for the presence of
this hash, and when it's there, simply merge it on top of the array it
would have returned. Thus, if the function was abc($a) and I called it
with abc(4, 'a' = 3) then func_get_args() inside abc would give
array(0 = 3, 'a' = 3).
The question I have is if we are not copying the array semantics
anymore, whether we should have abc('a' = 3) or abc(a = 3). I
personally would prefer 'a' = 3 because that allows for variable
parameter names.
Greg
Stanislav Malyshev wrote:
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 ... at the end (more or
less what we are doing now). We have the following issues to overcome
now:
1. We don't keep the name information on the receiving end. It should
be pretty easy to fix - the parser knows the variable names. So
instead of a number RECV opcode can just get a name, or maybe have
separate name table that corresponds to numbers.
2. We don't have a way to pass the name information on the sending
end - right now we use stack, which would not go well with named
params. We'd probably have to switch to a hashtable - which would
require substantial change to parameter change/receive code - but
should be doable. Though introducing a hashtable may have performance
impact there.
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, catching this situation can be non-trivial,
as right now parsing nested function calls may not keep enough
context for this.
4. varargs can be dealt with by either extending func_get_args() to
provide name information or maybe by having some function that
returns only those args that do not have matching names (that would
make generic options easier to do).
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Named Parameters
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, catching this situation can be non-trivial, as right now parsing nested function calls may not keep enough context for this. If we introduce named argument, mixing them should not be weird. An argument can have both a name and a position, allowing combination of normal or named arguments. Python's way to do it is very nice and handy: http://diveintopython.org/power_of_introspection/optional_arguments.html I did not look at the parser implementation or limitation lately, but it would rock if we can use the same syntax than python. It should not conflict with any existing syntax (foo($a = 1) already works, with operator precedence). Again, if the parser allows it :) I also don't see another way to do it than using a hash (or similar constructs) which will certainly have a significant impact on performance. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Named Parameters
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 have abc('a' = 3) or abc(a = 3). I
personally would prefer 'a' = 3 because that allows for variable
parameter names.
Allowing variable parameter names means allowing any expression (else it
gets messy with inconsistent rules) which means that we allow a very
flexible syntax which might lead to code that's hard to understand. If
you don't know which parameters you want to provide maybe an array is
the better option. With such a syntax I expect more abuse than useful
use of the feature.
For do_something(parameter = 23); we have the benefit, that IDEs could
easily validate that which prevents typos and provide aid. But then I'm
not sure this fits to the language either as we always expect quoted
names. And from the some distance this looks like a constant used used
as parameter name, as in
?php
const foo = 42;
$a = array(foo = 'bar');
do_something(foo = 'bar');
?
Another possible limitation there is that our parser won't allow
keywords there. An example where this might be annoying might be
something along these lines:
?php
function getInstance($param1 = 1, $param2 = 2, $class = 'default_class' {
$r = new ReflectionClass($class);
return $r-createInstance($param1, $param2);
}
getInstance(class = 'my_class');
?
Just some random thoughts, maybe somebody has a better syntax, maybe
that's just me,
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Named Parameters
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 variable should be no more overhead than if the user manually
passed in an array() as the last parameter.
Johannes: yeah I think I strongly prefer $parameter = 23. Like you
said, it looks like a constant if we used f(parameter=23) . In fact,
arrays with arbitrary keys are useful and PHP already has
$arr['foo-bar'], ${'foo-bar'} and $baz-{'foo-bar'}, so f('parameter' =
23) is not such a stretch. Especially since func_get_args returns an
array. There is only one case where things get a little hairy, and
that's f(2, '0' = 4) which will probably make func_get_args() return
array(4) ... just as array(2, '0' = 4) would return array(4).
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Named Parameters
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...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Named Parameters
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 way how parameters are passed, since the stack won't work too good anymore for it. Is the desire for named parameters to only have it for user land function/methods? If so, I am kind of -.5 on this because that would be a little WTF for a new user. If not, then it is a huge undertaking as every internal function and pecl extension would have to be updated to support them. In which case it is a ton of work. I have long ago started passing arrays and doing validation myself, which sucks. I admit, named parameters + scalar type hints would be quite nice and simplify a lot of my code. Brian. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Named Parameters
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 bring in strictct-ish naming convention I don't see any immediate problems On Apr 3, 2010 1:02 AM, Stanislav Malyshev s...@zend.com wrote: Hi! I really doubt named parameters would have much of an impact on anything, but I'd be willing t... 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. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net...
Re: [PHP-DEV] Named Parameters
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 to show up. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Named Parameters
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 changing the way how parameters are passed, since the stack won't work too good anymore for it. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Named Parameters
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, named parameters would be a great aid in building uncoupled systems—particularly when some of the tiers are not based on PHP. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: mixed up PHP variant (Re: [PHP-DEV] named parameters?)
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 comfortable as RYL version but can serve for the same demand. Jakub Vrana -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] named parameters?
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 promotes long, long lists of parameters as well ;-) I for one would love them since they are very nice and concise for functions that take optional parameters and have a lot of them (such as generic search functions). It would save on the creation of a temporary array, and then having pass that to the function. But then, I also think this has been to the list before, and we don't currently have named parameters, so I'm guessing it got shot down already :) Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] mixed up PHP variant (Re: [PHP-DEV] named parameters?)
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 syntactic sugar, but it's a very convenient thing I guess (and promotes long, long lists of parameters as well ;-) I for one would love them since they are very nice and concise for functions that take optional parameters and have a lot of them (such as generic search functions). It would save on the creation of a temporary array, and then having pass that to the function. But then, I also think this has been to the list before, and we don't currently have named parameters, so I'm guessing it got shot down already :) Yeah, I think so... but I did a search on the archives and found nothing (at least, I found nothing on the first N results... maybe the full text indexer needed some tweaking) Anyways, what PHP alternatives to PHP are already available out there? 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. People building the RYL PHP will have to specify something like: ./configure --enable-named-parameters --enable-attributes to enable these features (or maybe --enable-all-experimental for the most adventurous). Giving no optional features would build an exact PHP as the official version. Does something like this already exist? -- Hendy Irawan http://www.gauldong.net http://dev.gauldong.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: mixed up PHP variant (Re: [PHP-DEV] named parameters?)
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 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 ;-) I for one would love them since they are very nice and concise for functions that take optional parameters and have a lot of them (such as generic search functions). It would save on the creation of a temporary array, and then having pass that to the function. But then, I also think this has been to the list before, and we don't currently have named parameters, so I'm guessing it got shot down already :) Yeah, I think so... but I did a search on the archives and found nothing (at least, I found nothing on the first N results... maybe the full text indexer needed some tweaking) Anyways, what PHP alternatives to PHP are already available out there? 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. People building the RYL PHP will have to specify something like: ./configure --enable-named-parameters --enable-attributes to enable these features (or maybe --enable-all-experimental for the most adventurous). Giving no optional features would build an exact PHP as the official version. Does something like this already exist? 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 of the existing scripts made for PHP and have all the power features of Power-PHP (not that it could be called Power-PHP without the blessing of Zend :) Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: mixed up PHP variant (Re: [PHP-DEV] named parameters?)
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
Re: [PHP-DEV] Re: mixed up PHP variant (Re: [PHP-DEV] named parameters?)
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. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] named parameters?
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 promotes long, long lists of parameters as well ;-) This was suggested before, and declined. Please search the archives. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] named parameters?
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 guess (and promotes long, long lists of parameters as well ;-) This was suggested before, and declined. Please search the archives. Derick As far as I remember this was brought to the list first by Thies and later by me, back in the days when PHP 5 was still on the design table. It was said that it is so late, and should wait for PHP 6 :) . PHP 5 took 4 years after PHP 4. So PHP 6 may take another 5 years after PHP 5 - 2009 :). Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
