Le 29/08/2013 07:54, Pierre Joye a écrit :
hi Remi!
On Thu, Aug 29, 2013 at 7:33 AM, Remi Collet r...@fedoraproject.org wrote:
But we are PHP project members. And we ship an OpenSource software which
is Licensed under the PHP License, a really free License (per FSF
definition).
Ah? I
Hi!
Subject: Switch from json extension which have a problematic (non-free)
license to jsonc dropin free alternative.
RFC: https://wiki.php.net/rfc/free-json-parser
From what I see in the benchmarks, while encoding is on par with current
implementation, decoding is more than 2x slower.
Le 29/08/2013 08:25, Stas Malyshev a écrit :
Hi!
Subject: Switch from json extension which have a problematic (non-free)
license to jsonc dropin free alternative.
RFC: https://wiki.php.net/rfc/free-json-parser
From what I see in the benchmarks, while encoding is on par with current
Le 29/08/2013 08:25, Stas Malyshev a écrit :
Also, I see the sizes of the encode results is different from ext/json.
Why is that?
Stupid bench... data include some values from microtime()...
Fixed.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Le 29/08/2013 09:04, Stas Malyshev a écrit :
Hi!
From my analysis (profiling), most of the time is spent in memory
allocation calls.
As we used a parser from a library, we do
1- parse in library space
2- object tree allocation of the result
3- copy result from library space to php space
I have to say that I'm not wildly enthusiastic about making this change over
what appears to be a fairly minor comment in the license, and without even
going into the discussion as to why we want to promote Evil :)
The main concerns I have are:
* Downwards compatibility. We've found one
On Wed, Aug 28, 2013 at 8:50 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
I would like to react on Stat's it's-not-our-problem comment in
https://bugs.php.net/bug.php?id=63520
I assume by Stat you mean myself, though I'm not the only one who
Yup, sorry for mangling your name, this
2013/8/28 Stas Malyshev smalys...@sugarcrm.com:
Hi!
And while the issue was first reported by Debian, the other
distributions share the same concerns. This is why PHP should consider
this - because the other parts of the eco-system are already going
forward with this.
What we need to
Hi!
Unfortunatelly nobody pointed out that it has to be discussed in the mailing
list in the mentioned bug report. We have stated that we have a problem
with JSON license and we had to solve the problem we had.
I consider the licensing issue as a bug and it's always better to track it
as
Hi internals!
This is a spinoff from the variadics thread. Quoting Stas:
I also think this:
public function query($query, ...$params)
public function query(...$params)
should be legal too.
This is a general issue in PHP that we might want to fix: Currently a
method A is not
On Thu, Aug 29, 2013 at 11:33 AM, Nikita Popov nikita@gmail.com wrote:
This is a general issue in PHP that we might want to fix: Currently a
method A is not compatible with a method B if A has less arguments than B.
E.g. both of the following are incompatible signatures:
public
On Fri, Aug 2, 2013 at 6:47 PM, Julien Pauli jpa...@php.net wrote:
Hi internals.
I started a work of refactoring magic methods from internals.
The first goal was to never write ourselves things like __get, but use
macros for those names. (get, set, invoke, etc...).
A second goal was to
2013/8/28 Nikita Popov nikita@gmail.com:
Hi internals!
I'd like to propose an RFC, which adds dedicated syntax for variadic
functions:
https://wiki.php.net/rfc/variadics
Basically this allows declaring variadics directly in the function
signature, rather than fetching the
2013/8/29 Nikita Popov nikita@gmail.com:
Hi internals!
This is a spinoff from the variadics thread. Quoting Stas:
I also think this:
public function query($query, ...$params)
public function query(...$params)
should be legal too.
I respectfully disagree.
The first method
Marc Bennewitz wrote:
Idea for an RFC for a more powerful (and backward compatible) API of
random number generator functions.
The following psaudocode is self explained (hopfully)
const RAND_ALGO_LIBC
const RAND_ALGO_MERSENNE_TWISTER
const RAND_ALGO_OPENSSL
const RAND_ALGO_GMP
(...)
What do
On Thu, Aug 29, 2013 at 12:09 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
I like the idea, the concept of capturing rest of args is pretty
common. But couldn't we in addition have func_get_args() be able to
receive an int argument that would produce the rest in an easier way
for
Nikita Popov wrote:
I'd like to propose an RFC, which adds dedicated syntax for variadic
functions:
https://wiki.php.net/rfc/variadics
I can remember in PHP4 days, passing parameters to the database as a string of
variables was the norm. Then arrays came along and it was preferable to
On Thu, Aug 29, 2013 at 11:03 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
So if something is a question which needs
discussion, it is proper to raise it to the list, that doesn't mean
automatically it's considered not important or not worth fixing - quite
the contrary, raising it on the
Hey internals,
The two weeks of voting have passed. Voting is now closed. The result of the
vote is: 16 Yes votes, 4 No. This translates to 16/20 = 0.8, which is above
the required 2/3 majority threshold.
As such, I consider this RFC accepted. Thanks for the feedback and support.
Both Stas
Ondřej Surý wrote:
Well, basically the pecl-json-c is now a default provider of JSON extension
in Debian (and Fedora) and the downstream distributions (Ubuntu, RHEL, ...).
This is an area I've highlighted in the past ... While the PHP distributions
define a 'core' set of modules, I don't know
Lester's position seems unclear but I'll weigh-in. Having strict interfaces
and arguments means that the developer does not have to parse and validate
each parameter that is arbitrarily passed in. If anything, I would prefer to
see func_get_args() removed entirely. Now, I know that won't happen
On Thu, Aug 8, 2013 at 5:11 PM, Ferenc Kovacs tyr...@gmail.com wrote:
Hi,
I've just bumped into https://bugs.php.net/bug.php?id=65322 recently, and
I would like you get some opinions on the issue.
Personally I think that it is a really bad design to introduce
pedantic(E_STRICT) errors which
I think of the following definition:
function foo($bar = NULL)
To really be two definitions with method overloading:
function foo()
function foo($bar)
Allowing an inheritor/implementor to choose to not implement the second
signature does not seem logical at all when you think of them this
On Thu, Aug 29, 2013 at 5:00 AM, Nikita Popov nikita@gmail.com wrote:
On Fri, Aug 2, 2013 at 6:47 PM, Julien Pauli jpa...@php.net wrote:
Hi internals.
I started a work of refactoring magic methods from internals.
The first goal was to never write ourselves things like __get, but
On Thu, Aug 29, 2013 at 5:59 PM, Levi Morrison morrison.l...@gmail.comwrote:
On Thu, Aug 29, 2013 at 5:00 AM, Nikita Popov nikita@gmail.comwrote:
On Fri, Aug 2, 2013 at 6:47 PM, Julien Pauli jpa...@php.net wrote:
Hi internals.
I started a work of refactoring magic methods from
Hi!
I respectfully disagree.
The first method requires at least one parameter (or two, depending on
the pending clarification in the other thread) , and the latest: zero
or more (or 1 or more).
Yes, this is true. But how it is an objection? LSP allows to weaken
preconditions, but not to
On 27/08/13 10:40, Nikita Popov wrote:
On Sat, Aug 3, 2013 at 8:16 PM, Nikita Popov nikita@gmail.com wrote:
Hi internals!
Is there any particular reason why we only pass return_value_ptr to
internal functions if they have the ACC_RETURN_REFERENCE flag set?
Why can't we always provide the
All,
I have created a new draft RFC implementing function and constant
autoloading in master:
https://wiki.php.net/rfc/function_autoloading
All feedback is welcome.
Thanks
Anthony
On Thu, Aug 29, 2013 at 9:00 PM, Ángel González keis...@gmail.com wrote:
Marc Bennewitz wrote:
Idea for an RFC for a more powerful (and backward compatible) API of
random number generator functions.
The following psaudocode is self explained (hopfully)
const RAND_ALGO_LIBC
const
Hi!
I have created a new draft RFC implementing function and constant
autoloading in master:
https://wiki.php.net/rfc/function_autoloading
All feedback is welcome.
I think it is an unnecessary complication. Classes fit autoloader
paradigm nicely, since the usual pattern is one class per
Hi!
It is
Oops, clicked too soon. I wanted to conclude that I think it is too many
complications in the engine for too little gain.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To
On Fri, Aug 30, 2013 at 12:58 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
It is
Oops, clicked too soon. I wanted to conclude that I think it is too many
complications in the engine for too little gain.
I agree with Stas here.
thanks
--
Stanislav Malyshev, Software Architect
32 matches
Mail list logo
