Re: [PHP-DEV] [RFC DISCUSSION] User defined session serializer

[Yasuo Ohgaki]

Hi Markus,

On Sat, Nov 19, 2016 at 1:15 PM, Yasuo Ohgaki  wrote:
>> Btw, what is the proper way to signal a problem during
>> serialization/unserialization? I couldn't figure it out from the RFC nor
>> the PR and there doesn't seem to be a test case for it.
>> Return null/false? Throw an exception?

I added test and add return value description in RFC sample code.
Serialize function should return "string".
Unserialize function should return "array".
Anything other data type raises E_RECOVERABLE_ERROR, so returning
FALSE would be the reasonable choice to indicate error condition.

To all,

If there is no additional comment, I'll start vote in a few days.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

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

Re: [PHP-DEV] Re: [RFC] Debugging PDO Prepared Statement Emulation v2

[Matteo Beccati]

Hi Adam,

On 29/11/2016 00:16, Adam Baratz wrote:
> I'd be happy to make the feature more specific. The "Parsed" line would
> only show with emulated prepares enabled, after execute() has been called.
> I'd prefer using "Parsed" because the language would be more specific. It
> would also correspond to pdo_parse_params(), the function which does the
> emulation.

Sure, it might be the name of the function, but technically it's parsing
+ interpolation.

> Basically, you'd never see this kind of example:
> 
> SQL: "SELECT * FROM tbl WHERE x = ?"
>> Sent SQL: "SELECT * FROM tbl WHERE x = $1"
>>

why not? That's what active_query_string contains e.g. in pdo_pgsql w/o
emulate prepares. Which is more or less what has been sent to the
server, unless cursors are used. I don't see why it is deemed to be
not-useful or less useful than emulated prepares.

In fact it would come in very handy for extended tests of a bugfix I
have in the pipeline.

> I haven't tested, but I'm pretty sure the feature could be implemented by
> adding this block below the first php_stream_printf() call in
> debugDumpParams():
> 
> /* show parsed SQL if emulated prepares enabled */
>> /* pointers will be equal if PDO::query() was invoked */
>> if (stmt->active_query_string != NULL && stmt->active_query_string !=
>> stmt->query_string) {
>>   php_stream_printf(out, "Parsed SQL: [%zd] %.*s\n",
>> stmt->active_query_stringlen, (int) stmt->active_query_stringlen,
>> stmt->active_query_string);
>> }
> 
> 
> Let me know what you think of this approach. If it sounds fine, I'll update
> the RFC.

Possibly, but tbh I haven't had time to check.


Cheers
-- 
Matteo Beccati

Development & Consulting - http://www.beccati.com/

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

Re: [PHP-DEV] [RFC] Parameter No Type Variance

[Nikita Popov]

On Mon, Nov 21, 2016 at 10:39 AM, Niklas Keller  wrote:

> Morning Internals,
>
> I'd like to announce a RFC to allow omitting the type declarations for
> parameters in subclasses:
> https://wiki.php.net/rfc/parameter-no-type-variance
>
> PHP doesn't currently allow variance for parameters as checking these for
> compatibility isn't possible on compile time.
> This limitation is caused by autoloading and doesn't allow widening the
> accepted parameters.
>
> This RFC proposes to allow ommiting the type entirely in a subclass, as
> dropping all parameter constraints is
> always valid according to the LSP principle.
>
> We already allow return types being added in subclasses.
>
> Your feedback is welcome. :-)
>
> Regards, Niklas
>

The RFC is a bit lacking in motivation ...

The main practical use-case I see for this is post-hoc addition of
type-hints on an interface. To cite a particular example we ran into for
PHP 7.0: Derick added a DateTimeZone type hint for the third arg of the
DateTime::createFromFormat() method [1]. The method is already documented
to accept only this class in the manual, but the typehint is not actually
present in the implementation.

However, this change had to be reverted, because all classes extending
DateTime currently don't have this typehint (and adding it would be illegal
under LSP), so they started throwing a method signature mismatch warning.

Allowing extending classes to drop typehints in accordance with
variance-rules allow people to add additional parameter typehints on parent
classes without breaking BC. (Adding an additional return typehint would
break BC, but it is still a cross-version compatible change, as consumers
have the possibility of writing code that is valid under both versions --
something that is currently impossible if you want to add parameter
typehints.)

Thanks,
Nikita

[1]:
https://github.com/php/php-src/commit/8e19705a93d785cd1ff8ba3a69699b00169fea47

Re: [PHP-DEV] [RFC] Parameter No Type Variance

[Niklas Keller]

>
> But this leads to code that can't pass static inspections?
>

No.


> interface Joiner {
> public function join(array $array): string;
> }
>
> class WideJoiner implements Joiner {
> public function join($iterable): string {
> $array = is_array($iterable) ? $array :
> iterable_to_array($iterable);
>
> return implode(", ", $array);
> }
> }
>
> function joinWith(Joiner $joiner, $iterable) {
> return $joiner->join($iterable); // <-- invalid argument ?
> }
>

Yes, a static analysis engine should report invalid argument. If you depend
on another thing being accepted, you shouldn't declare just Joiner but
instead an extending interface or an implementation directly.


> According to the Joiner abstraction, only array is accepted, and that's
> all a static analysis tool can know about the $joiner argument in the
> joinWith() function.
>

Correct, that's why the static analysis engine should throw a warning on
that code.


> Being unable to pass static inspections is one thing, but this also makes
> the code generally difficult to explain
>

How so?


> there's a contract, Joiner, which states that an array is required - to a
> person reading the joinWith() function, that's all they can know about a
> Joiner instance
>

Correct.


> it isn't safe for anybody to depend on a specific implementation of Joiner
> with a widened argument-type
>

It is safe as long as you depend on the specific implementation or an
extended interface with the widened argument type.


> unless they read through the entire codebase and happen to know about the
> WideJoiner implementation, but even then, someone using the joinWith()
> function would also need to know which implementation of Joiner is being
> passed
>

You'd just declare that you depend on a Joiner that accepts also iterables.


> which seems to defeats the purpose of even having an abstraction in the
> first place?
>

So your argument is basically that contra-variance is never needed?

Regards, Niklas

Re: [PHP-DEV] [RFC] Parameter No Type Variance

[Rasmus Schultz]

But this leads to code that can't pass static inspections?

interface Joiner {
public function join(array $array): string;
}

class WideJoiner implements Joiner {
public function join($iterable): string {
$array = is_array($iterable) ? $array :
iterable_to_array($iterable);

return implode(", ", $array);
}
}

function joinWith(Joiner $joiner, $iterable) {
return $joiner->join($iterable); // <-- invalid argument ?
}

According to the Joiner abstraction, only array is accepted, and that's all
a static analysis tool can know about the $joiner argument in the
joinWith() function.

Being unable to pass static inspections is one thing, but this also makes
the code generally difficult to explain - there's a contract, Joiner, which
states that an array is required - to a person reading the joinWith()
function, that's all they can know about a Joiner instance; it isn't safe
for anybody to depend on a specific implementation of Joiner with a widened
argument-type, unless they read through the entire codebase and happen to
know about the WideJoiner implementation, but even then, someone using the
joinWith() function would also need to know which implementation of Joiner
is being passed, which seems to defeats the purpose of even having an
abstraction in the first place?


On Mon, Nov 21, 2016 at 10:39 AM, Niklas Keller  wrote:

> Morning Internals,
>
> I'd like to announce a RFC to allow omitting the type declarations for
> parameters in subclasses:
> https://wiki.php.net/rfc/parameter-no-type-variance
>
> PHP doesn't currently allow variance for parameters as checking these for
> compatibility isn't possible on compile time.
> This limitation is caused by autoloading and doesn't allow widening the
> accepted parameters.
>
> This RFC proposes to allow ommiting the type entirely in a subclass, as
> dropping all parameter constraints is
> always valid according to the LSP principle.
>
> We already allow return types being added in subclasses.
>
> Your feedback is welcome. :-)
>
> Regards, Niklas
>

[PHP-DEV] UGLY Benchmark Results for PHP Master 2016-11-29

[lp_benchmark_robot]

Results for project PHP master, build date 2016-11-29 06:26:31+02:00
commit: d1f9d37
previous commit:f0ba9ab
revision date:  2016-11-29 06:45:01+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.13%  0.68% -0.16%  
  7.41%
:-|   Drupal 7.36 cgi -T1  0.28%  0.31% -0.23%  
  3.40%
:-|   MediaWiki 1.23.9 cgi -T5000  0.09%  0.22%  2.36%  
  3.14%
:-)   bench.php cgi -T100  0.01%  1.57% 33.00%  
 -0.50%
:-)  micro_bench.php cgi -T10  0.05%  1.23% 12.96%  
  3.63%
:-(  mandelbrot.php cgi -T100  0.06% -3.15% 29.53%  
 -6.02%
---

* Relative Standard Deviation (Standard Deviation/Average)

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

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

[PHP-DEV] Re: [RFC] Parameter No Type Variance

[Jan Altensen]

no please no "mixed" keyword

my idea to this is having something like this:

class Foo { public function test (int $a) : int { return $a; } }
class Bar extends Foo { override public function test (string $a) :
string { return $a; } }
class FooBar extends Foo { override public function test ($a) { return
$a; } }

or maybe this too
class Bar extends Foo { override private function test (string $a) :
string { return $a; } }

so you have to mark the override explicitly
if you leave the override keyword it still throws a fatal error

dunno if this is a good idea or not, just my 2 cents

Regards,
Jan Altensen (Stricted)

Am 26.11.2016 um 16:54 schrieb Niklas Keller:
> 2016-11-21 12:59 GMT+01:00 Christoph M. Becker :
> 
>> On 21.11.2016 at 10:39, Niklas Keller wrote:
>>
>>> I'd like to announce a RFC to allow omitting the type declarations for
>>> parameters in subclasses:
>>> https://wiki.php.net/rfc/parameter-no-type-variance
>>>
>>> PHP doesn't currently allow variance for parameters as checking these for
>>> compatibility isn't possible on compile time.
>>> This limitation is caused by autoloading and doesn't allow widening the
>>> accepted parameters.
>>>
>>> This RFC proposes to allow ommiting the type entirely in a subclass, as
>>> dropping all parameter constraints is
>>> always valid according to the LSP principle.
>>
>> Have you considered that instead of simply omitting the type
>> declaration, one would have to mark the omission explicitly, to still
>> get a compile time warning in case of unintended omission
>>
> 
> No, not really. While we could use "mixed" there, those signatures _are_
> compatible without it and shouldn't throw a warning.
> 
> Anyone else interested in the usage of "mixed" as an explicit type
> declaration?
> 


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