> 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
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://
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
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
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_
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 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
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 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
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
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 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
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
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
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
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
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 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
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
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
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
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
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)
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
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
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
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
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.
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
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
30 matches
Mail list logo
