On 12/25/18 12:20 PM, Derick Rethans wrote:
There is no need to go from new extension with a new unproven API to directly
into core as first try. It's much better to try things out in for example PECL
and then to promote it to a core extension when all the kinks are worked out.
True, but in
Is sad to see people voting against this feature, which would help move
PHP into territories outside of the web development landscape. For those
developers not interested in learning the zend engine (lack of time) but
with enough knowledge about C, this extension would surely help a lot
when in
I'm just sneaking into the subject to point out that theres already some
work on this with the PHP swoole extension, in case it hasn't been
looked/taked into consideration yet:
https://github.com/swoole/swoole-src#coroutine
https://github.com/swoole/swoole-src#short-api-name
It has great perfo
On 09/03/2017 05:48 PM, David Rodrigues wrote:
From doc: http://php.net/manual/en/language.variables.scope.php
Note: Static variables may be declared as seen in the examples above.
From PHP 5.6 you can assign values to these variables which are the result
of expressions, but you can't use an
I upgraded my PHP version on a server from 7.0 to latest 7.1.9 and got
this strange behaviour, did something changed on the core language or is
this a bug?
PHP sample code:
--
PHP Fatal error: Constant expression contains invalid operations in
test.php
On 06/01/2017 03:04 PM, Fleshgrinder wrote:
Hey guys!
Just finished the very brief Doxygen RFC. Please let me know if you
require more information in it, I feel that it is sufficient as is,
since documenting is not rocket science (writing useful documentation
definitely is, but we cannot vote on
On 05/30/2017 02:48 PM, Fleshgrinder wrote:
Nice to see that I'm not the only who thinks that proper documentation
is a good thing. I already mentioned that it is not super important to
me personally to actually generate the docs from the code base. However,
there is also nothing bad about doing
Hi,
It seems that five years ago I was chatting on the php.internals irc and
I was asking wether documenting the source code with doxygen was
something that it could be worked on, but it seems that most core
developers where against having lots of code comments on the engine
code. So I sugges
On 12/08/2015 08:32 AM, Lester Caine wrote:
On 08/12/15 02:23, Rasmus Lerdorf wrote:
Ah, I just checked. You have no opcache at all in your PHP 7 setup. And you
have eaccelerator configured for PHP 5. So an opcode cached PHP 5 is only 10%
faster than a completely unaccelerated PHP 7. That's pr
On 11/16/2015 04:22 PM, Rasmus Lerdorf wrote:
But that is exactly what the file-based opcache does by itself. The only
speedup you achieve by trying to distribute the .bin files would be a
minor boost the first time a cli script is executed. All subsequent runs
of the script would hit the cache.
On 11/14/2015 08:03 PM, Rasmus Lerdorf wrote:
Beyond that I can't picture what possible use this could be.
I also think that the ability to have a .phpc and .php side by side
would be nice, but not for hiding the source code. It would be useful
especially for php-cgi and secondary for php-cli
On 09/23/2015 02:19 PM, Rowan Collins wrote:
The internal implementation can never be quite as simple as an IS_LONG
zval if we want to provide anything at all beyond a C-style enum. I for
one do not want Days::MONDAY === Months::JANUARY to return true, and nor
should typeof(Days::MONDAY) return "
On 09/22/2015 06:38 AM, Stig Bakken wrote:
Actually, you need to think about compatibility in a bigger perspective.
One of the first things I would want do if PHP were to grow enums, is
to add support for it to Apache Thrift. For those not familiar with
it, Thrift is basically an IDL for specify
On 09/18/2015 02:29 PM, Rowan Collins wrote:
Jefferson Gonzalez wrote on 18/09/2015 19:25:
I also believe the rfc should include type hinting of enums as has
been mentioned on this discussion. That would make enumerations more
useful and the rfc more complete.
It already mentions that
On 09/18/2015 01:21 PM, Levi Morrison wrote:
On Fri, Sep 18, 2015 at 11:18 AM, Rowan Collins wrote:
Levi Morrison wrote on 18/09/2015 18:04:
Anything else is trying to add value in some way – in your case you
are adding a primitive value that the language will automatically map
for you. I'm n
On 09/18/2015 10:21 AM, Levi Morrison wrote:
On Fri, Sep 18, 2015 at 1:05 AM, Pavel Kouřil wrote:
On Fri, Sep 18, 2015 at 1:06 AM, Rowan Collins wrote:
Hi All,
This has come up in passing a few times recently, but I'm not sure there's
ever been a dedicated discussion of it: would it be usefu
On 09/18/2015 10:42 AM, Anthony Ferrara wrote:
As far as enums, I wonder if they would be necessary if we supported
algebraic types, since you could define an "enum" as a virtual type:
const MONDAY = 0;
const TUESDAY = 1;
const WEDNESDAY = 2;
const THURSDAY = 3;
const FRIDAY = 4;
use MONDAY | TU
On 09/17/2015 08:05 PM, Rowan Collins wrote:
I don't think serializing to a name is particularly more inefficient
than serializing to an integer - depending on the internal
implementation, of course. Or do you mean efficiency in terms of the
length of the string produced?
Exactly! Lets say you
On 06/12/2015 04:13 PM, Rasmus Lerdorf wrote:
You can get even more speed by compiling with --enable-opcache-file and
then in your php-cli.ini add:
opcache.enable_cli=1
opcache.file_cache=/var/tmp
opcache.file_cache_only=1
Then every time you run composer it won't have to recompi
On 02/23/2015 05:05 AM, Zeev Suraski wrote:
-Original Message-
From: Joe Watkins [mailto:pthre...@pthreads.org]
Sent: Monday, February 23, 2015 10:03 AM
To: Jefferson Gonzalez
Cc: Zeev Suraski; PHP internals
Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints
RFC
On 02/22/2015 10:06 PM, Zeev Suraski wrote:
One key premise behind both strict type hinting and coercive type hinting is
that conversions that lose data, or that 'invent' data, are typically
indicators of a bug in the code.
You're right that there's no risk of a segfault or buffer overflow from
On 02/22/2015 09:15 PM, Stanislav Malyshev wrote:
We were talking about the case where the argument was even, you must
have missed that part. If the argument is not even, indeed both models
would produce the same error, no difference there. The only difference
in your model vs. dynamic model so f
On 02/22/2015 06:28 PM, François Laupretre wrote:
Hi Stas,
It seems the actual problem is that we have too many compiler / code analysis
experts in the community ;)
(don't get me wrong, I am not saying that for you, I just admire your patience
explaining the same again and again to people who
On 02/22/2015 11:06 AM, Joe Watkins wrote:
This is an inescapable difference, of the the kind that definitely does
have a negative impact on implementation complexity, runtime, and
maintainability.
To me, it only makes sense to compile strict code AOT or JIT; If you want
dynamic behaviour, we h
On 02/22/2015 09:00 AM, Etienne Kneuss wrote:
There have been several attempts:
for JS: http://users-cs.au.dk/simonhj/tajs2009.pdf
or similar techniques applied to PHP, quite outdated though:
https://github.com/colder/phantm
You are right that the lack of static information about types is (one
You're right. I am probably expressing my own frustration when I imagine that
withdrawing four important RFC s a few days before vote ends has little to do
with time management issues.
Let's stay politically correct and don't express anything about the atmosphere
in the community, which has no
26 matches
Mail list logo
