date:20120418

Hi!

> Before addressing the points individually, I have to reiterate that
> internal functions have no concept of default values. I think this

I disagree. Most of them certainly do, for example, look at strpos
documentation:

int strpos ( string $haystack , mixed $needle [, int $offset = 0 ] )

$offset is documented as having default of 0. Right now it is
implemented in ad-hoc manner - i.e. you set up the value, but you don't
actually declare it anywhere as some special "default value". But it is
certainly there and for the user it is certainly a default as any other.
We didn't do the best job documenting all these, unfortunately (see
below) but in almost all cases they are there.

> Instead, we have lots of functions that will not only break (see below for
> a definition of "break"), but break subtly (e.g. uninitialized values) and

Any function that passes uninitialized value to optional argument has a
bug and needs to be fixed.

> only under very particular conditions (using this new feature). Plus, they
> increase the complexity of doing argument parsing (surely no one will
> forget checking for NULLs). All the functions that use ZEND_NUM_ARGS()
> have to be reviewed and the PHP core is just the tip of the iceberg.

For 99.9% of the functions there's no increase of complexity since they
already do the right thing. As for the matter of checking for NULL being
too complex - this is the absolutely basic thing you always do in C,
check your pointers, if you write engine code it can't be too complex
for you.

> I was talking about ZEND_NUM_ARGS(). My point is that ZEND_NUM_ARGS() now
> gives near-0 useful information. Yes, you can know which arguments were
> passed through other means, but not via ZEND_NUM_ARGS(), which what many
> functions are currently using.

This is not true. It gives the same information as before, and it is
very useful. The only case where you'd have to take some extra case is
where you do not use recommended APIs but try to fetch arguments from
stack manually or when you have complex dependencies between parameters.
Then you'd have to check for NULLs and decide if you are ready to accept
parameters after that. Not rocket science by any measure.

> When I say this "breaks" current functions, I don't mean they will never
> work again. I mean that, due to different semantics in argument passing,
> they will have to be changed. I'm assuming even the though cases like
> PDOStatement::fetchAll() can be fixed.

Yes, some functions with extremely complex corner cases of parameter
parsing will have to be slightly changed. I'll think how to make this
change easier. Of course, for this functions notion of default
parameters won't work - we may even introduce some API to tell
zend_parse_parameters about it. But for many other functions it may work
just fine. For example, in the same PDO you have:

bool PDOStatement::bindColumn ( mixed $column , mixed &$param [, int
$type [, int $maxlen [, mixed $driverdata ]]] )

Now, what you do if you want to supply $driverdata but don't care about
max length? We have two problems here:
1. Defaults are not documented, so you have zero idea how to get default
behavior without looking into C code.
2. Defaults could change and you'd have to change your code.

Skipping parameters would work here just fine and will use the same
defaults the code uses, with zero pain to the user.

> mt_srand() was a bad example. But let's supposed it didn't initialize
> seed. It would be perfectly correct under current semantics, but as far as
> I understand under the patch mt_srand(default) would result in
> uninitialized data being used.

If it didn't initialize seed, it would be a bug which even now needs to
be fixed. You're not supposed to pass uninitialized values for default
args into zend_parse_parameters, if you code does that, please fix it ASAP.

> All it does is check for (PHP) NULLs before using zpp with "l", because
> "l" would convert the NULL to 0 and I want to distinguish the two cases,
> so that I can use NULL to the same effect of not passing the argument.
> This was actually discussed in a pull request a few weeks ago.

This seems to be a very unusual special case then, which has very little
to do with topic at hand. Probably unique case in our code. Maybe we
need to change zend_parse_parameters API or your function API or do some
other good solution for it, but it's offtopic for now. Feel free to open
a new thread on that, but for purposes of this one the conclusion is -
yes, if you ignore system APIs then there's some work to be done there.
I'll scan the code for such functions and see how to fix it best, thanks
for bringing this issue to my attention. I do not see however that it
somehow invalidates the concept, as 99% of the functions do not do that
and you're not supposed to do that except in very special circumstances.

> Quickly skimming the output with shows that in some cases it's multiline
> calls, but those are in a clear minority (most are in if/swi

Re: [PHP-DEV] [RFC] skipping optional parameters

On Wed, 18 Apr 2012 23:35:37 +0200, Stas Malyshev
wrote:

Before addressing the points individually, I have to reiterate that
internal functions have no concept of default values. I think this
proposal or a named arguments proposal is *really* ill-advised without
introducing proper default values for internal functions. Then the engine
could pass those default values on the stack and we would have none of
these problems.

Instead, we have lots of functions that will not only break (see below for
a definition of "break"), but break subtly (e.g. uninitialized values) and
only under very particular conditions (using this new feature). Plus, they
increase the complexity of doing argument parsing (surely no one will
forget checking for NULLs). All the functions that use ZEND_NUM_ARGS()
have to be reviewed and the PHP core is just the tip of the iceberg.

the number of arguments actually passed. But even if it returned the
number of arguments passed, it would be irrelevant because you would not
know *which* arguments were passed.

I would know. Unless you're using "+" in zend_parse_parameters but
actually have positional arguments - so far I know no such functions but
if I discover any I'll see how to handle it.

I was talking about ZEND_NUM_ARGS(). My point is that ZEND_NUM_ARGS() now
gives near-0 useful information. Yes, you can know which arguments were
passed through other means, but not via ZEND_NUM_ARGS(), which what many
functions are currently using.

Z params won't stop working, why should they? They'd just have nulls
there. You'd have to handle these nulls of course.

When I say this "breaks" current functions, I don't mean they will never
work again. I mean that, due to different semantics in argument passing,
they will have to be changed. I'm assuming even the though cases like
PDOStatement::fetchAll() can be fixed.

Passing default to mt_srand makes little sense since mt_srand doesn't
have default documented. But we can define it as being 0. Of course,
mt_srand(default) will be different from mt_srand() then, but so what?
It doesn't break anything.

mt_srand() was a bad example. But let's supposed it didn't initialize
seed. It would be perfectly correct under current semantics, but as far as
I understand under the patch mt_srand(default) would result in
uninitialized data being used.

https://github.com/cataphract/php-src/blob/intl_calendar/ext/intl/calendar/calendar_methods.cpp#L399
-- and guess what -- your feature would break this.

I don't think it will break that. You may have to do a bit more work to
do it, but it can be done. Though frankly I have no idea what that code
is supposed to do and suspect it is not really a good API if it requires
this level of variation in one function. It basically doing all
parameters handling by itself instead of using system API and this is
usually a bad sign.

All it does is check for (PHP) NULLs before using zpp with "l", because
"l" would convert the NULL to 0 and I want to distinguish the two cases,
so that I can use NULL to the same effect of not passing the argument.
This was actually discussed in a pull request a few weeks ago.

Good or bad, usage of ZEND_NUM_ARGS() is all over the place:

glopes@nebm:~/php/php-src$ git grep -n ZEND_NUM_ARGS | grep -v
zend_parse

| grep -v zend_get_parameters | wc -l
364

Yeah, I've fallen into this trap too initially. Most of those are
multiline calls to zend_parse_parameters and checks that are completely
harmless.

Quickly skimming the output with shows that in some cases it's multiline
calls, but those are in a clear minority (most are in if/switch
statements). And remember, this is just PHP core, a small fraction of all
extensions.

--
Gustavo Lopes

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Allow non-variable arguments to empty()

2012-04-18 Thread Kris Craig

Ugh I hate to throw a POO into this, but

On Wed, Apr 18, 2012 at 4:09 PM, Nikita Popov wrote:

> Hey internals :)
>
> As there doesn't seem to be any further discussion regarding my RFC,
> I've opened the vote:
>
> https://wiki.php.net/rfc/empty_isset_exprs#vote
>
> Nikita
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
"There'd be a minimum of 2 weeks between when an RFC that touches the
language is brought up on this list and when it's voted on is required.
Other RFCs might use a smaller timeframe, but it should be at least a week."

(from http://wiki.php.net/rfc/voting)

>From what I can tell, you first created the topic on this 6 days ago.  Even
if this didn't touch the language (which I think it does), voting would not
be permissible yet.

For the record, I do plan to vote yes on this and I think the voting rules
should be amended to allow for sooner voting if discussion has ended.  But
until such amendments are made, are we really comfortable setting a
precedent of just ignoring the policy whenever it proves inconvenient?  I
know I've been a bit of a lightning rod recently but I really think we
should make a decision on how we want to handle this.  Personally, I'm a
big fan of having consistent procedures and defined parameters.  But if
we're going to treat the voting RFC as binding or non-binding, I just think
we should overtly express a collective position on that here.

I'll refrain from voting on this until other people have had a chance to
weigh-in on this concern.  I think we basically have three choices:  Cancel
the vote on this RFC and wait until the 2 weeks have passed, come to a
decision that the rules in the voting RFC are non-binding, *or *(and this
would be my preference) let it slide this time with the understanding that
we'll add clarifying language to the voting procedure in the forseeable
future.

And in the interest of making people not want to murder me and feed my
entrails to a pack of wild ferrets, I'll shut up now.  ;)

--Kris

[PHP-DEV] [VOTE] Allow non-variable arguments to empty()

2012-04-18 Thread Nikita Popov

Hey internals :)

As there doesn't seem to be any further discussion regarding my RFC,
I've opened the vote:

https://wiki.php.net/rfc/empty_isset_exprs#vote

Nikita

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Addition of calendar to intl

Hi!

> I think the documentation part in this case is not as problematic,
> because the interface has been thoroughly documented in the ICU
> project. Most of your next questions can be answered by reading
> 
> http://userguide.icu-project.org/datetime/calendar

This is ICU docs, not PHP docs. Most PHP users wouldn't even know where
to find it, let alone how to use it applied to PHP. We need something to
list the functions and what they do. RFC can serve this role, until
proper docs are written, but since you've skipped it, we need some other
solution, but without that it will be hard to make use of it effectively.

> See http://userguide.icu-project.org/datetime/calendar#TOC-Usage

OK, I see but it refers to UDate and operations with it - does it
duplicate what we do with DateTime? What would be typical use case - to
use DateTime or your calendar functions? Would I have to keep dates in
two separate forms? How this interacts with DateTime?

> By specifying @calendar=hebrew in the locale (either in 
> intl.default_locale or by passing it to the factory method 
> IntlCalendar::createInstance()).

That definitely has to be documented somewhere.

> The main drive for creating a IntlTimeZone class was simply to 
> encapsulate  ICU TimeZone objects, which the Calendar classes work
> with. Therefore, the support is limited and only the base ICU class
> for timezones is exposed, except for the methods that allow changing
> the TimeZone. ICU allows you to build timezones with arbitrary rules,
>  import/export RFC2445 VTIMEZONE and a lot more, none of which are 
> available with my patch.

I'd say if we already have this class why not support at least most
useful things? I'd find VTIMEZONE support definitely very useful.

> Still, there is already some functionality that doesn't exist in 
> DateTimeZone, like timezone id canonization, localization of time
> zone names on 8 different formats and easier searching for timezones
> according to country and region.

Is there an easy way to get from DateTimeZone to intl one and back (at
least for standard ones, custom ones probably won't work)?
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] skipping optional parameters

Hi!

> Not sure what you mean here. What is this "varargs return"? As far as I  

zend_parse_parameters has varargs options. See how var_dump is implemented.

> the number of arguments actually passed. But even if it returned the  
> number of arguments passed, it would be irrelevant because you would not  
> know *which* arguments were passed.

I would know. Unless you're using "+" in zend_parse_parameters but
actually have positional arguments - so far I know no such functions but
if I discover any I'll see how to handle it.

> addition. There is no reason to think functions shouldn't do manual  
> argument parsing. In fact, they do, and there are even many ways to have  

There is. We have API for argument passing, functions should use it. If
you're not using APIs, you'd have to fix your function when something
changes. This is why we have APIs.

> them do it -- zpp with Z*/z*/Z+/z+, _zend_get_parameters_array,  
> zend_get_parameters_ex and more. These are not one or two and they will  
> stop working,

Z params won't stop working, why should they? They'd just have nulls
there. You'd have to handle these nulls of course.

> But to my argument: many functions use ZEND_NUM_ARGS() to determine if an  
> argument was passed. Sometimes, this is the only way to determine if an  
> argument was passed -- for instance, if we're using zpp with "l", see  
> mt_srand() for an example. For a more drastic example, see the  
> implementation of PDOStatement::fetchAll().

Passing default to mt_srand makes little sense since mt_srand doesn't
have default documented. But we can define it as being 0. Of course,
mt_srand(default) will be different from mt_srand() then, but so what?
It doesn't break anything.
For fetchAll() NULL there might be indeed unexpected - so we may think
about either fixing such cases or letting zend_parse_parameters know if
this parameter can handle default (most can) or it does some fancy stuff
with argument dependencies.

> Now, you may argue that this is a bad practice because you can't pass an  
> argument with a value with same effect of not passing it, and I would  
> agree. In fact, I've just gone through a great deal of trouble to avoid  
> having internal functions with this kind of behavior. See  
> https://github.com/cataphract/php-src/blob/intl_calendar/ext/intl/calendar/calendar_methods.cpp#L399
>   
> -- and guess what -- your feature would break this.

I don't think it will break that. You may have to do a bit more work to
do it, but it can be done. Though frankly I have no idea what that code
is supposed to do and suspect it is not really a good API if it requires
this level of variation in one function. It basically doing all
parameters handling by itself instead of using system API and this is
usually a bad sign. With or without this feature, I would seriously
consider redesigning it and making it simpler. But again, I have no clue
what this function is supposed to do. Which, BTW, is pretty bad since
apparently it is committed to main code base without having any
comments, prototypes, RFCs, documentation or anything - how one would be
supposed to make any use of it?

> Good or bad, usage of ZEND_NUM_ARGS() is all over the place:
> 
> glopes@nebm:~/php/php-src$ git grep -n ZEND_NUM_ARGS | grep -v zend_parse  
> | grep -v zend_get_parameters | wc -l
> 364

Yeah, I've fallen into this trap too initially. Most of those are
multiline calls to zend_parse_parameters and checks that are completely
harmless. There will be some cases where they aren't - like when default
parameters depend on each other like in fetchAll() - but those can be
handled. Functions like yours above are extremely rare and should be.
And if we ever get names params you'd have to rewrite it anyway so I'd
seriously consider starting to think how it would work with it then. I'd
go with "+" or "*" but that's just a guess.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Ability to assign new object to a class property.

2012-04-18 Thread Richard Lynch

On Sun, April 15, 2012 5:47 pm, Simon Schick wrote:
> Just to add a random thought 
> When do you expect this code to be executed?
>
> class Foo {
> static public $foo = new StdClass();
> }

I may be too late to this party, but...

For what it's worth, if the non-scalar initialization in class
definition were to be implemented, I, the naive PHP developer, would
expect the implementation to execute the new StdClass() exactly once
(either at compile time or on the instantiation of the first instance)
and Foo::$foo or whatever it is would be static in the sense that the
same instance of a stdClass would be shared by all Foo instances.

I'm with Stas on this one though.

Yes, it would be nifty syntactic sugar, and I used to yearn for it.

But complex initializations in the constructor is something I've grown
used to, and now appreciate as a Feature.

Trying to find all the little bits and pieces of non-scalar
initializations up and down the chain of a complex class hierarchy is
already difficult enough.

Tossing in a bunch more places it can happen is Not Good (tm).

-- 
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] skipping optional parameters

On Wed, 18 Apr 2012 22:34:23 +0200, Stas Malyshev
wrote:

Hi!

This would cause a lot of problems. Basically, all the functions that
rely
on ZEND_NUM_ARGS() will have to be changed. You can't tell if a
parameter

was passed or not by relying on it.

ZEND_NUM_ARGS() would probably work since IIRC it relies on stack size,
not on varargs return.

Not sure what you mean here. What is this "varargs return"? As far as I
see, a NULL pointer is pushed to the stack and ZEND_NUM_ARGS() will return
the size of the stack; in this case, the index of the last argument, not
the number of arguments actually passed. But even if it returned the
number of arguments passed, it would be irrelevant because you would not
know *which* arguments were passed.

Yes, that means ZEND_NUM_ARGS() and varargs would
return different things, and that means when you manually fetch args
from stack you'd have to check for NULLs - but these cases should be
quite rare and can be handled on case-by-case basis. Most functions
don't - and shouldn't - use manual stack parsing, and for those
everything would work just fine.

This is a straw man argument as I was not addressing manual stack parsing,
but, in any case, I think it reveals even a stronger argument against this
addition. There is no reason to think functions shouldn't do manual
argument parsing. In fact, they do, and there are even many ways to have
them do it -- zpp with Z*/z*/Z+/z+, _zend_get_parameters_array,
zend_get_parameters_ex and more. These are not one or two and they will
stop working,

But to my argument: many functions use ZEND_NUM_ARGS() to determine if an
argument was passed. Sometimes, this is the only way to determine if an
argument was passed -- for instance, if we're using zpp with "l", see
mt_srand() for an example. For a more drastic example, see the
implementation of PDOStatement::fetchAll().

Now, you may argue that this is a bad practice because you can't pass an
argument with a value with same effect of not passing it, and I would
agree. In fact, I've just gone through a great deal of trouble to avoid
having internal functions with this kind of behavior. See
https://github.com/cataphract/php-src/blob/intl_calendar/ext/intl/calendar/calendar_methods.cpp#L399
-- and guess what -- your feature would break this.

Good or bad, usage of ZEND_NUM_ARGS() is all over the place:

glopes@nebm:~/php/php-src$ git grep -n ZEND_NUM_ARGS | grep -v zend_parse
| grep -v zend_get_parameters | wc -l

364

(I removed its usage in zpp and similar)

the strong presumption that exists against new syntax changes. Maybe I'm
lucky, but the problem you're trying to solve is at most an occasional
minor nuisance for me. Plus, this solution encourages bad behavior. If
we

Please look at the RFC, it has links to multiple requests from users for
this feature.

I don't think this is a strong argument, I could find a number of
proponents for every crazy feature.

--
Gustavo Lopes

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] skipping optional parameters

Hi!

> "default" is already a reserved keyword. It's used in switch
> constructs. So it is safe to use :)

Ah, silly me, indeed it is. Then I guess it doesn't hurt to add it as an
option. Will do.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] skipping optional parameters

2012-04-18 Thread Nikita Popov

On Wed, Apr 18, 2012 at 10:24 PM, Stas Malyshev  wrote:
> Hi!
>
>> My one comment, which others have raised, is readability of multiple
>> commas -- TBH, at first glance it has the appearance of a mistake. I
>> think those suggesting a keyword such as "default" make a good point in
>> this regard -- it makes it 100% clear that you want the default value
>
> I wouldn't mind default but that means another keyword which means
> another disruption (default would be pretty common method name, etc.)
"default" is already a reserved keyword. It's used in switch
constructs. So it is safe to use :)

Nikita

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] skipping optional parameters

Hi!

> This would cause a lot of problems. Basically, all the functions that rely
> on ZEND_NUM_ARGS() will have to be changed. You can't tell if a parameter
> was passed or not by relying on it.

ZEND_NUM_ARGS() would probably work since IIRC it relies on stack size,
not on varargs return. Yes, that means ZEND_NUM_ARGS() and varargs would
return different things, and that means when you manually fetch args
from stack you'd have to check for NULLs - but these cases should be
quite rare and can be handled on case-by-case basis. Most functions
don't - and shouldn't - use manual stack parsing, and for those
everything would work just fine.

> the strong presumption that exists against new syntax changes. Maybe I'm
> lucky, but the problem you're trying to solve is at most an occasional
> minor nuisance for me. Plus, this solution encourages bad behavior. If we

Please look at the RFC, it has links to multiple requests from users for
this feature.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] skipping optional parameters

Hi!

> My one comment, which others have raised, is readability of multiple
> commas -- TBH, at first glance it has the appearance of a mistake. I
> think those suggesting a keyword such as "default" make a good point in
> this regard -- it makes it 100% clear that you want the default value

I wouldn't mind default but that means another keyword which means
another disruption (default would be pretty common method name, etc.)

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] skipping optional parameters


On Wed, 18 Apr 2012 00:54:41 +0200, Stas Malyshev 
wrote:


[snip]
https://wiki.php.net/rfc/skipparams

[snip]


«For internal functions, parameter parser will ignore the NULLs, thus
leaving the defaults supplied by the caller intact. Again, skipping
non-optional parameter is an error.»

This would cause a lot of problems. Basically, all the functions that rely
on ZEND_NUM_ARGS() will have to be changed. You can't tell if a parameter
was passed or not by relying on it.

For instance, if you have ZEND_NUM_ARGS() yielding x, but skipped arg x -
y, now the variable for the argument x - y won't be touched but the
function will think the argument was supplied. Segfaults and unpredictable
behavior due to uninitialized values and other logic errors will follow.

Of course, this because internal functions don't have "default values", at
least not the same way user-land functions do.

This seems a lot of trouble for a feature that, in my opinion, even if it
could be implemented without problems, won't be useful enough to overcome
the strong presumption that exists against new syntax changes. Maybe I'm
lucky, but the problem you're trying to solve is at most an occasional
minor nuisance for me. Plus, this solution encourages bad behavior. If we
want to properly support long argument lists (and I'm not we do), we have
to have named parameters.

--
Gustavo Lopes

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] skipping optional parameters

Hi!

> I'll keep going offtopic a bit more.
> I would rather see named parameters implemented *prior* to this.

I'd rather see named parameters implemented already in 5.0. But somehow
that didn't happen :) It's on my todo list though if nobody beats me to it.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: New Feature: Fully qualified class name resolution as scalar with class keyword

Hi!

> As already mentioned, There can't be a class constant called "class",
> because it is a keyword. (const class = 'Foo' is a syntax error).

It looks like class constant. So it should work like one (or, in this
case, not work since as you noticed there can not be one).

> But yes, I agree that runtime resolution only duplicates existing
> behavior, so it isn't really necessary (you could argue thought that
> self::class similarly also only replicates the existing __CLASS__). It
> would be nice for consistency in my eyes, but I'm good without it too

I do not see any "consistency" in creating functionality that is not
needed and collides with existing syntax and actually works completely
different even though it looks the same. Not much sense to have
$foo::bar and $foo::class mean completely different things. foo::bar is
static constant expression, so is foo::class, but static::class and
$foo::class won't be. It all would be very confusing. I suggest limiting
ourselves to constant expressions like foo::class, self::class and
parent::class.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] skipping optional parameters

2012-04-18 Thread Richard Lynch

On Tue, April 17, 2012 6:23 pm, Jordi Boggiano wrote:
> On 18.04.2012 00:54, Stas Malyshev wrote:
>> One of the annoying things I've encountered in working with PHP was
>> dealing with functions having long optional parameter lists,
>> especially
>> if you need to change only the last one - you have to copy all the
>> defaults. Full named params implementation would solve it, probably,
>> but
>> before we have that here's an easier solution for part of the
>> problem:
>>
>> https://wiki.php.net/rfc/skipparams
>>
>> Basically, it allows you to do this:
>>
>> create_query("deleted=0", "name",,, /*report_errors*/ true);

It might be worth mentioning in the docs edge cases like strtok.

As you all know, I presume, the optional first param restarts parsing
with a new string.  When there is only one param, it continues parsing
the previous first argument.

As silly as this may seem to you experts, newbies will probably be
confused by the optional argument syntax versus functions that change
the parameter position...

-- 
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] skipping optional parameters

2012-04-18 Thread Pierrick Charron

I like the idea. In fact I started to implement it some time ago, but your
patch is really cleaner than mine :)
Otherwise I would prefer to insert the default keyword to make the code
more readable. It might be hard to count when you have something like

function(true);

P.

On 17 April 2012 18:54, Stas Malyshev  wrote:

> Hi!
>
> One of the annoying things I've encountered in working with PHP was
> dealing with functions having long optional parameter lists, especially
> if you need to change only the last one - you have to copy all the
> defaults. Full named params implementation would solve it, probably, but
> before we have that here's an easier solution for part of the problem:
>
> https://wiki.php.net/rfc/skipparams
>
> Basically, it allows you to do this:
>
> create_query("deleted=0", "name",,, /*report_errors*/ true);
>
> Implementation of it is here:
> https://github.com/smalyshev/php-src/tree/skip_params
> All things described in RFC seem to be working, please tell me if I
> forgot anything. If it's accepted I'll also add tests, etc. of course.
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Some Stats

2012-04-18 Thread Daniel Brown

On Tue, Apr 17, 2012 at 18:13, Kris Craig  wrote:
>>
> Yeah one of the problems that really frustrates the hell out of me is that,
> after I've answered a question or responded to an objection, somebody new
> jumps in and raises the exact same issue.  When I tell them to read earlier
> in the thread for my answer, they tend to get hostile and will often just
> keep re-repeating the criticism until I finally get fed-up and just repeat
> the response I'd posted earlier.  Rinse and repeat.

If it's repeat criticism, it'll be skimmed over by the folks that
matter, trust me.  Fighting every single skirmish could well lead to
losing the campaign.

-- 

Network Infrastructure Manager
http://www.php.net/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] voting without vcs accounts

2012-04-18 Thread Ferenc Kovacs

>
>
> And I wonder why that should have more precise rules than the ones we
> use to hand out accounts. Basically every candidate I imagine could get
> a "proper" account easily, if they want.


   - we have a dedicated page for requesting vcs account
   - we also have an agreed upon, loosely defined set of requirements for
   handing out accounts (first send patches and after a few gets accepted, you
   should apply for your own account)
   - it is a public information who can approve accounts (it is well
   hidden, but public:
   
http://git.php.net/?p=web/master.git;a=blob;f=manage/users.php;h=75c5aa6bf9812b653de35c43667ef03387050437;hb=HEAD#l478
^^)
   - when an account is approved or rejected, a mail is sent to the list,
   where we can see who approved/denied/deleted the account

 if we can have the same for the non-vcs voting approval, that would be
fine with me.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] voting without vcs accounts

2012-04-18 Thread Johannes Schlüter

On Wed, 2012-04-18 at 10:23 +0200, Gustavo Lopes wrote:
> I think the issue is not who, in general terms, can vote, but how a  
> determination that someone is covered by those terms is made.
> 
> What is a "known" OSS project? For instance, which of these would
> qualify:  
> http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#PHP ?

If the vote is bound to the other project: does this mean the other
project has to decide about a "delegate"? Could the organisation revoke
that delegation or replace him? Would we therefore only work with
projects which are setup properly? (This would mean that a project
organized like PHP won't get a vote)

Right now accounts (and therefore voting rights) are handed out based on
individual contributions. And I think that's a good model to follow for
the votes.

The way I understood the rule was to be able to give regular
participants in discussions, (assuming they actually make useful
contributions ;-) ) voting karma even though they don't contribute code.
And I wonder why that should have more precise rules than the ones we
use to hand out accounts. Basically every candidate I imagine could get
a "proper" account easily, if they want.

johannes

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [RFC] skipping optional parameters

2012-04-18 Thread Matthew Weier O'Phinney

On 2012-04-17, Stas Malyshev  wrote:
> One of the annoying things I've encountered in working with PHP was
> dealing with functions having long optional parameter lists, especially
> if you need to change only the last one - you have to copy all the
> defaults. Full named params implementation would solve it, probably, but
> before we have that here's an easier solution for part of the problem:
>
> https://wiki.php.net/rfc/skipparams
>
> Basically, it allows you to do this:
>
> create_query("deleted=0", "name",,, /*report_errors*/ true);

I actually had a need for either this or named parameters this past
week, and as such would love to see one or the other in place. While I'd
personally prefer named arguments, this approach would work in most
places I've needed them.

My one comment, which others have raised, is readability of multiple
commas -- TBH, at first glance it has the appearance of a mistake. I
think those suggesting a keyword such as "default" make a good point in
this regard -- it makes it 100% clear that you want the default value
for the argument in that position. This also presents an improvement
over current usage, as you're not hard-coding values in your function
calls themselves -- particularly as the defaults could change in future
refactors.

-- 
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework  | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: New Feature: Fully qualified class name resolution as scalar with class keyword

2012-04-18 Thread Nikita Popov

On Wed, Apr 18, 2012 at 1:21 AM, Stas Malyshev  wrote:
> Hi!
>
>> Well, not that you mention it, I don't see a reason why we shouldn't
>> add run-time resolution where necessary. For once this would allow
>
> Runtime resolution of what? We already have get_class(),
> get_called_class() and __NAMESPACE__. Now, having constant expression
> for full class name might be useful since some contexts allow only
> constant expressions. But for runtime contexts we already have it. And
> there's no such thing as run-time resolution of namespaced class names.
Yes, you are right. static::class would be equivalent to
get_called_class() and $foo::class would be equivalent to
get_class($foo).

>> static::class, but also would allow $obj::class. Not sure this is
>> really necessary, but it would be more consistent :)
>
> $obj::class means "class" constant of the class whose name is given by
> string variable $obj. Probably not what you intended. And you have
> get_class() already.
As already mentioned, There can't be a class constant called "class",
because it is a keyword. (const class = 'Foo' is a syntax error).

But yes, I agree that runtime resolution only duplicates existing
behavior, so it isn't really necessary (you could argue thought that
self::class similarly also only replicates the existing __CLASS__). It
would be nice for consistency in my eyes, but I'm good without it too
:)

Nikita

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] skipping optional parameters


Daniel Macedo wrote:

I am sorry Lester, but you seem to be getting the "optional parameter"
backwards.

You are supposed to use the optional parameters when it's up to the
library/function definition to determine it's value, not when the
value is what you want for this particular function call!

What you seem to be currently reading from a function definition when
using it is i.e.: "This parameter's default is TRUE? That's what I
need it to be here, skip typing it!"
This is the wrong approach for proper design, and you will have a lot
of headaches when refactoring!

If you use them*properly*, what you read when using the function call
is "I don't need/want to change the default value for this optional
parameter, use what the library determines!", this is the proper way
to use a function call with optional parameters, that will give you a
LOT less headaches!


I'm reading things exactly has they are written ...
If I am USING a later optional parameter, then with well written libraries I 
also often need to change the earlier optional ones. Since my IDE provides an 
overview of how the defaults have been defined I can check, but I *HAVE* been 
stung by changes of a default value in the library which then messed up 
operation requiring the optional parameter to be set. Adding the ability of also 
having to check earlier optional parameters just seems adding to the agro 
without any real gain! I'm not talking about MY use of this, but is inclusion 
without thought in library code.



The problem with the way things work currently, is that the default
value, is now*hard coded*  into all function calls were you wanted to
use the default, but needed to define a latter optional parameter!

Hence the proper use would be to either use a reserved word, or having
named parameters.
I personally think there's a place for having both.


Yet another reason for wanting a LTS version of PHP that we can use without 
worrying about all these 'extras'. Named parameters have been discussed in the 
past, and not taken forward. If you NEED named parameters, simply use a 
parameter hash ... which is the normal practice for 'heavy' parameter passing 
anyway.


Similarly if I could trust the library maintainers NOT to change a default, then 
'default' might make sense, but to be honest trying to keep libraries working is 
as bad nowadays as keeping my own code working as well. I've just finished 3 
heavy days making the bulk of the bitweaver code 'strict' safe. Much of the code 
still needs extra work, but the bulk of what I USE is now clean. NOW I have to 
do the same on the libraries that it uses ... In the absence of a GOOD guide to 
'preferred practice' rewriting the bw code to include ALL the public/private 
additions will have to wait.


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] 答复: [PHP-DEV] [RFC] skipping optional parameters

2012-04-18 Thread 高春辉

+1.

I LIKE https://wiki.php.net/rfc/namedparameters , please change OLD decide.

-邮件原件-
发件人: Ferenc Kovacs [mailto:tyr...@gmail.com] 
发送时间: 2012年4月18日 15:19
收件人: Stas Malyshev
抄送: PHP Internals
主题: Re: [PHP-DEV] [RFC] skipping optional parameters

On Wed, Apr 18, 2012 at 12:54 AM, Stas Malyshev wrote:

> Hi!
>
> One of the annoying things I've encountered in working with PHP was 
> dealing with functions having long optional parameter lists, 
> especially if you need to change only the last one - you have to copy 
> all the defaults. Full named params implementation would solve it, 
> probably, but before we have that here's an easier solution for part of the 
> problem:
>
> https://wiki.php.net/rfc/skipparams
>
> Basically, it allows you to do this:
>
> create_query("deleted=0", "name",,, /*report_errors*/ true);
>
> Implementation of it is here:
> https://github.com/smalyshev/php-src/tree/skip_params
> All things described in RFC seem to be working, please tell me if I 
> forgot anything. If it's accepted I'll also add tests, etc. of course.
>
>
I would prefer Named parameters, but this is still better than the current 
situation.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] skipping optional parameters

2012-04-18 Thread Daniel Macedo

I am sorry Lester, but you seem to be getting the "optional parameter"
backwards.

You are supposed to use the optional parameters when it's up to the
library/function definition to determine it's value, not when the
value is what you want for this particular function call!

What you seem to be currently reading from a function definition when
using it is i.e.: "This parameter's default is TRUE? That's what I
need it to be here, skip typing it!"
This is the wrong approach for proper design, and you will have a lot
of headaches when refactoring!

If you use them *properly*, what you read when using the function call
is "I don't need/want to change the default value for this optional
parameter, use what the library determines!", this is the proper way
to use a function call with optional parameters, that will give you a
LOT less headaches!

The problem with the way things work currently, is that the default
value, is now *hard coded* into all function calls were you wanted to
use the default, but needed to define a latter optional parameter!

Hence the proper use would be to either use a reserved word, or having
named parameters.
I personally think there's a place for having both.

> Daniel Macedo wrote:
>>
>> function fn1($a = false, $b = nul, $c = 1)
>> {
>>   var_dump($a, $b. $c);
>> }
>>
>> // your idea
>> fn1(NULL, NULL, 10), // NULL, NULL, 10
>>
>> // vs. using a reserved word
>> fn1(default, default, 10), // FALSE, NULL, 10
>
>
> Of cause one little problem here is if the default gets changed in the
> 'library' then every use of 'default' would need to be checked.
> Of cause the same problem applies with changing defaults that are used by
> leaving out the latter parameters on the list, but this just adds another
> area that needs cross checking. Always including the parameters needed is
> the safe way in many cases anyway! So leaving them off can be bad practice
> anyway?
>
>
> --
> Lester Caine - G8HFL
> -
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk//
> Firebird - http://www.firebirdsql.org/index.php
>
> --
> 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] [RFC] skipping optional parameters

2012-04-18 Thread Stefan Neufeind

On 04/18/2012 01:05 PM, Arvids Godjuks wrote:
> I personally would vote for the "default" keyword if I want to skip the
> param rather than just doing it with , - the keyword approach is much more
> readable and error prone.

I also agree that the "comma-train" (multiple commas without anything
inbetween) might be too confusing and that using a default-keyword
(whatever it might be) might imho be an option.

Regards,
 Stefan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] skipping optional parameters

2012-04-18 Thread Arvids Godjuks

I personally would vote for the "default" keyword if I want to skip the
param rather than just doing it with , - the keyword approach is much more
readable and error prone.

Re: [PHP-DEV] [RFC] skipping optional parameters


Daniel Macedo wrote:

function fn1($a = false, $b = nul, $c = 1)
{
   var_dump($a, $b. $c);
}

// your idea
fn1(NULL, NULL, 10), // NULL, NULL, 10

// vs. using a reserved word
fn1(default, default, 10), // FALSE, NULL, 10


Of cause one little problem here is if the default gets changed in the 'library' 
then every use of 'default' would need to be checked.
Of cause the same problem applies with changing defaults that are used by 
leaving out the latter parameters on the list, but this just adds another area 
that needs cross checking. Always including the parameters needed is the safe 
way in many cases anyway! So leaving them off can be bad practice anyway?


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] skipping optional parameters

2012-04-18 Thread Peter Cowburn

On 18 April 2012 11:38, Daniel Macedo  wrote:

> You can't do that, NULL is a perfectly acceptable value to pass into a
> function, you wouldn't be able to know when you wanted to pass NULL or
> use the default value, e.g.:
>
>
You totally missed the point: hinting, not-so-subtly, at the
long-established convention to use null as the default value. I guess my
humour doesn't come across so well on the list.  Lets get back to
discussing ",,," parameters.

Re: [PHP-DEV] HEADS UP: Force pushed to revert to d55afe4df63945a6e3abe9892ba7836f83c74265

2012-04-18 Thread Johannes Schlüter

On Wed, 2012-04-18 at 12:35 +0200, Johannes Schlüter wrote:
> Hi,
> 
> the master branch was accidentally merged into the 5.4 branch. I
> reverted that by force pushing the old revision
> d55afe4df63945a6e3abe9892ba7836f83c74265 into PHP-5.4 and then
> cherry-picking all revisions since then. Please take a look and
> double-check that nothing was lost.

I've pushed the "messed" branch to
https://github.com/johannes/php-src/tree/php-5.4-messup in case somebody
wants to verify something.

johannes



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] skipping optional parameters

2012-04-18 Thread Daniel Macedo

You can't do that, NULL is a perfectly acceptable value to pass into a
function, you wouldn't be able to know when you wanted to pass NULL or
use the default value, e.g.:

function fn1($a = false, $b = nul, $c = 1)
{
  var_dump($a, $b. $c);
}

// your idea
fn1(NULL, NULL, 10), // NULL, NULL, 10

// vs. using a reserved word
fn1(default, default, 10), // FALSE, NULL, 10

Cheers,


On Wed, Apr 18, 2012 at 11:21, Peter Cowburn  wrote:
> On 18 April 2012 10:25, Daniel Macedo  wrote:
>>
>> But I couldn't support the comma train, for the insane «lots of
>> parameters» case, would hate to read some fn($some $var,,, $other)
>> call.
>> I'd rather reuse a reserved word like 'default' (or even get a shorter
>> one?)
>>
>
> How about "null"? (Tongue firmly in cheek)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] HEADS UP: Force pushed to revert to d55afe4df63945a6e3abe9892ba7836f83c74265

2012-04-18 Thread Johannes Schlüter

Hi,

the master branch was accidentally merged into the 5.4 branch. I
reverted that by force pushing the old revision
d55afe4df63945a6e3abe9892ba7836f83c74265 into PHP-5.4 and then
cherry-picking all revisions since then. Please take a look and
double-check that nothing was lost.

If you pulled within the last few minutes please make sure that you do
not have the revision 885e57517ad6057b497b2c90482ddb2d58ac1a2b and don't
push that revision to the repository.

johannes


Changes reapplied:

commit 0618e33b5dbac73efc0893884051b5c24e7ab409
Merge: d6394e6 da6465a
Author: Johannes Schlüter 
Date:   Wed Apr 18 12:22:27 2012 +0200

Merge branch 'PHP-5.4' of git.php.net:/php-src into PHP-5.4

* 'PHP-5.4' of git.php.net:/php-src:
  Fixed bug #61761 ('Overriding' a private static method with a
different signature causes crash)

commit d6394e66a31e788560e664d6823d30b2e759d7cb
Author: Yasuo Ohgaki 
Date:   Tue Apr 17 16:34:47 2012 +0900

Add NEWS

commit cce0f8e507c05ecc7c8222efa5005991f04ce4c0
Author: Yasuo Ohgaki 
Date:   Fri Mar 30 09:45:33 2012 +0900

Implement Request #47570libpq's PG_VERSION should be exported to
userland

commit da6465a268d9ece2ffd38447890b206dd94b3250
Author: Xinchen Hui 
Date:   Wed Apr 18 18:13:27 2012 +0800

Fixed bug #61761 ('Overriding' a private static method with a
different signature causes crash)

commit d55afe4df63945a6e3abe9892ba7836f83c74265
Merge: 3d106ae f3d86b3
Author: Anatoliy Belsky 
Date:   Mon Apr 16 17:07:33 2012 +0200

Merge branch 'PHP-5.3' into PHP-5.4

* PHP-5.3:
  Fix bug 61746 Failing tests in
ext/standard/tests/file/windows_links/*



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] skipping optional parameters

2012-04-18 Thread Peter Cowburn

On 18 April 2012 10:25, Daniel Macedo  wrote:

> But I couldn't support the comma train, for the insane «lots of
> parameters» case, would hate to read some fn($some $var,,, $other)
> call.
> I'd rather reuse a reserved word like 'default' (or even get a shorter
> one?)
>
>
How about "null"? (Tongue firmly in cheek)

Re: [PHP-DEV] [RFC] skipping optional parameters


Adam Jon Richardson wrote:

I disagree with the suggestion that the "real" solution is to refactor
functions. Is a function with 3 parameters too long?

function foo($val1, $val2 = true, $val3 = false) { /* code */}

If I want to pass in a value to the third argument but keep the default
value for the second argument, I have to look up what the default is and
then paste/type it in as the second argument.


OK we are back in the debate on what needs to be IN the runtime handling ...
Eclipse gives be a pop-up with the parameter set so I know what is expected. I 
don't even need to go and 'lookup' anything.


Where the parameter chain is more than a couple of entries, then use a parameter 
hash. Always a lot easier anyway when handling SQL type activities as one can 
add stuff later and the order is irrelevant anyway.


When one uses the right support tools is this really something to be wasting 
even more time on?


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] skipping optional parameters

2012-04-18 Thread Daniel Macedo

I'll keep going offtopic a bit more.
I would rather see named parameters implemented *prior* to this.
Although maybe not instead, I think both might have their place.

On Wed, Apr 18, 2012 at 08:43, Yasuo Ohgaki  wrote:
>
> Something like
>
> setcookie( name:'mycookie', value:'abc', secure:true, httponly:true );
>
> is really nice to have. Source code will be much more readable.
>

I agree with this! But for short array syntax we kept the => as in
$array = ["foo" => "bar"];
Not sure if this was a limitation, lack of that suggestion or a
decision; but the shortest syntax it's still not... (as Yoda would
say!)

$array = ["foo": "bar"]; doesn't look weird to me, plenty readable,
and that's the shortest!

> This is getting off-topic, but while we're here, I think:
>
> setcookie($name => 'mycookie', $value => 'abc');

Not sure what the optimal PHP syntax should be for named parameters,
but I think this isn't it.

Back to the topic at hand.
There doesn't need to be a lot of parameters on a function for this to
be useful, even with IDE assistance.

For a proper refactoring, where you'd only needing to change the
function definition. In calls where the optional parameters would call
a 'default', they should in fact be the default. Where as now we'd
have to go through all the function calls for any case where we
statically used the default and change it to the new default...

But I couldn't support the comma train, for the insane «lots of
parameters» case, would hate to read some fn($some $var,,, $other)
call.
I'd rather reuse a reserved word like 'default' (or even get a shorter one?)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] skipping optional parameters

2012-04-18 Thread Christian Kaps


Am 18.04.2012 09:18, schrieb Ferenc Kovacs:

On Wed, Apr 18, 2012 at 12:54 AM, Stas Malyshev
wrote:


Hi!

One of the annoying things I've encountered in working with PHP was
dealing with functions having long optional parameter lists, 
especially

if you need to change only the last one - you have to copy all the
defaults. Full named params implementation would solve it, probably, 
but
before we have that here's an easier solution for part of the 
problem:


https://wiki.php.net/rfc/skipparams

Basically, it allows you to do this:

create_query("deleted=0", "name",,, /*report_errors*/ true);

Implementation of it is here:
https://github.com/smalyshev/php-src/tree/skip_params
All things described in RFC seem to be working, please tell me if I
forgot anything. If it's accepted I'll also add tests, etc. of 
course.



I would prefer Named parameters, but this is still better than the 
current

situation.


Every time a new language construct is proposed, the first arguments 
against are:

- This is confusing syntax
- It is hard to read
- And so one

Stas, and I think you are one of the core developers which raises his 
voice as first, against new language constructs. And now you propose 
such a construct. But the best is you show the optimal solution(named 
parameters) for this problem in your post, and suggests this proposal as 
work around for it. So if this proposal gets implemented and maybe in 
the future named parameters gets also implemented. Have we then two 
solutions for this problem. Or does we revert your current proposal.


Sorry, its not against you but for me it seems more as a quick shot.

Just my 2 cents
Christian

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] skipping optional parameters

2012-04-18 Thread Pierre Joye

hi Stas,



On Wed, Apr 18, 2012 at 12:54 AM, Stas Malyshev  wrote:

> create_query("deleted=0", "name",,, /*report_errors*/ true);

I like the concept, a lot :)

Indeed there is the "code written for only this version and above",
from a syntax point of view. But that's something I do not care much
about.

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] [off] PHP: a fractal of bad design

2012-04-18 Thread Philip Olson

On Apr 18, 2012, at 1:34 AM, Hartmut Holzgraefe wrote:

> On 04/10/2012 06:20 PM, Adir Kuhn wrote:
>> Hi folks,
>> 
>> today I read this post, I think that some points are valid, follow the link 
>> for
>> you guys
> 
> as stuff like this comes up again and again (although not in as epic
> lenght as this one) i've been thinking whether it might make sense to
> have some
> 
> "PHP Gotchas, how they came to be, and why we can't simply fix them"
> 
> FAQ section in the manual or wiki?
> 
> If nothing else it would at least help with dealing with this kind
> of rant (nothing new here, move along, your concerns were already
> covered in ### in great detail), but also might help that would
> indeed want to understand why some things are as they are.
> 
> I'd rather proactively own this kind of discussions than just
> jump into them whenever they arise elsewhere …

Hello Hartmut,

Agreed, and I think it belongs in the manual. An example (not being
proposed as such, but is a rough idea):

  Why are function naming schemes seemingly random?

PHP glues many different API's together, and sometimes this
gets messy. PHP leans towards the C variant which is why the
likes of strlen() vs str_replace() exists, and …

As opposed to our current approach, which is via mailing lists and 
typically "RTFM." or "BC. Read archives." or the like. Ack!

And also include possible solutions/recommendations like this PHP FAQ
entry about haystack,needle ordering, which includes the following 
text:

A simple rule of thumb is as follows: Array function parameters 
are ordered as "needle, haystack" whereas String functions are the 
opposite, so "haystack, needle".

And thankfully there are already a lot of sites to steal the questions 
from, and often answers live within their user comments. :)

Regards,
Philip

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [off] PHP: a fractal of bad design

2012-04-18 Thread Hartmut Holzgraefe

On 04/11/2012 05:19 PM, Luke Scott wrote:

> The only thing that infuriates me is the ternary operator being left
> associative. I want that fixed - screw bc on that one! I have been
> programming for 10 years and that one still confuses me! Most people
> just add parentheses to "fix" the problem. I wish someone would write
> an RFC to change this to right associative like every other language!
> *hint hint*

i actually never noticed this until now as i keep it as a best practice
to never nest ternaries anyway, in any language. To me it's at least as
much a sign for a desseased mind as using multiple exclamation marks
!!!11eleven ;)

The problem i see though is that in code that really relies on this it
may become a real nightmare to track down what goes wrong if evaluation
order is changed if you're not aware of that change having happened.

An E_DEPRECATED may help here, but will also produce a lot of false
positives for those using parentheses? Or can we add enough parser
magic to only throw warnings for the unsafe uses? ...

-- 
hartmut

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [off] PHP: a fractal of bad design

2012-04-18 Thread Hartmut Holzgraefe

On 04/10/2012 06:20 PM, Adir Kuhn wrote:
> Hi folks,
> 
> today I read this post, I think that some points are valid, follow the link 
> for
> you guys

as stuff like this comes up again and again (although not in as epic
lenght as this one) i've been thinking whether it might make sense to
have some

 "PHP Gotchas, how they came to be, and why we can't simply fix them"

FAQ section in the manual or wiki?

If nothing else it would at least help with dealing with this kind
of rant (nothing new here, move along, your concerns were already
covered in ### in great detail), but also might help that would
indeed want to understand why some things are as they are.

I'd rather proactively own this kind of discussions than just
jump into them whenever they arise elsewhere ...

-- 
hartmut

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] skipping optional parameters

2012-04-18 Thread Adam Jon Richardson

On Wed, Apr 18, 2012 at 1:56 AM, Alexey Shein  wrote:

> Hi!
>
> My opinion is that solution tries to overcome bad consequences of
> legacy code, when it's not feasible to change something without
> breakage a lot of code, although the real solution is to refactor
> functions with long variable lists (as Uncle Bob says), maybe this
> should be noted in documentation of this feature.
>

I disagree with the suggestion that the "real" solution is to refactor
functions. Is a function with 3 parameters too long?

function foo($val1, $val2 = true, $val3 = false) { /* code */}

If I want to pass in a value to the third argument but keep the default
value for the second argument, I have to look up what the default is and
then paste/type it in as the second argument.

Being able to just call foo($val1 = "something", , $val3 = true) lets me
set a specific value for the 3rd argument without having to do any hunting
down of the 2nd default value or copying/pasting/typing in the argument.

>From my perspective, this solution is more about maintaining defaults and
improving developer experience than about problems with legacy code, and it
holds value for any function that has more than one default value.

Adam

Re: [PHP-DEV] [RFC] skipping optional parameters

2012-04-18 Thread Yasuo Ohgaki

Hi,

2012/4/18 Ryan McCue :
> Yasuo Ohgaki wrote:
>>
>> Something like
>>
>> setcookie( name:'mycookie', value:'abc', secure:true, httponly:true );
>>
>> is really nice to have. Source code will be much more readable.
>
>
> This is getting off-topic, but while we're here, I think:
>
> setcookie($name => 'mycookie', $value => 'abc');
>
> ...would be better.

Real life code would be something like

setcookie($name => $my_cookie_name, $value => $value);

It's confusing.
Off topic anyway.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] voting without vcs accounts

On Wed, 18 Apr 2012 07:34:06 +0200, Pierre Joye   
wrote:


On Wed, Apr 18, 2012 at 12:50 AM, Stas Malyshev   
wrote:



I have a problem that we don't have understanding of what is the goal of
this whole vote setup. What is it for? What we will be doing with it?
And please don't say "it says so in RFC" - it is not a goal.


Let me clarify that and try to do not go backwards while we have
finally moved forward.

The goal is to have community leader participating in our design
discussions and decisions. It has happened already for a couple of
RFCs (accepted and rejected) and went very well. The FUDs about core
devs, legacy developers and the like loosing control about the
direction PHP takes has been killed, it did not happen and it is very
unlikely that it will happen.

How do the community leaders come in? They are usually very well known
and already participate to php in one way or another (bugs report,
testing, etc.) and are part of a known OSS project (we have drupal,
zf, symfony already for example). Having a couple of devs to second
their addition is also requested.

This has been said many times already in the past and it is said in
the RFC as well. We do not need over killed process as an attempt to
make php more closed to our communities.



I think the issue is not who, in general terms, can vote, but how a  
determination that someone is covered by those terms is made.


What is a "known" OSS project? For instance, which of these would qualify:  
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#PHP ?


Of course, it's impossible to set a clear line on what is a "known"  
project. Which leads to arbitrariness. Which leads to the second question  
-- who approves those voting rights? It's been said in this thread that  
any wiki admin can approve an account without saying anything. Is this  
case? Who was approved, by whom, and who "seconded the addition" of these  
accounts? Personally, I don't know.


These are, in my opinion, legitimate concerns that should not be dismissed  
(and "has been said in the past" and allusions to obviousness or lack of  
problems so far are not appropriate responses).


--
Gustavo Lopes

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] skipping optional parameters

2012-04-18 Thread Michael Wallner

On 18 April 2012 01:23, Jordi Boggiano  wrote:
> On 18.04.2012 00:54, Stas Malyshev wrote:

>> https://wiki.php.net/rfc/skipparams
>>
>> Basically, it allows you to do this:
>>
>> create_query("deleted=0", "name",,, /*report_errors*/ true);

+1


> - Would it be possible to allow trailing commas in combination to this?
> i.e. foo("arg",) would just call foo with "arg" and then the default
> value for the second arg if there is one, or just nothing. That would
> make multi-line function calls a bit cleaner, and more similar to arrays.

Yet another +1!

-- 
Regards,
Mike

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] voting without vcs accounts


Pierre Joye wrote:

I am ignoring the comment about FUDs because I have no idea what it is
>  about, so I guess you are answering somebody other's comment that I have
>  not read.

It was not for you directly but the voting opponent (the very few we
have) who cannot get over it. However you are right, they can be
ignored (for their opinion about voting :).


I guess that covers me :(

--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] skipping optional parameters

2012-04-18 Thread Ryan McCue


Yasuo Ohgaki wrote:

Something like

setcookie( name:'mycookie', value:'abc', secure:true, httponly:true );

is really nice to have. Source code will be much more readable.


This is getting off-topic, but while we're here, I think:

setcookie($name => 'mycookie', $value => 'abc');

...would be better.

--
Ryan McCue


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] skipping optional parameters

2012-04-18 Thread Yasuo Ohgaki

Hi,

2012/4/18 Ferenc Kovacs :
> I would prefer Named parameters, but this is still better than the current
> situation.

Something like

setcookie( name:'mycookie', value:'abc', secure:true, httponly:true );

is really nice to have. Source code will be much more readable.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] skipping optional parameters

2012-04-18 Thread Ferenc Kovacs

On Wed, Apr 18, 2012 at 12:54 AM, Stas Malyshev wrote:

> Hi!
>
> One of the annoying things I've encountered in working with PHP was
> dealing with functions having long optional parameter lists, especially
> if you need to change only the last one - you have to copy all the
> defaults. Full named params implementation would solve it, probably, but
> before we have that here's an easier solution for part of the problem:
>
> https://wiki.php.net/rfc/skipparams
>
> Basically, it allows you to do this:
>
> create_query("deleted=0", "name",,, /*report_errors*/ true);
>
> Implementation of it is here:
> https://github.com/smalyshev/php-src/tree/skip_params
> All things described in RFC seem to be working, please tell me if I
> forgot anything. If it's accepted I'll also add tests, etc. of course.
>
>
I would prefer Named parameters, but this is still better than the current
situation.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] [RFC] skipping optional parameters

2012-04-18 Thread Adam Harvey

On 18 April 2012 06:54, Stas Malyshev  wrote:
> create_query("deleted=0", "name",,, /*report_errors*/ true);

I like it. At the risk of bikeshedding, can we have a token rather
than just a series of commas — say reusing the default keyword so it
would look like this instead:

create_query("deleted=0", "name", default, default, /*report_errors*/ true);

That seems easier to read to my eyes than counting commas.

Thanks,

Adam

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] voting without vcs accounts

2012-04-18 Thread Pierre Joye

hi Stas,

On Wed, Apr 18, 2012 at 8:58 AM, Stas Malyshev  wrote:
> Hi!
>
>> The goal is to have community leader participating in our design
>> discussions and decisions. It has happened already for a couple of
>> RFCs (accepted and rejected) and went very well. The FUDs about core
>> devs, legacy developers and the like loosing control about the
>> direction PHP takes has been killed, it did not happen and it is very
>> unlikely that it will happen.
>
> Excellent. So we have people participating, contributing to RFCs,
> getting features accepted, etc. So what's the problem that needs fixing?

Nothing right now, everything works as it should so far. We may do a
review in a year, or half a year. But as of now we are on track and
everything seems to run well.

> I am ignoring the comment about FUDs because I have no idea what it is
> about, so I guess you are answering somebody other's comment that I have
> not read.

It was not for you directly but the voting opponent (the very few we
have) who cannot get over it. However you are right, they can be
ignored (for their opinion about voting :).

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] voting without vcs accounts