Hi!
> It would be good to have a section in UPGRADING.INTERNALS explaining
> in details what should be done, very important for non core extensions
> (pecl or other repositories).
Probably a good idea but I'm not sure what exactly to write there,
besides "initialize everything, check everything"
On Sun, Jul 27, 2014 at 8:10 AM, Michael Wallner wrote:
>
> On 27 07 2014, at 02:53, Kris Craig wrote:
>>
>> So even IF you want to reduce the scope of the 2/3 requirement to language
>> impacts in userland only, your RFC *still* falls under that requirement
>> because it directly affects the lan
On Sat, Jul 26, 2014 at 11:10 PM, Michael Wallner
wrote:
>
> On 27 07 2014, at 02:53, Kris Craig wrote:
> >
> > So even IF you want to reduce the scope of the 2/3 requirement to
> language
> > impacts in userland only, your RFC *still* falls under that requirement
> > because it directly affects
On 27 07 2014, at 02:53, Kris Craig wrote:
>
> So even IF you want to reduce the scope of the 2/3 requirement to language
> impacts in userland only, your RFC *still* falls under that requirement
> because it directly affects the language itself in userland, as described
> above. I would again
hi,
On Sun, Jul 27, 2014 at 1:59 AM, Stas Malyshev wrote:
> Hi!
>
>> What I found *safe*, with checkers that check object is properly
>> initialized, so not needing patch, but throwing exceptions or warnings
>> when used bad constructed :
>> - SPL
>
> SPL unfortunately is not safe at all - a lot
On Sun, Jul 27, 2014 at 3:38 AM, Andrea Faulds wrote:
>
> On 27 Jul 2014, at 02:30, Lonny Kapelushnik wrote:
>
>> Previously I posted on the list requesting any immediate feedback on this
>> proposal. Given the quick feedback I received I’ve made an RFC for
>> deprecating and removing the image
On 27 Jul 2014, at 02:30, Lonny Kapelushnik wrote:
> Previously I posted on the list requesting any immediate feedback on this
> proposal. Given the quick feedback I received I’ve made an RFC for
> deprecating and removing the imagettftext and imagettfbbox functions:
>
> https://wiki.php.net/
Hi all,
I appreciate the immediate feedback in this thread. Given the quick feedback
and suggestions I received I wanted to create an RFC to be able to collect
everything and move forward. I’ve written it out and properly announced it here.
Lets continue the discussion over there.
Morning all,
Previously I posted on the list requesting any immediate feedback on this
proposal. Given the quick feedback I received I’ve made an RFC for deprecating
and removing the imagettftext and imagettfbbox functions:
https://wiki.php.net/rfc/imagettf_deprecation
All comments welcome!
–
On 27 Jul 2014, at 01:53, Kris Craig wrote:
> so func_get_arg() and func_get_args() will return current value of argument
> instead of the actually passed. The following code is going to be affected
> “function foo($x) { $x = 2; return func_get_arg(0);} var_dump(foo(1));”
Those are to be consid
On Sat, Jul 26, 2014 at 3:16 PM, Zeev Suraski wrote:
> Kris,
>
>
>
> I’ll make it short.
>
>
>
> EVERY RFC affects the language in *some* way – be it its features,
> positioning, perception, performance, implementation, testability, you name
> it.
>
I believe that argument is specious. The RFC
Hi!
> What I found *safe*, with checkers that check object is properly
> initialized, so not needing patch, but throwing exceptions or warnings
> when used bad constructed :
> - SPL
SPL unfortunately is not safe at all - a lot of iterator classes
segfault on no-ctor initialization. I'll make a pa
On 27/07/2014 00:32, Andrea Faulds wrote:
>> Is PHPNG a feature? No, it’s not. It’s improvements & performance
>> optimizations at the implementation level. Those who have been following
>> my involvement on internals@ over the years know my position about both
>> feature creep and downwards com
Hi!
> What I found *not safe*, throwing unwanted warnings hitting an
> undesired behavior, or even segfaulting, and thus needing patch :
> - Dom
> - Mysqli
> - sqlite3 (sqlite3stmt class segfaults)
I'm testing a patch for sqlite3 right now and will commit it shortly,
but I could not reproduce an
In that case tthe voting RFC should be improved. The sentence about 1/2 vs
2/3 votes is really ambiguous.
Not fixing it will always lead to discussions over and over again.
On Sun, Jul 27, 2014 at 12:32 AM, Andrea Faulds wrote:
>
> On 26 Jul 2014, at 23:16, Zeev Suraski wrote:
>
> > *“**Given
On 26 Jul 2014, at 23:16, Zeev Suraski wrote:
> *“**Given that changes to languages (as opposed to changes to apps or even
> frameworks) are for the most part irreversible”*
>
>
>
> Implementation improvements such as PHPNG are not irreversible. New
> features or changed features are. This
Kris,
I’ll make it short.
EVERY RFC affects the language in *some* way – be it its features,
positioning, perception, performance, implementation, testability, you name
it. Each and every one, or we wouldn’t be discussing it on php.net’s
internals@ mailing list. So I’m afraid I’m not going
Hi!
> Could somebody please clarify what issues are still open here? From what
> I understand, both the opcache issue and the recursion issue are fixed
> now. What's the discussion about?
As I understand, the issue is that if you define class constant like this:
class Foo { const Bar = [0]; }
e
On 25 July 2014 17:25, Larry Garfield wrote:
> On 7/24/14, 2:38 PM, Sara Golemon wrote:
>>
>> On Thu, Jul 24, 2014 at 12:29 PM, Rowan Collins
>> wrote:
Zend is only one of many
contributors. Yes, the engine is still named Zend Engine but the
language has been improved by many
Hi!
> nope, some mock frameworks do that (afair atoum for example) but
> phpunit(phpunit-mock-objects to be more precise) was using the serialize
> trick and newInstanceWithoutConstructor()
> (https://github.com/sebastianbergmann/phpunit-mock-objects/blob/42f29d650744fd7ce785e7a4dd3598a09b0bfd2b/s
On Fri, Jul 25, 2014 at 12:51 AM, Zeev Suraski wrote:
>
>
>
> On Fri, Jul 25, 2014 at 7:28 AM, Kris Craig wrote:
>
>>
>>
>> > While this is a major change to the language implementation, it does
>> not actually affect end users in any meaningful way except for the positive
>> ‘side effect’ of th
On Sat, Jul 26, 2014 at 1:26 AM, Stas Malyshev
wrote:
> Hi!
>
> > yeah, that would work ofc, but as these libs seems to have instanitate
> > arbitrary classes, that would require either generating files on the fly
> > and including them or simply evaling them, but of those are a bit
> > dirtier
On Sat, Jul 26, 2014 at 5:42 PM, Nikita Popov wrote:
> On Fri, Jul 25, 2014 at 11:03 PM, Julien Pauli wrote:
>
> > On Wed, Jul 23, 2014 at 8:12 PM, Dmitry Stogov wrote:
> >
> >> PHP-5.6 is frozen for new features for a long time.
> >> Adding new features after RC is not a good idea.
> >> And we
On Sat, Jul 26, 2014 at 9:55 PM, Julien Pauli wrote:
> On Sat, Jul 26, 2014 at 1:26 AM, Stas Malyshev
> wrote:
>
>> Hi!
>>
>> > yeah, that would work ofc, but as these libs seems to have instanitate
>> > arbitrary classes, that would require either generating files on the fly
>> > and including
On Sat, Jul 26, 2014 at 1:26 AM, Stas Malyshev
wrote:
> Hi!
>
> > yeah, that would work ofc, but as these libs seems to have instanitate
> > arbitrary classes, that would require either generating files on the fly
> > and including them or simply evaling them, but of those are a bit
> > dirtier
On Fri, Jul 25, 2014 at 11:03 PM, Julien Pauli wrote:
> On Wed, Jul 23, 2014 at 8:12 PM, Dmitry Stogov wrote:
>
>> PHP-5.6 is frozen for new features for a long time.
>> Adding new features after RC is not a good idea.
>> And we will need some kind of RFC and voting.
>>
>
> I agree here.
>
> Bob
On 26/07/14 02:42, Bishop Bettini wrote:
> So I'm all for open information. My point is about human factors. When the
> results are listed alongside the argument, the results themselves *become
> part of the argument*. That is the nature of the bandwagon effect. *The
> brain treats the results as
27 matches
Mail list logo
