Re: [PHP-DEV] [RFC] IntlCharsetDetector

[Sara Golemon]

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.  It's trivial for some
composer installable library to wrap this into something nicer.  In
fact, one probably WOULD use a userspace library in order to provide
fallback to mb_detect_encoding() on PHP < 7.1

That said, how do you feel about compromising by adding this function
in addition to the raw API?

function ucsdet_detect_encoding(string $text, string $hint = null,
bool $filter = false) {
  $det = new IntlCharsetDetector($text);
  if ($hint !== null) {
$det->setDeclaredEncoding($hint);
  }
  $det->enableInputFiltering($filter);
  return $det->detect()['name'];
}

That'll give simplicity for the 80% case (I have a string, I want a
best guess) but still provide the true API for consideration of
confidence and/or other guesses.

-Sara

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] IntlCharsetDetector

[Stanislav Malyshev]

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 a bit strange - new IntlCharsetDetector($text) and then
detect(). Can't we just have detect([$text])?

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC] IntlCharsetDetector

[Sara Golemon]

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 Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] IntlCharsetDetector

[Sara Golemon]

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, Stas, your informal thumbs up to the idea means enough to me to
at least formalize it into an RFC even though I was previously feeling
negative on it.

I may yet vote no on my own RFC after the discussion period, but as
you say it's worth considering the fact that someone thought it
reasonable enough to actually build into ICU...

-Sara

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC Discussion] Typed Properties

[Stephen Coakley]

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:


public int $foo, $bar;

$bar here will be int.

Trying to specify another type will resolve in an error. RFC is
updated to match.

We have a few more implementation tweaks to make, then it's off to the
races with this one.



Nice work; I really appreciate all of the hard work done on this RFC. A 
happy camper here with the results.


--
Stephen

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Final properties

[Fleshgrinder]

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 mentioned because
then they are not simply public mutable properties anymore but a real
method will be called that allows hooks. I wrote the above under the
assumption of:

interface Example {

final public DateTimeImmutable var $created;

}

Where you end up not being able to hook into assignments and I am
against the introduction of such a feature. ;)

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Final properties

[Fleshgrinder]

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 for implementing objects in the
> style of DateTimeImmutable or the PSR-7 Request/Response objects. 
> Locking after __construct or __clone (as appropriate) is done is fine,
> but if we can't clone-and-modify then I would pretty much never find
> value in this feature (no pun intended).
> 

*__clone* support is indeed extremely important, very good point.

> I agree that final seems like a potentially confusing keyword, as every
> other use of final (AFAIK) means "subclass cannot change this", but
> that's not at all the meaning here.
> 

See other messages of mine in this thread.

> Another question, which unfortunately runs straight into the previous
> Properties RFC: If a public property is write-once, with the intent
> being that it's set from the constructor and then cannot be overridden
> but is publicly exposed... shouldn't an interface be able to declare it
> as well?  It makes public properties safe to use in some cases, but you
> can't rely on that safely without an interface.
> 
> (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 would also subsume this question quite nicely.)
> 

I do not see the relation to the RFC (not judging the actual RFC because
I liked the idea but never got into the topic to be able to judge) but I
understand the concern.

In my opinion interfaces in PHP are at the state of Java 7 interfaces
(or even a direct copy) and their functionality must be extended at some
point. Same happened in Java 8.

That being said, I agree that properties should be allowed in
interfaces, however, they must be automatically made *final* and
immutable (where I proposed the *val* keyword).

interface Example {

DateTimeImmutable $created;

function example();

}

Transforms to:

interface Example {

final public DateTimeImmutable val $created;

public function example();

}

Otherwise no consumer could rely on the interface to not change. Also
note that it does not require the RFC you mentioned because no setter,
unset, nor isset is necessary or possible if we handle it like this.

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.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] IntlCharsetDetector

[Fleshgrinder]

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 can not detect charsets with 100% accuracy. It is,
> however, also true that many charsets can be distinguished with enough
> accuracy to make it useful, especially if you know the set of charsets
> you are dealing with. E.g., Russian had about 5 commonly used encodings
> before everybody started to use UTF-8, and several exotic ones. Being
> able to detect at least the major ones while dealing with a
> heterogeneous library of Russian-language texts is a great help. There
> may be other cases like this.
> 
> 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.
> 

I need to agree with Stanislav here completely. Sebastian Bergmann has a
quirky userland detection in its own library and I am sure there are
millions of others who have it. Providing one quirky implementation in
the core at least allows us to improve it over time and userland
improves at the same time (although I doubt that it is possible to
improve this kind of detection to a point where it really works).

On 4/11/2016 4:51 PM, Bishop Bettini wrote:
> What about forcing the consumer to stipulate minimal acceptable
confidence?
> The API would internally filter any matches with confidence strictly lower
> than the given value. Along the lines of:
>
> ucsdet_detect(IntlCharsetDetector $det, int $minimum_confidence): array
> ucsdet_detect_all(IntlCharsetDetector $det, int $minimum_confidence):
array
>
> So the relatively reliable UTF-8 test
>  could be written:
>
> if ('UTF-8' === $detector->detect(100)) {
> // ...
> }
>
> This exposes the heuristics available in ICU and leaves the API flexible,
> while forcing the consumer to consider the fact that this is statistical
> reasoning, not decision.
>

This is actually not such a bad idea to create awareness. At least
better than only documenting it; which probably only good devs read (and
understand).

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Final properties

[Fleshgrinder]

/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 tried to assign it a new meaning in the
thread about /Access and Visibility Modifiers/ thread
(http://marc.info/?l=php-internals=146005798902985=2) but as Rowan
Collins pointed out, it would be kind of weird to continue using *var*
for anything related to access/visibility because it simply means
something else; it means /variable/.

The introduction of a counterpart to it would allow it to finally have a
meaningful functionality and it would not introduce any kind of BC for
old code.

class Foo {

val $x;

var $y;

val $z;

}

class Bar extends Foo {

var $x;

$y;

$z;

}

The parent defines its property as being a *val* (immutable) and the
extending class lifts this constraint by redeclaring it as a *var*
(mutable). Doing so ensures that the developer must know what she is
doing and hence makes the language overall more secure.

There is no BC for the /y/ property because the parent is already
mutable and implicit public (or hopefully /assembly visible/ in the
future, see other references thread), hence, the /y/ in the child class
simply stays mutable.

The /z/ will stay a *val* (immutable) because its parent declaration is
defined as such.

class Point {

final public float val $x = 0.0;

final public float val $y = 0.0;

}

final class Point3d extends Point {

final public float val $z = 0.0;

}

final class MutablePoint extends Point {

final public float var $x; // FATAL ERROR

final public float var $y; // FATAL ERROR

}

The *final* keyword could be added via another RFC and it would have the
same meaning as the *final* keyword for classes and methods: freeze the
definition. This is why the *MutablePoint* results in fatal errors: it
tries to redeclare /x/ and /y/ from *val* to *var* although they are
*final*.

Note that this could be easily extended to local variables at a later
stage as well and it would be extremely useful.

I think that Scala's *val*/*var* approach could really help us to make
*var* usable again in a meaningful manner and it corresponds nicely to
the concept of /value objects/ and related concepts with its naming scheme.

What do you think?

-- 
Richard "Fleshgrinder" Fussenegger





signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] IntlCharsetDetector

[Stanislav Malyshev]

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, also true that many charsets can be distinguished with enough
accuracy to make it useful, especially if you know the set of charsets
you are dealing with. E.g., Russian had about 5 commonly used encodings
before everybody started to use UTF-8, and several exotic ones. Being
able to detect at least the major ones while dealing with a
heterogeneous library of Russian-language texts is a great help. There
may be other cases like this.

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.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Object getter method optimization

[Dmitry Stogov]

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; Bob Weinand; Joe Watkins; internals
Subject: Re: Object getter method optimization



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?) prefer to keep the JIT implementation as an extension or 
integrate the JIT implementation into the Zend core?


Thanks, Yo-An

[PHP-DEV] Re: Object getter method optimization

[Lin Yo-An]

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?) prefer to keep the JIT implementation as an extension
or integrate the JIT implementation into the Zend core?


Thanks, Yo-An

[PHP-DEV] Re: Object getter method optimization

[Dmitry Stogov]

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 only during optimization (it's especially 
used in inter-procedure data-flow pass).
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 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).




And I think the function info we pre-processed in the compile-time 
would help JIT to compile the opcode a lot.
Of course. Actually, the new optimization passes introduced in "master" 
branch came from our zend-jit project and reused to generate LLVM code.


By the way, would you mind to let me know the plan of implementing the 
JIT compilation in PHP? I saw your zend-jit branch is using LLVM as 
the backend.
We don't have special plans yet. We are going to work on JIT later, and 
now we mainly work on interpretative optimizations.
Once we start JIT, it's going to be much difficult to change something 
in VM...


In my experience, LLVM compiles large code a lot of slower.  what do 
you think of using DynASM as the JIT backend?

Right. LLVM is not suitable for JIT. It's a compiler without front-end part.
We will probably go with DynASM from LuaJIT, Low Level Interpreter from 
WebKit or our own similar approach.


V8 compiles ast nodes into native code directly without 
interpreting/translating the op codes, I don't know if it's a good 
approach to try. your thoughts?
In my experience, this approach doesn't work well especially with big 
PHP applications.


Thanks. Dmitry.


Cheers, Yo-An

Re: [PHP-DEV] Final properties

[Larry Garfield]

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 if at all possible, as it would also subsume this question quite nicely.)


And by Properties RFC you mean Property Accessors Syntax RFC right?
https://wiki.php.net/rfc/propertygetsetsyntax-v1.2


Yes, that thing.

--
--Larry Garfield


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] IntlCharsetDetector

[Bishop Bettini]

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's passed muster.
>
> > Ironically, PHPUnit attempts to detect UTF-8
> >
> Akward
>
> > I'd rather we include the patch for a few reasons:
> >
> > 1. so that there's a modern "standard" method of doing so, and that
> > "standard" method has plenty of documentation that points people to the
> > limitations.
> >
> In that spirit, how about we put in some stub documentation under the
> intl extension with a paragraph or two on why UCharsetDetector *isn't*
> wrapped, and why it's such a bad idea to try to solve the problem from
> this end.
>
> > 2. to completely expose the underlying ICU, rather than arbitrarily
> > deciding one part isn't good for developers to use.
> >
> Is it arbitrary though?  The fact that coming up with test cases which
> produce reasonable/expected results is half crap-shoot makes this an
> evidence based decision, not a capricious one.
>
> > 3. to provide an alternative to mb_detect_encoding.
> >
> And again in that spirit, I think this is a good argument for going
> E_DEPRECATED on mb_detect_encoding().  The entire conversation which
> led to prototyping an IntlCharsetDetector extension came from the fact
> that mb_detect_encoding() wasn't doing its job well.  Rather than have
> two supported, bad solutions, I think it'd be better to have one
> deprecated (and thus unsupported) bad solution (which is only kept for
> BC).
>
> > While I can't say if this will or won't cause more user confusion, I do
> > believe this adds value: ICU provides a confidence metric, which no other
> > in-built or buildable solution (to my knowledge) provides.
> >
> The confidence metric is useful, but my spidey sense tells me that
> it'll simply be ignored.
>
> How about a compromise.  I'll reorder this patch to be a standalone
> extension and we PECLize it.  If someone REALLY wants to throw caution
> to the wind, they can, but they're on their own when it gives them
> fugly results.


What about forcing the consumer to stipulate minimal acceptable confidence?
The API would internally filter any matches with confidence strictly lower
than the given value. Along the lines of:

ucsdet_detect(IntlCharsetDetector $det, int $minimum_confidence): array
ucsdet_detect_all(IntlCharsetDetector $det, int $minimum_confidence): array

So the relatively reliable UTF-8 test
 could be written:

if ('UTF-8' === $detector->detect(100)) {
// ...
}

This exposes the heuristics available in ICU and leaves the API flexible,
while forcing the consumer to consider the fact that this is statistical
reasoning, not decision.

Re: [PHP-DEV] Re: [RFC Proposal] Null Coalesce Equal Operator

[S.A.N]

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 $value
  static $value ??= $this->getValueFromDB();

  return $value;
 }
}

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Object getter method optimization

[Lin Yo-An]

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 we might have some optimization based on the function info
instead of optimizing opcode only in the future.

And I think the function info we pre-processed in the compile-time would
help JIT to compile the opcode a lot.

By the way, would you mind to let me know the plan of implementing the JIT
compilation in PHP? I saw your zend-jit branch is using LLVM as the backend.

In my experience, LLVM compiles large code a lot of slower.  what do you
think of using DynASM as the JIT backend?

V8 compiles ast nodes into native code directly without
interpreting/translating the op codes, I don't know if it's a good approach
to try. your thoughts?


Cheers, Yo-An

Re: [PHP-DEV] Final properties

[Lin Yo-An]

I would prefer putting the "final" keyword before the "public".

final public $items;

Since we should emphasis "final" rather than "public"

Re: [PHP-DEV] Final properties

[Quim Calpe]

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 using this term so it's a bit
awkward in that sense...


On Sat, Apr 9, 2016 at 4:54 PM, Niklas Keller  wrote:

> Readonly is already used in the documentation for some things in the DOM
> book. Writeonce sounds strange.
>
> Sebastian Bergmann  schrieb am Sa., 9. Apr. 2016 15:52:
>
> > Am 09.04.2016 um 12:55 schrieb Niklas Keller:
> > > Another possible choice would be "readonly".
> >
> >  Rather "writeonce", no?
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>

Re: [PHP-DEV] Final properties

[André Rømcke]

> 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 
> would also subsume this question quite nicely.)
> 

And by Properties RFC you mean Property Accessors Syntax RFC right?
https://wiki.php.net/rfc/propertygetsetsyntax-v1.2


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] NEUTRAL Benchmark Results for PHP Master 2016-04-11

[lp_benchmark_robot]

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
mem:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0, with hash 60fffd2 from
2015-12-01 04:16:47+00:00

---
benchmark   relative   change since   change since  
current rev run
std_dev*   last run   baseline  
   with PGO
---
:-|   Wordpress 4.2.2 cgi -T1  0.16% -0.44%  0.61%  
  7.12%
:-|   Drupal 7.36 cgi -T1  0.16%  0.59% -0.08%  
  4.15%
:-|   MediaWiki 1.23.9 cgi -T5000  0.18%  0.03%  1.56%  
  3.01%
:-|   bench.php cgi -T100  0.00%  0.02% 23.77%  
  2.00%
:-|  micro_bench.php cgi -T10  0.00%  0.01%  5.88%  
  4.30%
:-|  mandelbrot.php cgi -T100  0.06%  0.23% 28.93%  
  9.56%
---
* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/neutral-benchmark-results-for-php-master-2016-04-11/

Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
More details on measurements methodology at: 
https://01.org/lp/documentation/php-environment-setup.

Subject Label Legend:
Attributes are determined based on the performance evolution of the workloads
compared to the previous measurement iteration.
NEUTRAL: performance did not change by more than 1% for any workload
GOOD: performance improved by more than 1% for at least one workload and there
is no regression greater than 1%
BAD: performance dropped by more than 1% for at least one workload and there is
no improvement greater than 1%
UGLY: performance improved by more than 1% for at least one workload and also
dropped by more than 1% for at least one workload


Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php