Hey:
On Wed, Jun 27, 2018 at 9:44 PM Christoph M. Becker
wrote:
> On 27.06.2018 at 08:47, Jan Ehrhardt wrote:
>
> > "Christoph M. Becker" in php.internals (Tue, 26 Jun 2018 13:15:32
> > +0200):
> >
> >> On 26.06.2018 at 08:42, Jan Ehrhardt wrote:
> >>
> >>>
> https://github.com/php/php-src/blob/p
Hi,
My name is JiexinWang(wjx), I am a php extension developer and I am very
passionate about developing php extensions;
I have submitted the extension to PECL (https://pecl.php.net/package/xlswriter)
and now I need to add the documentation to php.net, so I am starting an account
request here
Hi everyone,
I've made some changes to the RFC and the implementation today to explain
some of the edge cases and combined behaviour better.
There are some issues towards the bottom of the RFC that I would really
like some opinions on. They all have decisions made but are not concrete,
so I'd lik
>
> In summary, I propose that return type constraints should be removed
> which will allow us to pursue specific operator overloading at a later
> point if we desire
There are no return types or parameter types. The only requirement is that
the function is public and not static.
On Wed, 27 Jun
Hi!
> In the proposal, the code is valid in all versions of PHP up to and
> including 7.3, *and represents the same algorithm in all versions*. The
> only difference would be the side-effect of issuing an additional
> deprecation notice; that's not "a different meaning". In PHP 8, under
> Nikita's
Hi!
> Seems the vote should have been closed already. :)
Indeed! Thank you for the reminder, and sorry about me not putting
reminder on my calendar to send the email about it. So here it goes:
The vote result is 19 for and 4 against, which is 82% approving. This
means this RFC has been accepted.
On 17.06.2018 at 21:43, Stanislav Malyshev wrote:
> I would like to open the vote for the RFC about cleaning up the
> unmaintained extensions:
>
> https://wiki.php.net/rfc/umaintained_extensions
>
> The vote ends 2018-06-26 23:59 PDT.
Seems the vote should have been closed already. :)
--
Chri
On Wed, Jun 27, 2018 at 12:24 PM Levi Morrison wrote:
>
> On Tue, Jun 26, 2018 at 5:50 PM Rudolf Theunissen
> wrote:
> >
> > Hi everyone,
> >
> > This is an RFC that is based on previous discussions here:
> > https://externals.io/message/102337
> >
> > RFC: https://wiki.php.net/rfc/object-compari
On Tue, Jun 26, 2018 at 5:50 PM Rudolf Theunissen
wrote:
>
> Hi everyone,
>
> This is an RFC that is based on previous discussions here:
> https://externals.io/message/102337
>
> RFC: https://wiki.php.net/rfc/object-comparison
>
> The implementation is tested and appears to be working as expected.
On 26 June 2018 at 19:27, Nikita Popov wrote:
> a) In PHP "switch" is considered a looping structure, for this reason
> "break" and "continue" both apply to "switch", as aliases. For PHP, these
> are reasonable semantics, as PHP supports multi-level breaks. It would be
> very questionable if "bre
On 27/06/18 17:08, Nikita Popov wrote:
On Wed, Jun 27, 2018 at 5:59 PM, Rowan Collins mailto:rowan.coll...@gmail.com>> wrote:
On 27 June 2018 at 16:45, niel mailto:spam-f...@blueyonder.co.uk>> wrote:
> On 24/06/18 17:16, Nikita Popov wrote:
>
>> Hi internals,
>>
>>
On 27/06/18 16:59, Rowan Collins wrote:
On 27 June 2018 at 16:45, niel wrote:
On 24/06/18 17:16, Nikita Popov wrote:
Hi internals,
Another small deprecation for your consideration...
https://wiki.php.net/rfc/continue_on_switch_deprecation
Regards,
Nikita
Could you clarify the PHP 8 cha
> On Jun 27, 2018, at 1:48 AM, Dmitry Stogov wrote:
>
> Hi Niklas,
>
> Fibers are the major feature we're looking forward to, because it
> allows async I/O in places that do not account for async, e.g. also
> re-using interfaces designed for sync applications. Apart from that,
> we want to avoi
>
>
> > If $left operand and $right operand both have the magic methods, it will
> call $left->__magic($right), otherwise, if only the right one has the
> handler? What if the right one has compareTo and the left has only equal?
> you probably should add a table that explains which method is called
On Wed, Jun 27, 2018 at 5:59 PM, Rowan Collins
wrote:
> On 27 June 2018 at 16:45, niel wrote:
>
> > On 24/06/18 17:16, Nikita Popov wrote:
> >
> >> Hi internals,
> >>
> >> Another small deprecation for your consideration...
> >>
> >> https://wiki.php.net/rfc/continue_on_switch_deprecation
> >>
>
On 27 June 2018 at 16:45, niel wrote:
> On 24/06/18 17:16, Nikita Popov wrote:
>
>> Hi internals,
>>
>> Another small deprecation for your consideration...
>>
>> https://wiki.php.net/rfc/continue_on_switch_deprecation
>>
>> Regards,
>> Nikita
>>
>>
> Could you clarify the PHP 8 changes:
>
> "PHP
On Wed, Jun 27, 2018 at 11:46 AM niel wrote:
> On 24/06/18 17:16, Nikita Popov wrote:
> > Hi internals,
> >
> > Another small deprecation for your consideration...
> >
> > https://wiki.php.net/rfc/continue_on_switch_deprecation
> >
> > Regards,
> > Nikita
> >
>
> Could you clarify the PHP 8 chang
On 27 June 2018 at 16:24, Michał Brzuchalski wrote:
> There is also one more thing I can think of. If __equals and __compareTo
> methods
> don't have any restrictions for $other parameter typehint then I'll be able
> to declare
> Foo {
> public function __compareTo(int $other): int {}
> }
> a
On 24/06/18 17:16, Nikita Popov wrote:
Hi internals,
Another small deprecation for your consideration...
https://wiki.php.net/rfc/continue_on_switch_deprecation
Regards,
Nikita
Could you clarify the PHP 8 changes:
"PHP 8 generates a compile error."
Does this mean *any* use of continue in
On 27 June 2018 at 16:14, niel wrote:
> On 26/06/18 21:49, Rowan Collins wrote:
>
>> On 26/06/2018 20:28, niel wrote:
>>
>>> On 24/06/18 17:16, Nikita Popov wrote:
>>>
Hi internals,
Another small deprecation for your consideration...
https://wiki.php.net/rfc/continue_on_s
śr., 27 cze 2018 o 16:55 Michał Brzuchalski
napisał(a):
>
>
> śr., 27 cze 2018 o 03:29 Rudolf Theunissen
> napisał(a):
>
>> > I would like to see this in an extension first, i think it's perfectly
>> doable and people can test it before merging to core
>>
>>
> It was possible in Sara's extension
On 27 June 2018 at 14:30, Wes wrote:
> not some class, only same comparator function. e.g. this is ok, as __equals
> is the same for both classes
> trait X{ function __equals($o){ ... } }
> class A{ use X; }
> class B{ use X; }
> assert((new A) == (new B));
>
What does "the same function" mean,
On 26/06/18 21:49, Rowan Collins wrote:
On 26/06/2018 20:28, niel wrote:
On 24/06/18 17:16, Nikita Popov wrote:
Hi internals,
Another small deprecation for your consideration...
https://wiki.php.net/rfc/continue_on_switch_deprecation
Regards,
Nikita
IMO the proposed illustrations will lead
śr., 27 cze 2018 o 03:29 Rudolf Theunissen
napisał(a):
> > I would like to see this in an extension first, i think it's perfectly
> doable and people can test it before merging to core
>
>
It was possible in Sara's extension[1], so maybe now also? Take a look.
> Actually not sure this can be d
On Wed, Jun 27, 2018 at 2:10 PM, Christoph M. Becker
wrote:
> On 27.06.2018 at 15:00, Jakub Zelenka wrote:
>
> > I think it makes sense for big engine changes that you described but I
> > don't think this should be the case for features in core extensions and
> > SAPI's. The thing is that some of
On 27.06.2018 at 08:47, Jan Ehrhardt wrote:
> "Christoph M. Becker" in php.internals (Tue, 26 Jun 2018 13:15:32
> +0200):
>
>> On 26.06.2018 at 08:42, Jan Ehrhardt wrote:
>>
>>> https://github.com/php/php-src/blob/php-7.3.0alpha2/UPGRADING.INTERNALS
>>>
>>> pecl_http:
>>> |php_http_client_curl_use
not some class, only same comparator function. e.g. this is ok, as __equals
is the same for both classes
trait X{ function __equals($o){ ... } }
class A{ use X; }
class B{ use X; }
assert((new A) == (new B));
On 27.06.2018 at 15:00, Jakub Zelenka wrote:
> I think it makes sense for big engine changes that you described but I
> don't think this should be the case for features in core extensions and
> SAPI's. The thing is that some of us are not going to work on those big
> changes for various reasons. P
On Mon, Jun 25, 2018 at 4:03 PM, Zeev Suraski wrote:
> On Mon, Jun 25, 2018 at 5:57 PM Christoph M. Becker
> wrote:
>
> > On 25.06.2018 at 14:30, Zeev Suraski wrote:
> >
> > > What this list is - a collection of directions around which we've
> > performed varying amounts of research (some of the
29 matches
Mail list logo
