> On 04/10/2012 06:20 PM, Adir Kuhn wrote:
>
> "PHP Gotchas, how they came to be, and why we can't simply fix them"
>
can't or won't?
It seems that the requirement for backward compatibility, as with most
software, stands in the way of any substantial leaps, and makes it
impossible to do away wi
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 ] )
$
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
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 Interna
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
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
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 wo
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 cl
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 sin
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
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 -
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, th
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 wou
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 woul
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 Archit
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
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 hav
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
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 threa
>
>
> 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 defin
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.o
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 woul
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 __NAMESP
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!
+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 Mal
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 cur
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
inb
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.
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 'l
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-estab
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. Pleas
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
//
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 wit
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"? (T
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
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, ht
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 hav
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
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
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.
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 so
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 lis
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($na
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
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
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 ri
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 be
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 Ohgak
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
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=
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
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
52 matches
Mail list logo
