On Mon, Apr 11, 2016 at 11:53 PM, Dmitry Stogov wrote:
> Or... maybe we shall move the function info related functions into the
> core? since we might have some optimization based on the function info
> instead of optimizing opcode only in the future.
>
> We consider, possibility of moving the wh
In PHP 7.0 we introduced random_bytes() which wraps Linux's getrandom(2)
as well as Windows's CryptGenRandom() and uses /dev/urandom as a fallback.
I think it would be great if we added a function that wraps
/proc/sys/kernel/random/uuid [2] and, if that exists, its equivalent on
Windows to make th
On Mon, Apr 11, 2016 at 4:09 PM, Stanislav Malyshev wrote:
> The API looks a bit strange - new IntlCharsetDetector($text) and then
> detect(). Can't we just have detect([$text])?
>
I went with a direct wrapping of the underlying API because it always
feels like we regret adding magic eventually.
Hi!
> With a light push from Stas, I've decided to go ahead and put up
> IntlCharsetDetector for discussion.
> https://wiki.php.net/rfc/intl.charset-detector
>
> I'm still not personally convinced this API is trustworthy enough, but
> it's worth a formal discussion period at least.
The API looks
With a light push from Stas, I've decided to go ahead and put up
IntlCharsetDetector for discussion.
https://wiki.php.net/rfc/intl.charset-detector
I'm still not personally convinced this API is trustworthy enough, but
it's worth a formal discussion period at least.
-Sara
--
PHP Internals - PHP
On Mon, Apr 11, 2016 at 9:36 AM, Stanislav Malyshev wrote:
> The point is even imperfect detection may be useful in certain
> circumstances, and detector being part of ICU hints that people find it
> useful enough to spend time implementing and supporting it. We should
> not ignore that.
>
Well, S
On 04/06/2016 11:33 AM, Phil Sturgeon wrote:
We polled pretty hard and had a bunch of discussions about how
multiple declarations should work, and ended up siding with Zeev and
Larry, and all those others saying that type declarations should work
for all just as visibility does currently:
publi
On 4/11/2016 7:12 PM, Fleshgrinder wrote:
> Support for mutable public properties is a different story but allowing
> them would destroy the encapsulation and I am against it without anyone
> bringing some good arguments that convince me.
>
This of course would be different with the RFC you menti
On 4/11/2016 6:59 AM, Larry Garfield wrote:
> There's an important point here that should not be missed. If these
> values are "write once then locked', which I can definitely see as
> useful, we need to have another shot at modifying them from __clone().
> If not, they are effectively useless fo
On 4/11/2016 6:36 PM, Stanislav Malyshev wrote:
> Hi!
>
>>> As you say, it doesn't work properly. As a matter of fact, guessing
>>> charsets, like timezones, is not possible. You need to know which
>>> charset something is in. If not, you need to address *that* problem.
>
> It is true that you
/Sending this again because the PHP mail server was down./
I thought some more about it and I think that the best choices would be
*val* (for /value/) and *var* (for /variable/) as in Scala.
Why?
The *var* keyword is not going to be deprecated and its meaning is
currently kind of ambiguous. I tr
Hi!
>> As you say, it doesn't work properly. As a matter of fact, guessing
>> charsets, like timezones, is not possible. You need to know which
>> charset something is in. If not, you need to address *that* problem.
It is true that you can not detect charsets with 100% accuracy. It is,
however,
I think, It's going to be a part of opcache.
Today, all PHP processes use shared bytecode, with JIT we will in addition
share the native code.
Thanks. Dmitry.
From: Lin Yo-An
Sent: Monday, April 11, 2016 19:04
To: Dmitry Stogov
Cc: Xinchen Hui; Nikita Popov;
On Mon, Apr 11, 2016 at 11:53 PM, Dmitry Stogov wrote:
>
>
> We consider, possibility of moving the whole Optimizer into Zend, but it
> won't change a lot, because expensive optimization make sense only with
> opcache (when script is optimized once and executed many times).
>
Do you (or the team
Hi Yo-An
On 04/11/2016 02:54 PM, Lin Yo-An wrote:
Hi Dmitry,
How's it going?
I traversed the code of opcache extension, and just found the
FUNC_INFO related macros. I guess the accessor information is more
like an entry that should be put in the function info.
That, FUNC_INFO is available
On 4/11/16 5:51 AM, André Rømcke wrote:
On Apr 11, 2016, at 06:59 , Larry Garfield wrote:
...
(Which leads to "can interfaces define properties", which leads right back to "well
what can you do with them", which leads back to the Properties RFC. Which I still want to see
happen at some point i
On Fri, Apr 8, 2016 at 2:20 PM, Sara Golemon wrote:
> On Thu, Apr 7, 2016 at 9:36 AM, Bishop Bettini wrote:
> > The problem is, developers are going to write code to guess character
> sets.
> >
> True. But they're going to put more faith in something in the
> standard distribution, assuming it'
Maybe even more sugar? :)
getValueFromDB();
// Methode getValueFromDB() called, if $value not transmitted or null value
public function __construct($value ??= $this->getValueFromDB())
{
//...
}
public function getFromCache()
{
// Methode getValueFromDB() called, once upon init static $
Hi Dmitry,
How's it going?
I traversed the code of opcache extension, and just found the FUNC_INFO
related macros. I guess the accessor information is more like an entry
that should be put in the function info.
Or... maybe we shall move the function info related functions into the
core? since w
I would prefer putting the "final" keyword before the "public".
final public $items;
Since we should emphasis "final" rather than "public"
There is a concept in storage devices that fits: Write Once Read Many
(WORM) https://en.wikipedia.org/wiki/Write_once_read_many
final class Value {
public worm $name;
public function __construct(string $name) {
$this->name = $name;
}
}
I'm not aware of any programming language
> On Apr 11, 2016, at 06:59 , Larry Garfield wrote:
> ...
> (Which leads to "can interfaces define properties", which leads right back to
> "well what can you do with them", which leads back to the Properties RFC.
> Which I still want to see happen at some point if at all possible, as it
> wou
Results for project PHP master, build date 2016-04-11 06:34:59+03:00
commit: 60b1441
previous commit:a186ac0
revision date: 2016-04-07 10:26:32+09:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
23 matches
Mail list logo
