On Jan 11, 2017 11:46 PM, Nikita Popov wrote:
On Wed, Jan 11, 2017 at 1:07 PM, Dmitry Stogov
mailto:dmi...@zend.com>> wrote:
Hi,
I propose to introduce a unified type representation (zend_type).
Now it's going to be used for typing of arguments and return values.
Later we should use it for
Hi Andrea,
1) ZEND_TYPE_CE() is not used yet. We may make distinct between zend_string*
and zend_class_entry* based on context or using a value of reserved bit (0x2).
2) We can't initialize zend_strings* in constant structures, so we store const
char*. This code converts that const char* into
Hi Bob,
I don't exactly understand, what do you like.
Can you explain, or may be make it on top of this patch? (I think I'll commit
it on Friday)
Thanks. Dmitry.
From: Bob Weinand
Sent: Wednesday, January 11, 2017 9:13:33 PM
To: Dmitry Stogov
Cc: Derick Reth
Hi,
The page
https://wiki.php.net/phpng-upgrading#call_frame_changes_zend_execute_data
says:
> zend_execute_data.num_args - number of arguments passed to the function (this
> is a new field)
However, there's no such field in zend_execute_data structure:
https://github.com/php/php-src/blob/PHP-
Hi
2017-01-12 9:38 GMT+01:00 :
> Hi,
>
> The page
> https://wiki.php.net/phpng-upgrading#call_frame_changes_zend_execute_data
> says:
>
>> zend_execute_data.num_args - number of arguments passed to the function
>> (this is a new field)
>
> However, there's no such field in zend_execute_data str
Morning,
Other stuff that has been removed has strike through it, that would seem
approrpiate ?
Cheers
Joe
On Thu, Jan 12, 2017 at 8:59 AM, Kalle Sommer Nielsen wrote:
> Hi
>
> 2017-01-12 9:38 GMT+01:00 :
> > Hi,
> >
> > The page https://wiki.php.net/phpng-upgrading#call_frame_changes_
> zend
2017-01-12 10:28 GMT+01:00 Joe Watkins :
> Morning,
>
> Other stuff that has been removed has strike through it, that would seem
> approrpiate ?
Seems like a good idea, then we can indicate its not suggested to use
anymore and we still keep the information readable :)
--
regards,
Kalle Sommer
On Wed, Jan 11, 2017 at 7:22 PM, Scott Arciszewski
wrote:
> Hi all,
>
> I'm resurrecting my RFC to add libsodium as a core extension to PHP 7.2.
>
> In response to feedback from Pierre Joye, I've outlined which parts of the
> existing libsodium API I'd like exposed in the core extension. Most
> n
12.01.2017, 11:59, "Kalle Sommer Nielsen" :
> Hi
>
> 2017-01-12 9:38 GMT+01:00 :
>> Hi,
>>
>> The page
>> https://wiki.php.net/phpng-upgrading#call_frame_changes_zend_execute_data
>> says:
>>
>>> zend_execute_data.num_args - number of arguments passed to the function
>>> (this is a new fiel
Hi,
Dmitry Stogov wrote:
1) ZEND_TYPE_CE() is not used yet. We may make distinct between zend_string*
and zend_class_entry* based on context or using a value of reserved bit (0x2).
Ah, I see. Until it is used, could it be removed? Its presence right now
creates confusion.
2) We can't init
Afternoon internals,
I done a bad merge into 7.1, please do not commit until it is reset.
Very sorry for the inconvenience.
Cheers
Joe
hi,
we had a wrong merge in the php-src, merging master into PHP-7.1. I've just
force pushed the last good version before the bogus merge(
6fbd61a8199fbac9aac25d0dfaf1402a8f2b4e7b). You can find the bogus state at
https://github.com/Tyrael/php-src/tree/7.1.0-broken if you happen to have
some commi
On 03.01.2017 at 18:59, Jan Ehrhardt wrote:
> Davey Shafik in php.internals (Wed, 9 Dec 2015 13:51:56 -0500):
>
>> It's a simple Yes/No 50%+1 majority required as it's not a language change.
>>
>> https wiki dot php dot net/rfc/curl_http2_push#vote
>
> The RFC was apparently accepted, but the RFC
Results for project PHP master, build date 2017-01-11 20:29:06-08:00
commit: ec6b03a
previous commit:63b36be
revision date: 2017-01-12 00:14:55+01:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
On 1/12/2017 8:19 AM, Sebastian Bergmann wrote:
> Am 12.01.2017 um 08:11 schrieb Tim Bezhashvyly:
>> Disallow explicit call of __construct method
>
> I am baffled that this (still) works:
>
> $ cat /tmp/t.php
> class C
> {
> public function __construct()
> {
> print __METHOD__ .
Heya,
While I agree that it is weird to be able to call constructors more than
once, this is generally used for:
* lazy loading
* resource reset
Specifically, what is going on is something like following:dsn = $dsn;
// socket stuff happens here, much like with PDO
}
public fun
Hi Arvids,
> On Jan 10, 2017, at 17:22, Arvids Godjuks wrote:
>
> I would also add the support, bug and feature issues that will definitely
> crop up with such an interface. If there is a major bug, flaw or security
> issue, getting it fixed is going to be a problem, because as we know, the
>
On 1/12/2017 9:35 PM, Marco Pivetta wrote:
> Heya,
>
> While I agree that it is weird to be able to call constructors more than
> once, this is generally used for:
>
> * lazy loading
> * resource reset
>
> Specifically, what is going on is something like following:
> final class DbConnection
Hey Richard,
On Thu, Jan 12, 2017 at 9:58 PM, Fleshgrinder wrote:
> On 1/12/2017 9:35 PM, Marco Pivetta wrote:
> > Heya,
> >
> > While I agree that it is weird to be able to call constructors more than
> > once, this is generally used for:
> >
> > * lazy loading
> > * resource reset
> >
> > Sp
Hi Marco,
the only reason for prohibiting explicit __construct calls is that it makes PHP
objects mutable and it's state unpredictable. Still would like to give this RFC
a try.
And what about polymorphic dispatch?
Regards,
Tim
> On 12 Jan 2017, at 21:35, Marco Pivetta wrote:
>
> Heya,
>
>
On 1/12/2017 10:13 PM, Marco Pivetta wrote:
> Hey Richard,
>
> I made an example where everything was in a single class, but most
> scenarios involve a lazy-loading wrapper that has no knowledge of the
> original class besides its constructor.
>
> I use this approach to generate proxy classes tha
Hi Richard,
thank you for support with __construct. I absolutely agree that it breaks BC
and fine to propose it just for PHP 8.
By polymorphic dispatch I mean a possibility to have the same method (including
constructor) in multiple variations. E.g.:
class Price
{
public function __constru
Hey Tim,
On Thu, Jan 12, 2017 at 10:51 PM, Tim Bezhashvyly wrote:
> Hi Richard,
>
> thank you for support with __construct. I absolutely agree that it breaks
> BC and fine to propose it just for PHP 8.
>
> By polymorphic dispatch I mean a possibility to have the same method
> (including construc
On 12/01/2017 20:52, Paul Jones wrote:
I would also add the support, bug and feature issues that will definitely crop
up with such an interface. If there is a major bug, flaw or security issue,
getting it fixed is going to be a problem, because as we know, the adoption of
PHP is nowhere near i
>
> I am baffled that this (still) works:
>
__clone was special cased in 5.x, but special case was removed in 7.0
means that previously you couldn't do publicly $obj->__clone(); now you can
and, yes, it's as dangerous as it looks
however, the special case was removed for a reason that i'm sure is
25 matches
Mail list logo
