Results for project PHP master, build date 2016-08-29 06:24:23+03:00
commit: 07d1f0c
previous commit:9950485
revision date: 2016-08-29 05:58:33+09:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
I think you will find information about this in the threads
for discussion and voting regarding Nullable types RFC:
- https://marc.info/?l=php-internals&m=14606054028
- https://marc.info/?l=php-internals&m=146289381815830
- https://wiki.php.net/rfc/nullable_types
Regards //Björn Larsson
Den
On Mon, Aug 29, 2016 at 7:36 AM, Igor Inas wrote:
> Hello,
>
> same as last post in the mailing list - this may have been suggested before
> - but I had hard time finding it in the archives.
>
> Coming from static typed languages, I love the addition of return type
> annotations and extension of p
There was / is a proposal about bigints, see:
https://wiki.php.net/rfc/bigint
Regards //Björn Larsson
Den 2016-08-29 kl. 15:48, skrev David Rodrigues:
Currently PHP integer is limited to 2147483647 or 9223372036854775807
(PHP_INT_MAX), depending of system bits. We can works with long
integers
Currently PHP integer is limited to 2147483647 or 9223372036854775807
(PHP_INT_MAX), depending of system bits. We can works with long
integers by using bcmath, for instance. But why not to support it
natively?
I mean, PHP can parse infinity integers, but it's converted to
cientific notation or to
Hello,
same as last post in the mailing list - this may have been suggested before
- but I had hard time finding it in the archives.
Coming from static typed languages, I love the addition of return type
annotations and extension of parameter type annotations. I also love the
fact, that types are
As was said, this was debated a lot. Both sides had valid arguments, but
this should not be taken lightly just because there is no "BC break". There
is such thing as too much syntactic sugar, and PHP is one of those, rare
these days, languages that keep options of doing the same thing low.
On Mon,
Hi, Thanks
Seems like is not going to happen very soon :)
In fact it is not broken, it's only a cosmetic nice to have.
Maybe in the future it will happen.
On 29 August 2016 at 14:06, Kalle Sommer Nielsen wrote:
> Hi Mathias
>
> 2016-08-29 15:03 GMT+02:00 Mathias Grimm :
> > Hi,
> > I have a su
Hi Mathias
2016-08-29 15:03 GMT+02:00 Mathias Grimm :
> Hi,
> I have a suggestion, maybe many gave it before.
>
> My suggestion is the optional use of the keyword "function" inside classes,
> interfaces and traits.
> It would look much more clean while removing the redundancy.
This was discussed
Hi,
I have a suggestion, maybe many gave it before.
My suggestion is the optional use of the keyword "function" inside classes,
interfaces and traits.
It would look much more clean while removing the redundancy.
Cheers,
Mathias Grimm
On 25/08/2016 19:13, Adam Baratz wrote:
Anatol suggested I reach out to this group. I've been doing some of this
work in an informal capacity over the past few months
(design/coding/testing feedback on relevant PRs). I'd like to take on the
role officially. Besides the PR feedback, I'm working on
Hi everyone,
following Adam's example, I think it's time for me to step up. I've been
unofficially doing bug fixing and adding new features to pdo_pgsql over
the past few years, and I'd be happy to keep doing that officially in
the future. I'd also try to keep an eye on pdo itself if needs be,
12 matches
Mail list logo
