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

18 апреля 2012 г. 11:40 пользователь Stas Malyshev написал: > Hi! > >> NULL or empty string? I.e. will optional parameters always get NULLs >> or their default values? > > Their default values. That's the whole point of it - if I wanted just > nulls, I could put nulls in the call, but if I want th

Re: [PHP-DEV] Variable-length args by reference

On 04/18/2012 12:31 AM, Yasuo Ohgaki wrote: > Hi, > > 2012/4/18 Stefan Neufeind : >> On 04/18/2012 12:02 AM, Stefan Neufeind wrote: >>> Hi, >>> >>> the topic of variable argument-lists for functions in connection with >>> getting the parameters by reference came up. This is currently not >>> possi

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

Hi! > NULL or empty string? I.e. will optional parameters always get NULLs > or their default values? Their default values. That's the whole point of it - if I wanted just nulls, I could put nulls in the call, but if I want the actual default, I'd have to find the definition and copy-paste from t

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

On 18 April 2012 07:56, Alexey Shein wrote: *snip* > > One question about implementation: > Given we have this function >>   function create_query($where, $order_by, $join_type='', $execute = false, >> $report_errors = true) {} > and this statement >> On the engine level, it will be implemented

Re: [PHP-DEV] Re: Release day, was: release process with git

hi Stas, On Tue, Apr 17, 2012 at 10:19 PM, Stas Malyshev wrote: >> So if we want to release Thursday, then windows builds need to be done one >> Wednesday. > > OK, I can tag on Tuesday instead, will it make things better? Let's try > it with 5.4.1. It is important to keep in mind (we did not fo

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

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 documentatio

Re: [PHP-DEV] voting without vcs accounts

On Wed, Apr 18, 2012 at 7:37 AM, Pierre Joye wrote: > hi, > > On Wed, Apr 18, 2012 at 1:29 AM, Philip Olson wrote: > >>  1. Those with SVN [sic] access (but how does karma come into play?) > > It does, or we begin to have 2nd, 3rd and totally irrelevant classes > of developers or doc writers. A

Re: [PHP-DEV] voting without vcs accounts

hi, On Wed, Apr 18, 2012 at 1:29 AM, Philip Olson wrote: >  1. Those with SVN [sic] access (but how does karma come into play?) It does, or we begin to have 2nd, 3rd and totally irrelevant classes of developers or doc writers. >  2. Those without (how do we provide such rights? to whom?) See

Re: [PHP-DEV] voting without vcs accounts

hi Stas, 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 a

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

On Tue, Apr 17, 2012 at 6:54 PM, 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

Re: [PHP-DEV] Some Stats

On Tue, Apr 17, 2012 at 7:30 PM, Sherif Ramadan wrote: > > On 04/17/2012 11:41 AM, Kris Craig wrote: > >> > >> > >> On Mon, Apr 16, 2012 at 11:57 PM, Rasmus Lerdorf >> > wrote: > >> > >> Number of posts to internals since Jan.1,2012 (top 15): > >> > >> [kris.cr.

Re: [PHP-DEV] Some Stats

> On 04/17/2012 11:41 AM, Kris Craig wrote: >> >> >> On Mon, Apr 16, 2012 at 11:57 PM, Rasmus Lerdorf > > wrote: >> >>     Number of posts to internals since Jan.1,2012 (top 15): >> >>     [kris.cr...@gmail.com ]        => 249 >> >> >> Wooot!

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

Hi! > a) it kind of encourages using long lists of arguments (which is not > normally regarded as good practice) This ship has sailed long ago, these lists are the reality. And rewriting all the code to change all function calls is in most cases completely infeasible. > c) the current situation

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

On Wednesday, April 18, 2012 06:54 AM, Stas Malyshev wrote: Hi! 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

Re: [PHP-DEV] PHP Dependencies

On 18 April 2012 06:40, Kris Craig wrote: > Forgive me if this has been addressed before, but I was wondering:  Have we > ever considered maintaining an RPM for PHP dependencies for each version > branch?  The are legitimate reasons why people prefer to build PHP manually > instead of building fro

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

Hi, 2012/4/18 Stas Malyshev : > Hi! > >> Since func_num_args() won't be able to be used to see if an argument is set, >> could a func_isset_arg() be added? So something like: >> if(func_num_args() > 2) $value = func_get_arg(2); >> would become: >> if(func_isset_arg(2)) $value = func_get_arg(2); >

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

Hi! >> BTW: the diffs show a lot of WS changes that you should probably fix. That's Eclipse, it loves to strip trailing whitespace... Which btw shows for some reason we have lots of it in our code. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 22

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

On Wed, Apr 18, 2012 at 2:03 AM, Etienne Kneuss wrote: > Hi, > > > On Wed, Apr 18, 2012 at 01:56, Stas Malyshev wrote: >> Hi! >> >>> Since func_num_args() won't be able to be used to see if an argument is >>> set, could a func_isset_arg() be added? So something like: >>> if(func_num_args() > 2)

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

Hi, On Wed, Apr 18, 2012 at 01:56, Stas Malyshev wrote: > Hi! > >> Since func_num_args() won't be able to be used to see if an argument is set, >> could a func_isset_arg() be added? So something like: >> if(func_num_args() > 2) $value = func_get_arg(2); >> would become: >> if(func_isset_arg(2))

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

Hi! > Since func_num_args() won't be able to be used to see if an argument is set, > could a func_isset_arg() be added? So something like: > if(func_num_args() > 2) $value = func_get_arg(2); > would become: > if(func_isset_arg(2)) $value = func_get_arg(2); I think it's easier to just do func_get

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

Hi, 2012/4/18 Simon J Welsh : > On 18/04/2012, at 10: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 co

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

Hi! > I'm thinking undefined like JavaScript. Well, in PHP null is closest, but a bit different. I.e. in JS undefined a is an error, but a[0] where a is empty is "undefined". In PHP in both cases you get null and notice, and in both cases you can use isset/empty to check for it. -- Stanislav Mal

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

On 18/04/2012, at 10: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 para

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

Hi, It's undefined, so it does not have to keep track state ;) But it may require a lot of changes, so I don't matter much. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net 2012/4/18 Yasuo Ohgaki : > Hi, > > 2012/4/18 Stas Malyshev : >> Hi! >> >>> Introducing "undefined" might be good. >>> Intenti

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

Hi, 2012/4/18 Stas Malyshev : > Hi! > >> Introducing "undefined" might be good. >> Intention becomes clearer and we may do >> >> if ($var === undefined) { >>   echo '$var is undefined'; >> } > > What is undefined and how $var gets assigned it? I'm thinking undefined like JavaScript. AFAIK, engin

Re: [PHP-DEV] voting without vcs accounts

On Apr 17, 2012, at 4:08 PM, Christopher Jones wrote: > > > On 04/17/2012 03:50 PM, Stas Malyshev wrote: >> Hi! >> >>> sorry, I can't really follow you with that. >>> do you have a problem allowing the non-vcs users (defined by the voting >>> rfc) to vote, or do you have a problem providing a

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

Hi! > Introducing "undefined" might be good. > Intention becomes clearer and we may do > > if ($var === undefined) { > echo '$var is undefined'; > } What is undefined and how $var gets assigned it? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext

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

Hi, 2012/4/18 Stas Malyshev : > 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 wo

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

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

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

Stas Malyshev wrote: Basically, it allows you to do this: create_query("deleted=0", "name",,, /*report_errors*/ true); I'm a huge fan of this idea, for all the reasons listed on the RFC and one additional one: it brings normal functions in line with the syntax for list() - We can skip param

Re: [PHP-DEV] voting without vcs accounts

On 04/17/2012 03:50 PM, Stas Malyshev wrote: Hi! sorry, I can't really follow you with that. do you have a problem allowing the non-vcs users (defined by the voting rfc) to vote, or do you have a problem providing a clear way for them to get their voting karma? I have a problem that we don'

Re: [PHP-DEV] Some Stats

On Tue, Apr 17, 2012 at 3:42 PM, Sean Coates wrote: > My response earlier was meant to be funny, mostly, but I did also intend > to convey some of the same things Rasmus said. The only person who wants to > participate in a conversation where someone is hogging the floor is the > person doing the

[PHP-DEV] [RFC] skipping optional parameters

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

Re: [PHP-DEV] voting without vcs accounts

Hi! > sorry, I can't really follow you with that. > do you have a problem allowing the non-vcs users (defined by the voting > rfc) to vote, or do you have a problem providing a clear way for them to > get their voting karma? I have a problem that we don't have understanding of what is the goal of

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

Hi! > I tend to agree. __CLASS__ to me belongs to the family of constants > like __DIR__ and __FILE__ where they are meant to be evaluated in-place > and are simply a substitution for something completely static. But that's exactly what Foo::class is - completely static constant. > In my mind

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

Hi! > Fantastic question. I am unsure how to handle this. Currently, it will > simply resolve those names against the rules (I am sure this is the > wrong behavior.) So, > > namespace Foo\Bar { var_dump(self::class); } This should produce an error outside of class context, I think. Insi

Re: [PHP-DEV] Some Stats

My response earlier was meant to be funny, mostly, but I did also intend to convey some of the same things Rasmus said. The only person who wants to participate in a conversation where someone is hogging the floor is the person doing the talking. > Yeah one of the problems that really frustrate

Re: [PHP-DEV] Variable-length args by reference

On Wed, 2012-04-18 at 00:02 +0200, Stefan Neufeind wrote: > How would you think about extending func_get_args() and func_get_arg() > to allow for: > > $args = func_get_args(FUNC_GET_ARGS_BY_REFERENCE); > $arg0 = func_get_arg (0, FUNC_GET_ARGS_BY_REFERENCE); > > (default would be FUNC_

[PHP-DEV] PHP Dependencies

Hey guys, Forgive me if this has been addressed before, but I was wondering: Have we ever considered maintaining an RPM for PHP dependencies for each version branch? The are legitimate reasons why people prefer to build PHP manually instead of building from a repo, but those reasons often don't

Re: [PHP-DEV] Variable-length args by reference

Hi, 2012/4/18 Stefan Neufeind : > On 04/18/2012 12:02 AM, Stefan Neufeind wrote: >> Hi, >> >> the topic of variable argument-lists for functions in connection with >> getting the parameters by reference came up. This is currently not >> possible with func_get_args(), though a "hack" with debug_bac

Re: [PHP-DEV] Some Stats

On Tue, Apr 17, 2012 at 2:42 PM, Gustavo Lopes wrote: > On Tue, 17 Apr 2012 23:23:35 +0200, Tjerk Meesters > wrote: > > Maybe this has been suggested before, but it would be nice if comments >> in, ahem, request for comments could be consolidated into one spot, the RFC >> page itself. Facebook c

Re: [PHP-DEV] Variable-length args by reference

On 04/18/2012 12:02 AM, Stefan Neufeind wrote: > Hi, > > the topic of variable argument-lists for functions in connection with > getting the parameters by reference came up. This is currently not > possible with func_get_args(), though a "hack" with debug_backtrace() is > possible. > > How would

[PHP-DEV] Variable-length args by reference

Hi, the topic of variable argument-lists for functions in connection with getting the parameters by reference came up. This is currently not possible with func_get_args(), though a "hack" with debug_backtrace() is possible. How would you think about extending func_get_args() and func_get_arg() to

Re: [PHP-DEV] voting without vcs accounts

On Tue, Apr 17, 2012 at 11:48 PM, Stas Malyshev wrote: > Hi! > > > http://www.mail-archive.com/internals@lists.php.net/msg51948.html > > Pierre said that it was a bug(better to say lack of restriction), that > > everybody with wiki account was able to vote, so I changed the voting > > plugin to on

Re: [PHP-DEV] voting without vcs accounts

Hi! > http://www.mail-archive.com/internals@lists.php.net/msg51948.html > Pierre said that it was a bug(better to say lack of restriction), that > everybody with wiki account was able to vote, so I changed the voting > plugin to only allow the specific groups(vcs + voting) to be able to vote. Thi

Re: [PHP-DEV] Some Stats

On Tue, 17 Apr 2012 23:23:35 +0200, Tjerk Meesters wrote: Maybe this has been suggested before, but it would be nice if comments in, ahem, request for comments could be consolidated into one spot, the RFC page itself. Facebook comments come to mind, though I'm sure there are other solution

Re: [PHP-DEV] is_numeric_string an hexadecimal numbers ("123" == "0x7B")

2012/4/17 Simon Schick > > Hi, Gustavo > > That's something I didn't know of ... if we're doing that, it should, > of course, be also be done for the dual system. > The only thing I wonder about is the code examples you're giving ... > > I would expect this to work if we start to change something

Re: [PHP-DEV] Some Stats

Maybe this has been suggested before, but it would be nice if comments in, ahem, request for comments could be consolidated into one spot, the RFC page itself. Facebook comments come to mind, though I'm sure there are other solutions based on OpenID, etc. Sent from my iPhone On 18 Apr, 2012,

Re: [PHP-DEV] Some Stats

The author of an RFC does need to respond to concerns raised (although possibly not the same concerns over and over). On Tue, Apr 17, 2012 at 3:46 PM, Rasmus Lerdorf wrote: > On 04/17/2012 11:41 AM, Kris Craig wrote: >> >> >> On Mon, Apr 16, 2012 at 11:57 PM, Rasmus Lerdorf >

Re: [PHP-DEV] Re: Release day, was: release process with git

Hi! > Stas tags Wednesday evening US Pacific time > Stefan builds Thursday during the day US Pacific time > David announces after all this is done which is Thursday evening EU time > sometimes it becomes so late that I can only do it friday morning. > > > So if we want to release Thursday, t

Re: [PHP-DEV] Re voting

On Mon, Apr 16, 2012 at 8:42 PM, wrote: > Stas: > > Just b/c there are rarely any women at all that participate on this list, > could we at list maintain a facade of gender neutrality? One of my favorite PHP dev folks is Sara Golemon. A fucking rock star. Female, I believe. I think she might be

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

"class" won't collide anyways, as it's already a keyword, and you can't use it in your constant or function names. __CLASS__ has bad connotations for me, as it resolves to the declaring class normally, not the class invoked. I tend to agree. __CLASS__ to me belongs to the family of constants l

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

Would changing the definition for class_name_scalar be sufficient? class_name_scalar: class_name { zend_resolve_class_name(&$1, ZEND_FETCH_CLASS_GLOBAL, 1 TSRMLS_CC); $$ = $1; } ; To my eye, this is the least surprising syntax. As far as I can tell, this rule will not co

Re: [PHP-DEV] Some Stats

On 04/17/2012 11:41 AM, Kris Craig wrote: > > > On Mon, Apr 16, 2012 at 11:57 PM, Rasmus Lerdorf > wrote: > > Number of posts to internals since Jan.1,2012 (top 15): > > [kris.cr...@gmail.com ]=> 249 > > > Wooot! What's

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

On Tue, Apr 17, 2012 at 9:36 PM, Galen Wright-Watson wrote: >Would it be easy to have a patch that simply allows use of the class name, > or is the "::class" suffix necessary to resolve some ambiguity? Example > usage: > >    $mock = $this->getMock(A\Namespaced\**ClassName); >    # or >    use A\N

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

On Sat, Apr 14, 2012 at 12:50 PM, Ralph Schindler wrote: > Hi all, > > There are many different use cases were in code we expect classes names as > arguments to functions as fully qualified names. We do this in ZF a lot > with our Service Location and DI components, but also with our code > refle

Re: [PHP-DEV] Make require*/include* behave like a function for returning values, and more

Hi Paul, On 17/04/12 15:31, Paul Dragoonis wrote: I don't see any fundamental benefit to having this in PHP. Unexposed symbols can be interesting when instrumended code (for my concerns) or simply for security and safety reasons. So, benefits exist. It doesn't work around any current restric

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

How would static::class behave ? is it handled by the current patch? Maybe the test case could be extended to reflect this, and also for self::class? Fantastic question. I am unsure how to handle this. Currently, it will simply resolve those names against the rules (I am sure this is the w

Re: [PHP-DEV] Make require*/include* behave like a function for returning values, and more

I don't see any fundamental benefit to having this in PHP. It doesn't work around any current restrictions in the language. It just looks like extra fluffy magic that we could do without. - Paul. On Tue, Apr 17, 2012 at 8:18 PM, Ivan Enderlin @ Hoa < ivan.ender...@hoa-project.net> wrote: > Hi ev

[PHP-DEV] Make require*/include* behave like a function for returning values, and more

Hi everyone, I have noticed that it is not possible to do something like that: // foo.php 'bar']; // bar.php Array access on a require does not work: we have a parse error. Is it just a parser issue? Because a file can return an array without any problem. For now, one possible solution is to

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

var_dump is Moo::CLASS but the symbol Moo does not exist yet, only the class Foo\Bar\Baz was declared at this point. It could exist. It could be a class name handled by an autoloader somewhere else. This method of class name resolving operates in the spirit of how our namespace implementati

Re: [PHP-DEV] Some Stats

On Tue, Apr 17, 2012 at 12:05 PM, Sean Coates wrote: > Wooot! What's my prize? ;P > > > Shame. > > Hmm can I just opt for the cash payout instead? --Kris

[PHP-DEV] Make require*/include* behave like a function for returning values, and more

Hi everyone, I have noticed that it is not possible to do something like that: // foo.php 'bar']; // bar.php Array access on a require does not work: we have a parse error. Is it just a parser issue? Because a file can return an array without any problem. For now, one possible solution is to

Re: [PHP-DEV] Some Stats

> Wooot! What's my prize? ;P Shame.

Re: [PHP-DEV] Re voting

Sharon, On Mon, Apr 16, 2012 at 8:42 PM, wrote: > Stas: > > Just b/c there are rarely any women at all that participate on this list, > could we at list maintain a facade of gender neutrality? I seriously can't > believe that you used the word "him". What about "her"? Yeah, "her" as in > myse

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

> From the collisions point of view `class` and `__CLASS__` are equally > safe. > Imho ClassName::class reads nicer and also looks similar to the > similar ClassName.class syntax in Java. The current __CLASS__ could then be written self::class. Looks more "namespace/object oriented", where __CLAS

Re: [PHP-DEV] is_numeric_string an hexadecimal numbers ("123" == "0x7B")

On 4/17/12 08:17, "Nikita Popov" wrote: >The last one is more problematic. It is explicitly documented as >accepting hexadecimal numbers. In my eyes it too should not accept >them, but I could imagine that people rely on this. This always struck me as mistaken design. Why accept hex or decimal,

Re: [PHP-DEV] Some Stats

On Mon, Apr 16, 2012 at 11:57 PM, Rasmus Lerdorf wrote: > Number of posts to internals since Jan.1,2012 (top 15): > > [kris.cr...@gmail.com]=> 249 > Wooot! What's my prize? ;P Now I just need to start getting some commits in there --Kris

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

Hi Ralph, On 17/04/12 10:54, Ralph Schindler wrote: I've also added an RFC page, any thoughts on improving the RFC? * https://wiki.php.net/rfc/class_name_scalars Are you sure that the example section is correct? Because your first var_dump is Moo::CLASS but the symbol Moo does not exist yet,

Re: [PHP-DEV] '9223372036854775807' == '9223372036854775808'

On 04/13/2012 04:01 AM, Gustavo Lopes wrote: Currently, when two strings are compared, PHP tries to do a numerical comparison first. Therefore: var_dump("010" == "10"); //true I'm replying to this old mail now, because of the current discussion about hex numbers. The phrase "numerical com

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

On 2012-04-17, Stas Malyshev wrote: > > May I suggest using foo::__CLASS__ instead of foo::class ? It's longer, but > > closer to what already exists for this semantic (class name as string), > > don't you think ? > > I like this. __CLASS__ is already being used as class name, and little > chance

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

On Tue, Apr 17, 2012 at 6:58 PM, Stas Malyshev wrote: > Hi! > >> May I suggest using foo::__CLASS__ instead of foo::class ? It's longer, but >> closer to what already exists for this semantic (class name as string), >> don't you think ? > > I like this. __CLASS__ is already being used as class nam

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

Hi! > May I suggest using foo::__CLASS__ instead of foo::class ? It's longer, but > closer to what already exists for this semantic (class name as string), > don't you think ? I like this. __CLASS__ is already being used as class name, and little chance of colliding with some code since you're no

Re: [PHP-DEV] EXC_BAD_ACCESS, Could not access memory zval array type

On Tue, Apr 17, 2012 at 12:06 AM, Laruence wrote: > Hi: > > you can core dump the backtrace, then exam the related hash table to > find out what's going wrong there. So the problem doesn't seem to be with contains() at all. The problem is actually coming from another method I implemented call

Re: [PHP-DEV] Re: Some Stats

Great work everyone :) On 17 April 2012 12:44, David Soria Parra wrote: > On 2012-04-17, Rasmus Lerdorf wrote: >> Number of posts to the commit list since Jan.1,2012 (top 25): >> > > Number of commits to php-src (excluding merges) since Jan.1,2012 (top 15): > >    126 Xinchen Hui >     83 Rasmus

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

On 2012-04-17, Ralph Schindler wrote: > Hi Nikita, > > > A quick note on the patch: As the class name is compile-time > > resolvable it should in my eyes also be available as a > > `static_scalar`, so that it can be used in initialization lists: > > > > public function doFoo($withClass = ABC:

Re: [PHP-DEV] is_numeric_string an hexadecimal numbers ("123" == "0x7B")

On Tue, Apr 17, 2012 at 1:44 PM, Gustavo Lopes wrote: > On Tue, 17 Apr 2012 13:20:33 +0200, Nikita Popov > wrote: > >> The internal is_numeric_string [1] function is used to check whether a >> string contains a number (and to extract that number). >> >> Currently is_numeric_string also accepts he

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

Hi Nikita, A quick note on the patch: As the class name is compile-time resolvable it should in my eyes also be available as a `static_scalar`, so that it can be used in initialization lists: public function doFoo($withClass = ABC::class) { new $withClass; // or whatever } T

Re: [PHP-DEV] is_numeric_string an hexadecimal numbers ("123" == "0x7B")

On Apr 17, 2012, at 5:39, "Hartmut Holzgraefe" mailto:hartmut.holzgra...@gmail.com>> wrote: Same here, i never even knew that this worked in a string context until recently. Autocast/comparison rules are already complicated enough as they are documented now, and i failed to find anything in the m

Re: [PHP-DEV] is_numeric_string an hexadecimal numbers ("123" == "0x7B")

On 04/17/2012 01:20 PM, Nikita Popov wrote: > I don't think this has much BC impact, so it should be possible to change it. Same here, i never even knew that this worked in a string context until recently. Autocast/comparison rules are already complicated enough as they are documented now, and i

Re: [PHP-DEV] is_numeric_string an hexadecimal numbers ("123" == "0x7B")

2012/4/17 Gustavo Lopes : > > I think that would be an error. As was mentioned a few months ago when 0b > was introduced, no other number format has this behavior. You can't do "123" > == "0b10" or "123" == "0876". Extending this hexadecimal oddity instead of > eliminating it is inconsistent with t

[PHP-DEV] Re: Release day, was: release process with git

On 2012-04-17, Stas Malyshev wrote: > Hi! > >> The whole point of releasing on Thursdays is so sysadmins have the >> chance to update their servers in the event of known security problems >> "before the weekend". >> This point however becomes void when we release late Thursdays evening >> American

Re: [PHP-DEV] is_numeric_string an hexadecimal numbers ("123" == "0x7B")

On Tue, 17 Apr 2012 13:35:48 +0200, Simon Schick wrote: 2012/4/17 Nikita Popov var_dump('123' == '0x7b'); // true In all other parts of the engine hexadecimal strings are not recognized [3]: var_dump((int) '0x7b'); // int(0) I personally would rather change the type-conversion for str

[PHP-DEV] Re: Some Stats

On 2012-04-17, Rasmus Lerdorf wrote: > Number of posts to the commit list since Jan.1,2012 (top 25): > Number of commits to php-src (excluding merges) since Jan.1,2012 (top 15): 126 Xinchen Hui 83 Rasmus Lerdorf 79 Gustavo Andre dos Santos Lopes 73 Pierre Joye 62 Anatoliy

Re: [PHP-DEV] is_numeric_string an hexadecimal numbers ("123" == "0x7B")

On Tue, 17 Apr 2012 13:20:33 +0200, Nikita Popov wrote: The internal is_numeric_string [1] function is used to check whether a string contains a number (and to extract that number). Currently is_numeric_string also accepts hexadecimal strings [2] (apart from the normal decimal integers and d

Re: [PHP-DEV] is_numeric_string an hexadecimal numbers ("123" == "0x7B")

2012/4/17 Nikita Popov > > var_dump('123' == '0x7b'); // true > > In all other parts of the engine hexadecimal strings are not recognized > [3]: > > var_dump((int) '0x7b'); // int(0) > Hi, Nikita I personally would rather change the type-conversion for strings to integer ... At least if you forc

Re: [PHP-DEV] is_numeric_string an hexadecimal numbers ("123" == "0x7B")

hi! On Tue, Apr 17, 2012 at 1:20 PM, Nikita Popov wrote: >  [3]: > http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion >From the manual: "If the string starts with valid numeric data, this will be the value used. Otherwise, the value will be 0 (zero). Valid

[PHP-DEV] is_numeric_string an hexadecimal numbers ("123" == "0x7B")

Hi internals! The internal is_numeric_string [1] function is used to check whether a string contains a number (and to extract that number). Currently is_numeric_string also accepts hexadecimal strings [2] (apart from the normal decimal integers and doubles). This can cause some quite odd behavio

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

May I suggest using foo::__CLASS__ instead of foo::class ? It's longer, but closer to what already exists for this semantic (class name as string), don't you think ? As Marco suggested, I think using __CLASS__ would be confusing to some. __CLASS__ generally means, "where you see this, repla

[PHP-DEV] Merge request to 5.4. pg_escape_*()

Hi Stats, Would you merge this to 5.4? http://git.php.net/?p=php-src.git;a=commit;h=77d11b4959066dcbd47fce2ca65c41f5361ad40b This makes other bug fixes easier and keep master and 5.4 in sync. I don't mean to 5.4.1, but it should not harm any existing features. If you would like, I'll cherry pick

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

@Nicolas: wouldn't __CLASS__ introduce a bit of confusion with the existing constant? Marco Pivetta http://twitter.com/Ocramius http://marco-pivetta.com On 17 April 2012 11:17, Nikita Popov wrote: > On Sat, Apr 14, 2012 at 9:50 PM, Ralph Schindler > wrote: > > Hi all, > > > > There are man

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

On Sat, Apr 14, 2012 at 9:50 PM, Ralph Schindler wrote: > Hi all, > > There are many different use cases were in code we expect classes names as > arguments to functions as fully qualified names.  We do this in ZF a lot > with our Service Location and DI components, but also with our code > reflec

Re: [PHP-DEV] Some Stats

Hi! > Number of posts to the commit list since Jan.1,2012 (top 25): > > [s...@php.net] => 412 This figure is unfortunately over-inflated by the unfortunate tags incident :) So subtract 300 or so from that :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcr

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

May I suggest using foo::__CLASS__ instead of foo::class ? It's longer, but closer to what already exists for this semantic (class name as string), don't you think ? So, at current, is this small enough for just a pull request, or does this > deserve its own RFC? > Personnaly, I would say that a

[PHP-DEV] Re: Release day, was: release process with git

Hi! > The whole point of releasing on Thursdays is so sysadmins have the > chance to update their servers in the event of known security problems > "before the weekend". > This point however becomes void when we release late Thursdays evening > American time, and we could just as well release on S

Re: [PHP-DEV] release process with git

On 17.04.12 10:24, Bas van Beek wrote: > Sounds like facilitating wrong security protocols to me. In this > 365/24/7 environment, sysadmins should be willing and able to patch, fix > and secure systems at any time. Weekend should be no excuse. There are a lot of (very serious) shops out there with

Re: [PHP-DEV] release process with git

Op 17-4-2012 9:47, Hannes Magnusson schreef: On Mon, Apr 9, 2012 at 08:54, Stas Malyshev wrote: Hi! 5.4.1 will be the first release we're releasing using our new git setup. I would like to refine a process that we used to have for releases and make small tweaks hopefully to allow us more predi

Re: [PHP-DEV] release process with git

On Mon, Apr 9, 2012 at 08:54, Stas Malyshev wrote: > Hi! > > 5.4.1 will be the first release we're releasing using our new git setup. > I would like to refine a process that we used to have for releases and > make small tweaks hopefully to allow us more predictable release > schedule and faster re

Re: [PHP-DEV] voting without vcs accounts

> > >>> Why would that be a separate thread? Isn't that what we're talking >>> about? I.e. determining who gets voting access and who doesn't? >> >> >> I just ask for clarification on how the community representatives (which >> is defined in the accepted voting RFC) can get their karma. >> You a

Re: [PHP-DEV] EXC_BAD_ACCESS, Could not access memory zval array type

Hi: you can core dump the backtrace, then exam the related hash table to find out what's going wrong there. and some maybe un-relevant issues: 1. plz put all var declarations at the begining of a block (C89) 2. do not use "this" keyword as variable name (it's C++ keyword) thanks On Tue

  1   2   >