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 spac
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 potential
Hi internal,
I have met a strange behavior with stream_get_contents and stream
wrapper. This is explained here: https://bugs.php.net/65581.
Thoughts?
--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/
PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.
On Wed, Aug 28, 2013 at 8:50 PM, Stas Malyshev wrote:
> 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 must be a
2013/8/28 Stas Malyshev :
> 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 consider this ex
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 compa
On Thu, Aug 29, 2013 at 11:33 AM, Nikita Popov 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 function foo($bar)
On Fri, Aug 2, 2013 at 6:47 PM, Julien Pauli 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 rewrite
2013/8/28 Nikita Popov :
> 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 arguments using func
2013/8/29 Nikita Popov :
> 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 requires at l
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 y
On Thu, Aug 29, 2013 at 12:09 AM, Stas Malyshev wrote:
> 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 those that prefer
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 pa
On Thu, Aug 29, 2013 at 11:03 AM, Stas Malyshev wrote:
> 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 list makes sure more
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 but
On Thu, Aug 8, 2013 at 5:11 PM, Ferenc Kovacs 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 can break
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 wrote:
> On Fri, Aug 2, 2013 at 6:47 PM, Julien Pauli 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 tho
On Thu, Aug 29, 2013 at 5:59 PM, Levi Morrison wrote:
> On Thu, Aug 29, 2013 at 5:00 AM, Nikita Popov wrote:
>
>> On Fri, Aug 2, 2013 at 6:47 PM, Julien Pauli wrote:
>>
>> > Hi internals.
>> >
>> > I started a work of refactoring magic methods from internals.
>> >
>> > The first goal was to never
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 t
On 27/08/13 10:40, Nikita Popov wrote:
On Sat, Aug 3, 2013 at 8:16 PM, Nikita Popov 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 retval ptr, even for
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 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 RAND_ALGO_
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
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 u
On Fri, Aug 30, 2013 at 12:58 PM, Stas Malyshev 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
> SugarCRM: http://
> I think it is an unnecessary complication. Classes fit autoloader
> paradigm nicely, since the usual pattern is one class per one file
> (actually recommended in PSR), so it is easy to establish one-to-one
> automatic mapping between classes and files (also recommended in the
> PSR). But for func
30 matches
Mail list logo
