Re: [PHP-DEV] Re: [VOTE] PDO Float Type

[Matteo Beccati]

Hi Adam,

On 15/05/2017 14:54, Adam Baratz wrote:
>> You can't possibly think that changing the constant name resets the
>> cooldown counter.
> 
> I don't. I posted a new version of the RFC on May 1st. These are the notes
> I sent to this list:
> 
> Most of the discussion in the last round was about fixed precision types.
>> Since there was a lot of disagreement around the right way to handle them,
>> I'd like to keep them out of this RFC. I know Matteo wanted to get them
>> into this RFC, but I'd rather do less if it increases the chances that a
>> group can agree. Nothing in this RFC should interfere with a future
>> implementation of fixed precision types.

If you search the archives, you might find that I wasn't happy to have
PARAM_FLOAT without some kind of PARAM_NUMERIC. You're basically saying
that my point was irrelevant and out of scope. Aww, thanks ;)


> I added a PR to show how this feature would be implemented. It should make
>> it clear that very little change is needed to open up this functionality. I
>> avoided mixing in type casts or any special formatting to keep things safe
>> and simple. This allowed me to streamline the examples in the RFC quite a
>> bit.

The PR could be a 1-liner, but it's the concept behind it that I dislike.


> It would be helpful to get feedback from anyone who voted "no" previously,
>> but didn't comment in the thread. There's no need to talk through this RFC
>> again if everyone in that group wants fixed precision types to be included.
> 
> I think this changes the substance of the proposal, in which case there
> wouldn't need to be a cooldown period. It's okay if you disagree, but you
> can say so much instead of accusing me of acting in bad faith.

You did get feedback and one of the most prominent PDO users around
seems to agree that it's a fairly bad idea. Do you need more?

He also raised concerns about the cooldown period and you are claiming
that this is a brand new RFC because you've cleaned it up and shoved
some of the biggest concerns into the "out of scope" section.


> I don't know how my emails come across. I apologize if I seem antagonistic.
> I'm not trying to rile you up. I'm just an engineer trying to figure out
> how to solve a technical problem. And I'm trying to get a solution that
> will please as many people as possible, including you.

I thank you for your efforts, but, again, out-of-scoping other people's
concerns can't possibly come around as a pleasing solution.

And it's a solution that possibly affects the teeny tiny percentage of
PHP users wanting to optimize queries involving float parameters when
using pdo_dblib. A potential foot-gun for everyone else.


> You could quite easily work around it by embedding your floats in the
>> SQL command string instead. Which is basically what emulated prepares
>> would do for you.
>>
> Yes, that would generate the right query, but it could make it difficult to
> improve its execution plan in the future.
> 
> For example, I'm looking into an approach that would bring real prepared
> statements to pdo_dblib:
> https://bugs.php.net/bug.php?id=74592

No offence, but those look like pretty ugly hacks and poor attempts to
overcome what's a huge limitation of the underlying library.

I understand the power of legacy, since I'm running one very legacy
project myself, but please do yourself a favour and help out the
transition away from something as poor as dblib rather than trying to
build your own custom prepared statement emulator. Maybe your skills and
enthusiasm could be helpful to the pdo_sqlsrv team and the driver could
become core at some point?


> If float parameters aren't bound, each value would result in a new
> execution plan, which would negate a lot of the benefit of having prepared
> statements.

Since your driver uses emulated prepares, I'd expect you having a new
execution plan regardless. At least for current master, which is the RFC
target.


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] deprecate PDO::PARAM_NULL

[Matteo Beccati]

Hi Adam,

On 15/05/2017 13:49, Adam Baratz wrote:
> I've heard a few people here mention that this type isn't useful. It looks
> like it wouldn't be harmful to remove. The RFC mainly outlines the impact
> and proposes a schedule for doing so.
> 
> https://wiki.php.net/rfc/deprecate_pdo_null
> 
> Please let me know your thoughts.

Please elaborate:

"A handful of people on the internals mail list have asked for it to be
removed" - where and when?

"Supporting it adds some weight to PDO" what kind of weight? How many
lines / microseconds are we going to save?

I would agree that NULL is not a type and the constant shouldn't have
been there in the first place, but I think it could be a bit too late now.

The proposal itself is rather evil: it would break lots of code (a quick
github search shows 95k+ results) for basically no gain. Or maybe I just
didn't get it.


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] PDO Parameter types // PDO::PARAM_AUTO

[Matteo Beccati]

Hi Dorin,

On 15/05/2017 18:22, Dorin Marcoci wrote:
> Currently PDOStatement::bindValue is declared as
> 
> public bool PDOStatement::bindValue ( mixed $parameter , mixed $value [, int
> $data_type = PDO::PARAM_STR ] )
> 
> where third parameter is data type, string type as default.
> 
> It may be useful in terms of providing meta info and handle it accordingly,
> like quote, cast or do some additional stuff.
> 
> But there are DBMSes where this "feature" is more a burden than a helper.

Please elaborate.

> It's because after PDO::prepare, driver and server already knows all
> statement parameters and expected types.
> 
> Yes, it can be "forced", saying to pass for a integer parameter a string
> value, server will convert it to required type.
> 
> It is convenient in most cases to pass them as strings, for example by
> simply assign all params in a cycle before execute.

The thing is: the server (with non-emulated prepares) knows the data
type it's expecting. PHP has no knowledge of it, so you are expected to
do so if the default (string) is not ok.


> But when implementing FB Boolean data type parameters and doing ->bindValue
> ('bool_param', false) I get an empty string internally.
> 
> Yes, true ZVAL is converted as string as '1', but false as an empty string,
> not so consistent here ;)

That's not true.

$p = new PDO("pgsql:dbname=postgres");
$p->prepare("SELECT ?::bool");
$s->bindValue(1, false);
$s->execute();
var_dump($s->fetchColumn());'

outputs:

bool(false)

What are you referring to?


> That's why I think, it will be great to have a special type like
> PDO::PARAM_AUTO and a config flag to set it as default instead of PARAM_STR.

Config flags are evil as it's one more thing you'd need to be aware of
and could change depending on the environment you run your script or
library on.


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] Implement formal process for run-tests.php refactor

[Johannes Schlüter]

On Mi, 2017-05-17 at 23:30 +0200, Marco Pivetta wrote:
> Is Sebastian copied in here? Why can't we just use the super-battle-
> tested
> PHPUnit? It supports phpt and a ton of plugins, plus everyone uses it
> and
> is familiar with it.

PHPUnit is huge. run-tests is a small script in a single file which I
can quickly edit. For PHPUnit I have multiple files and need tooling to
phar them up.

PHPUnit (according to it's website) also has more dependencies (DOM and
JSON) which are not included in --disable-all. used

I'm not sure if PHPUnit meanwhile supports redirect tests as in PDO.

Is there a performance comparison? - make test runs for a lng time.
A difference might have an impact. (both ways round ;) )



To the original question: Granting run-tests.php karma is trivial. We
can easily give access to people working on it. While contributors
should be aware that this is a key component f the PHP development :-)

johannes


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

Re: [PHP-DEV] Fwd: PHP7 extension to control raspberry GPIO

[Johannes Schlüter]

Bonsoir,

On Do, 2017-05-11 at 14:25 +0200, simon .barotte wrote:
> code in order to advise me, or to guide me on some point to improve .
> 
> The code is available here : gpio_extension
> 

I had a *quick* look so this is no proper review, but a few comments:
Please check your indention, there seem to be tabs and spaces mixed
(PHP typically uses tabs)

I see you've added the GPLv3 as LICENSE file, while all files state
it's licensed under PHP License 3.01. Mind that PHP License and GPL are
incompatible.

The le_gpio_extension declaration can be removed. That's added by
ext_skel and could be used for registering a resource (which shouldn't
be done anymore ... probably one could patch ext_skel to get rid of
this)

stdbool.h is C99. For a stand-alone extension this is fine, for core
PHP we however didn't agree to use C99, yet (unless I missed the
switch, which could happen, I don't follow closely)

PHP_METHOD(Gpio, __construct)  seems to abuse return_value.

In general it is also bad to change the return_value before
callingzend_parse_parameters ... but here we're in a constructor so it
shouldn't matter much.

You shouldn't use zend_error, that's for the engine. Use
php_error_docref. Also don't use E_ERROR. E_ERROR is for critical
situations where the engine can hardly continue running. Probably you
want a custom exception.

In your MINIT you allocate
   zval *cd = (zval*)malloc(sizeof(zval));
but never use it. Related: Many people discourage casting malloc's
return value http://stackoverflow.com/a/605858/206302

You mix long and int types. If you have a 32bit system that is no
problem, but as soon as you use a 64 bit system this leads to issues.
i.e. this:
   static int readPin(int pin);
   zend_long pin;
   result = readPin(pin);

Another comment about readPin: If reading failes you don't close the
file handle.

You might also be interested in those common comments I include in such
reviews: https://wiki.php.net/internals/review_comments

And as a final thought: I think this is a great training thing! However
I don't see anything which *Requires* doing this in an extension. Doing
this in pure PHP should work with neglectable overhead.

johannes


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

[PHP-DEV] BAD Benchmark Results for PHP Master 2017-05-16

[lp_benchmark_robot]

Results for project PHP master, build date 2017-05-16 19:25:48-07:00
commit: 774e7ea
previous commit:7de2b21
revision date:  2017-05-16 15:10:13+02: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.17% -0.79% -0.50%  
  8.91%
:-|   Drupal 7.36 cgi -T1  0.14%  0.02%  0.50%  
  4.87%
:-|   MediaWiki 1.23.9 cgi -T5000  0.08% -0.15%  2.01%  
  3.52%
:-|   bench.php cgi -T100  0.05% -0.05% 37.81%  
 -2.15%
:-|  micro_bench.php cgi -T10  0.01% -0.18% 17.16%  
  1.11%
:-(  mandelbrot.php cgi -T100  0.22% -4.16% 29.02%  
 -6.42%
---

* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/bad-benchmark-results-for-php-master-2017-05-16/

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

Re: [PHP-DEV] Implement formal process for run-tests.php refactor

[Marco Pivetta]

Is Sebastian copied in here? Why can't we just use the super-battle-tested
PHPUnit? It supports phpt and a ton of plugins, plus everyone uses it and
is familiar with it.

Am I missing something?

On 17 May 2017 7:18 p.m., "Fleshgrinder"  wrote:

> I like the idea and the proposed approach. I would also offer my help
> with anything here. What I would definitely avoid is moving this out of
> the PHP repository itself. Ideally we get to a point where people enter
> a single command and it does take care of everything (given that the
> required dependencies are present on the system, e.g. a working git,
> make, etc.).
>
> --
> Richard "Fleshgrinder" Fussenegger
>
>

Re: [PHP-DEV] Implement formal process for run-tests.php refactor

[Fleshgrinder]

I like the idea and the proposed approach. I would also offer my help
with anything here. What I would definitely avoid is moving this out of
the PHP repository itself. Ideally we get to a point where people enter
a single command and it does take care of everything (given that the
required dependencies are present on the system, e.g. a working git,
make, etc.).

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] [VOTE] Object typehint RFC

[Michał Brzuchalski]

2017-05-17 19:12 GMT+02:00 Dan Ackroyd :

> > We were thinking about enumerations
>
> Who do you mean 'we', kemosabe?
>

My apologies. I was a little hurry.


>
> > Especially when taking Java pattern
>
> Java has been limited in its design as almost everything had to be an
> object, whether or not it was a good fit for what was needed.
>
> For me, objects are good at storing state, hiding implementation
> details and allowing type substitution.pretty much none of those
> things apply to enums, and so make me think that forcing enums to be
> objects isn't always the right thing to do.
>
> cheers
> Dan
>



-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] [RFC] [VOTE] Object typehint RFC

[Michał Brzuchalski]

2017-05-17 18:43 GMT+02:00 Levi Morrison :

> I'm not intending to derail the thread but let's consider your statement:
> your proposal constrains us to choosing something Java-like instead of
> having all options. Think closely about that: you are advocating that we
> constrain us to Java-like enums when there are many, many options and we
> get what for that trade-off? A simpler way to implement variance for the
> object-type only? No thanks.


No offence Levi, it was just an example of enums implementation.
Maybe I should not now point it in this thread.
My apologies.


-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] [RFC] [VOTE] Object typehint RFC

[Dan Ackroyd]

> We were thinking about enumerations

Who do you mean 'we', kemosabe?

> Especially when taking Java pattern

Java has been limited in its design as almost everything had to be an
object, whether or not it was a good fit for what was needed.

For me, objects are good at storing state, hiding implementation
details and allowing type substitution.pretty much none of those
things apply to enums, and so make me think that forcing enums to be
objects isn't always the right thing to do.

cheers
Dan

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

Re: [PHP-DEV] [RFC] [VOTE] Object typehint RFC

[Levi Morrison]

On Wed, May 17, 2017 at 10:26 AM, Michał Brzuchalski  wrote:

> Thank your Levi for your explanation.
>
> 2017-05-17 16:47 GMT+02:00 Levi Morrison :
>
>>
>>
>> On Wed, May 17, 2017 at 4:34 AM, Michał Brzuchalski <
>> mic...@brzuchalski.com> wrote:
>>
>>> Hi everyone,
>>>
>>> I would like to put Object Type RFC up to a vote for inclusion in PHP
>>> 7.2.
>>>
>>> Previously there were some concerns about adding named types in the
>>> future,
>>> but we came to the conclusion that each of them can be solved if there
>>> are
>>> proposals in the future.
>>>
>>> Voting starts today, 2017-05-17, and will close after two weeks on the
>>> Wednesday 2017-05-31 at midnight.
>>>
>>> The RFC and voting widget can be found here: https://wiki.php.net/
>>> rfc/object-typehint 
>>>
>>> The vote is a straight Yes/No vote for accepting the RFC and merging the
>>> patch which require 2/3 majority.
>>> The additional vote is also a straight Yes/No vote for accepting variance
>>> behaviour on the object type which also require 2/3 majority.
>>>
>>> Thanks!
>>> --
>>> regards / pozdrawiam,
>>> --
>>> Michał Brzuchalski
>>> about.me/brzuchal
>>> brzuchalski.com
>>>
>>
>> An emphatic "no" on variance for me. This is for two over-arching reasons:
>>
>>   1. Object variance should be implemented when we have generalized
>> variance for all types. By special casing it now we open ourselves to the
>> possibility that its implementation or semantics will differ from the
>> generalized solution.
>>
>>   2. The way it is implemented prevents us from adding new types which
>> are not objects. The reason is that the way this is implemented it just
>> assumes that an unknown type is an object type. If we add a feature such as
>> an enumerations (enums) this assumption probably breaks and cannot be fixed
>> while maintaining BC as it would almost certainly need to trigger an
>> autoload.
>>
>>
> We were thinking about enumerations and generally IMHO, they can be
> implemented as objects though. Especially when taking Java pattern
> http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html when dealing
> with enumeration means dealing with a special purpose and special kind of
> objects, which are IMO more powerful with methods which can implement some
> behaviour.
>

I'm not intending to derail the thread but let's consider your statement:
your proposal constrains us to choosing something Java-like instead of
having all options. Think closely about that: you are advocating that we
constrain us to Java-like enums when there are many, many options and we
get what for that trade-off? A simpler way to implement variance for the
object-type only? No thanks.

Re: [PHP-DEV] [RFC] [VOTE] Object typehint RFC

[Michał Brzuchalski]

Thank your Levi for your explanation.

2017-05-17 16:47 GMT+02:00 Levi Morrison :

>
>
> On Wed, May 17, 2017 at 4:34 AM, Michał Brzuchalski <
> mic...@brzuchalski.com> wrote:
>
>> Hi everyone,
>>
>> I would like to put Object Type RFC up to a vote for inclusion in PHP 7.2.
>>
>> Previously there were some concerns about adding named types in the
>> future,
>> but we came to the conclusion that each of them can be solved if there are
>> proposals in the future.
>>
>> Voting starts today, 2017-05-17, and will close after two weeks on the
>> Wednesday 2017-05-31 at midnight.
>>
>> The RFC and voting widget can be found here: https://wiki.php.net/
>> rfc/object-typehint 
>>
>> The vote is a straight Yes/No vote for accepting the RFC and merging the
>> patch which require 2/3 majority.
>> The additional vote is also a straight Yes/No vote for accepting variance
>> behaviour on the object type which also require 2/3 majority.
>>
>> Thanks!
>> --
>> regards / pozdrawiam,
>> --
>> Michał Brzuchalski
>> about.me/brzuchal
>> brzuchalski.com
>>
>
> An emphatic "no" on variance for me. This is for two over-arching reasons:
>
>   1. Object variance should be implemented when we have generalized
> variance for all types. By special casing it now we open ourselves to the
> possibility that its implementation or semantics will differ from the
> generalized solution.
>
>   2. The way it is implemented prevents us from adding new types which are
> not objects. The reason is that the way this is implemented it just assumes
> that an unknown type is an object type. If we add a feature such as an
> enumerations (enums) this assumption probably breaks and cannot be fixed
> while maintaining BC as it would almost certainly need to trigger an
> autoload.
>
>
We were thinking about enumerations and generally IMHO, they can be
implemented as objects though. Especially when taking Java pattern
http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html when dealing
with enumeration means dealing with a special purpose and special kind of
objects, which are IMO more powerful with methods which can implement some
behaviour.



> Given these two points I think it's unwise to implement variance as
> outlined. I highly encourage other voters to vote against that portion of
> the RFC.
>
> -
>
> Lastly, I want to thank Dan and Michal for working on this RFC as an
> object type even without variance would have been useful for me in the past.
>



-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] [RFC] [VOTE] Object typehint RFC

[Sebastian Bergmann]

On 05/17/2017 04:47 PM, Levi Morrison wrote:

An emphatic "no" on variance for me. This is for two over-arching reasons:


Thank you, Levi, for the explanation of your "no" vote on object 
variance. That saved me quite a bit of typing :-)


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

Re: [PHP-DEV] Implement formal process for run-tests.php refactor

[li...@rhsoft.net]

Am 17.05.2017 um 17:00 schrieb Andreas Heigl:







seriously a signature on top breaks reply and quotes for any sane MUA 
which strips signatures and so quotes only stuff on top of the "-- " 
line


> Just a stupid question for a non-regular: Why not a
> separate repo? In the end run-tests.php is a PHP-application
> and not a C one and with tests and all such things to do
> it might be wasier to develop independent from the PHP-sources.

that's invisible for endusers

> It needs to be available to the PHP-sources in the end, but that 
might > be possible by using git-submodules (or downloading a phar-file?)


a sane RPM build is using "run-tests.php" after compilation abd before 
generate the final packages


* configure
* make prof-gen
* run application code
* make prof-clean
* make prof-use
* run-tests.sh
* build rpm packages


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

Re: [PHP-DEV] Implement formal process for run-tests.php refactor

[Andreas Heigl]

-- 
Andreas Heigl
andr...@heigl.org
> Am 17.05.2017 um 16:28 schrieb Sammy Kaye Powers :
> 
> Hello internals folks!
> 
> As you may already know, run-tests.php is an old legacy app that is in
> serious need of a refactor. Some things that are badly needed amongst other
> things are:
> 
> - Better maintainability
> - Unit tests
> - Concurrency
> - Prettier output
> 
> I have seen numerous attempts of rewriting run-tests from scratch after
> some rallying at a UG or PHP conference only to see the initial excitement
> die off. The general advice for refactoring legacy apps is to not start
> with a clean slate, rather refactor a little bit at a time. We should treat
> run-tests as we would any other legacy app.
> 
> We need a structured process to allow the run-tests app to get refactored a
> little bit at a time. I propose the following (open to discussion of
> course).
> 
> 1) Create a new run-tests karma with access to php-src.git/run-tests.php
> (and hopefully the soon-to-be created php-src.git/run-tests folder).

Just a stupid question for a non-regular: Why not a separate repo? In the end 
run-tests.php is a PHP-application and not a C one and with tests and all such 
things to do it might be wasier to develop independent from the PHP-sources. 

It needs to be available to the PHP-sources in the end, but that might be 
possible by using git-submodules (or downloading a phar-file?)

Just my 0.02€

Cheers 

Andreas
> 
> 2) Elect 2-3 people and grant the new run-tests karma to them. They will
> champion the PR's that incrementally improve run-tests.
> 
> 3) The new run-tests champions (we'll call them "champions" because, why
> not?) will run the entire test suite ensuring that the refactor didn't
> inadvertently break the functionality and if all good, merge. (We might be
> able to get a solid Docker container or an automated CI process for an
> end-to-end test - thoughts?)
> 
> 4) The run-tests champions could be elected for a year-long term with the
> possibility of being reelected for another year commitment. This would help
> prevent run-test champion drop-off (because sometimes, life happens).
> 
> Once we get a process in place, I've drafted up a possible proposal of next
> steps to get run-tests refactoring kicked off:
> 
> https://github.com/SammyK/run-tests#proposed-refactoring-path
> 
> It's time to circle the wagons on run-tests! :)
> 
> Thanks,
> Sammy Kaye Powers
> sammyk.me
> 
> 230 S Clark St #194
> Chicago, IL 60604


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

Re: [PHP-DEV] [RFC] [VOTE] Object typehint RFC

[Andrey Andreev]

Hi,

On Wed, May 17, 2017 at 5:47 PM, Levi Morrison  wrote:
>
>   1. Object variance should be implemented when we have generalized
> variance for all types. By special casing it now we open ourselves to the
> possibility that its implementation or semantics will differ from the
> generalized solution.
>

That's a very good point.

It may even decide how variance works in all of PHP, "because consistency".

Cheers,
Andrey.

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

Re: [PHP-DEV] [RFC] [VOTE] Object typehint RFC

[Levi Morrison]

On Wed, May 17, 2017 at 4:34 AM, Michał Brzuchalski 
wrote:

> Hi everyone,
>
> I would like to put Object Type RFC up to a vote for inclusion in PHP 7.2.
>
> Previously there were some concerns about adding named types in the future,
> but we came to the conclusion that each of them can be solved if there are
> proposals in the future.
>
> Voting starts today, 2017-05-17, and will close after two weeks on the
> Wednesday 2017-05-31 at midnight.
>
> The RFC and voting widget can be found here: https://wiki.php.net/
> rfc/object-typehint
>
> The vote is a straight Yes/No vote for accepting the RFC and merging the
> patch which require 2/3 majority.
> The additional vote is also a straight Yes/No vote for accepting variance
> behaviour on the object type which also require 2/3 majority.
>
> Thanks!
> --
> regards / pozdrawiam,
> --
> Michał Brzuchalski
> about.me/brzuchal
> brzuchalski.com
>

An emphatic "no" on variance for me. This is for two over-arching reasons:

  1. Object variance should be implemented when we have generalized
variance for all types. By special casing it now we open ourselves to the
possibility that its implementation or semantics will differ from the
generalized solution.

  2. The way it is implemented prevents us from adding new types which are
not objects. The reason is that the way this is implemented it just assumes
that an unknown type is an object type. If we add a feature such as an
enumerations (enums) this assumption probably breaks and cannot be fixed
while maintaining BC as it would almost certainly need to trigger an
autoload.

Given these two points I think it's unwise to implement variance as
outlined. I highly encourage other voters to vote against that portion of
the RFC.

-

Lastly, I want to thank Dan and Michal for working on this RFC as an object
type even without variance would have been useful for me in the past.

Re: [PHP-DEV] messages not delivering?

[Ryan Pallas]

On Wed, May 17, 2017 at 8:25 AM, Adam Baratz  wrote:

> > > I'm think this problem might've cropped up again. I didn't receive this
> > > message:
> > > http://news.php.net/php.internals/99052
> > >
> > > I only heard about it because it was mentioned in a PR thread.
> > >
> >
> > I remember finding this one in the Spam dir (Gmail). It appears that
> > DMARC validation failed for it.
> >
> Weird, didn't see it in mine, also Gmail, at all.
>

Yeah, I also can't find it. Also on gmail.

[PHP-DEV] Implement formal process for run-tests.php refactor

[Sammy Kaye Powers]

Hello internals folks!

As you may already know, run-tests.php is an old legacy app that is in
serious need of a refactor. Some things that are badly needed amongst other
things are:

- Better maintainability
- Unit tests
- Concurrency
- Prettier output

I have seen numerous attempts of rewriting run-tests from scratch after
some rallying at a UG or PHP conference only to see the initial excitement
die off. The general advice for refactoring legacy apps is to not start
with a clean slate, rather refactor a little bit at a time. We should treat
run-tests as we would any other legacy app.

We need a structured process to allow the run-tests app to get refactored a
little bit at a time. I propose the following (open to discussion of
course).

1) Create a new run-tests karma with access to php-src.git/run-tests.php
(and hopefully the soon-to-be created php-src.git/run-tests folder).

2) Elect 2-3 people and grant the new run-tests karma to them. They will
champion the PR's that incrementally improve run-tests.

3) The new run-tests champions (we'll call them "champions" because, why
not?) will run the entire test suite ensuring that the refactor didn't
inadvertently break the functionality and if all good, merge. (We might be
able to get a solid Docker container or an automated CI process for an
end-to-end test - thoughts?)

4) The run-tests champions could be elected for a year-long term with the
possibility of being reelected for another year commitment. This would help
prevent run-test champion drop-off (because sometimes, life happens).

Once we get a process in place, I've drafted up a possible proposal of next
steps to get run-tests refactoring kicked off:

https://github.com/SammyK/run-tests#proposed-refactoring-path

It's time to circle the wagons on run-tests! :)

Thanks,
Sammy Kaye Powers
sammyk.me

230 S Clark St #194
Chicago, IL 60604

Re: [PHP-DEV] messages not delivering?

[Matteo Beccati]

Hi Adam,

On 17/05/2017 15:42, Adam Baratz wrote:
> Hi,
> 
> I'm think this problem might've cropped up again. I didn't receive this
> message:
> http://news.php.net/php.internals/99052
> 
> I only heard about it because it was mentioned in a PR thread.
> 
> Similarly, I'm wondering if some messages in this thread weren't getting
> delivered:
> http://news.php.net/php.internals/99041
> 
> At least, some of the responses I was getting made it seem like Matteo and
> Marco didn't get all of my posts.

I have received both but I just haven't had time to reply.

FWIW, I still think that both _FLOAT and _AUTO are very bad ideas.

About _NULL, I'm just worried about the potential BC break caused by the
sudden deprecation, for a little-to-none gain. But I haven't looked the
issue into much detail.

Hopefully I'll have more time in the next few days.


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] messages not delivering?

[Adam Baratz]

> > I'm think this problem might've cropped up again. I didn't receive this
> > message:
> > http://news.php.net/php.internals/99052
> >
> > I only heard about it because it was mentioned in a PR thread.
> >
>
> I remember finding this one in the Spam dir (Gmail). It appears that
> DMARC validation failed for it.
>
Weird, didn't see it in mine, also Gmail, at all.

Re: [PHP-DEV] messages not delivering?

[Andrey Andreev]

Hi Adam,

On Wed, May 17, 2017 at 4:42 PM, Adam Baratz  wrote:
> Hi,
>
> I'm think this problem might've cropped up again. I didn't receive this
> message:
> http://news.php.net/php.internals/99052
>
> I only heard about it because it was mentioned in a PR thread.
>

I remember finding this one in the Spam dir (Gmail). It appears that
DMARC validation failed for it.

Cheers,
Andrey.

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

[PHP-DEV] messages not delivering?

[Adam Baratz]

Hi,

I'm think this problem might've cropped up again. I didn't receive this
message:
http://news.php.net/php.internals/99052

I only heard about it because it was mentioned in a PR thread.

Similarly, I'm wondering if some messages in this thread weren't getting
delivered:
http://news.php.net/php.internals/99041

At least, some of the responses I was getting made it seem like Matteo and
Marco didn't get all of my posts.

Thanks,
Adam

[PHP-DEV] [RFC] [VOTE] Object typehint RFC

[Michał Brzuchalski]

Hi everyone,

I would like to put Object Type RFC up to a vote for inclusion in PHP 7.2.

Previously there were some concerns about adding named types in the future,
but we came to the conclusion that each of them can be solved if there are
proposals in the future.

Voting starts today, 2017-05-17, and will close after two weeks on the
Wednesday 2017-05-31 at midnight.

The RFC and voting widget can be found here: https://wiki.php.net/
rfc/object-typehint

The vote is a straight Yes/No vote for accepting the RFC and merging the
patch which require 2/3 majority.
The additional vote is also a straight Yes/No vote for accepting variance
behaviour on the object type which also require 2/3 majority.

Thanks!
-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] BC break in master (7.2) - Distinguish betweenunmatchedsubpatterns and empty matches in preg_*()

[Nicolas Grekas]

>
> PREG_SKIP_UNMATCHED instead of PREG_UNMATCHED_AS_NULL.
>

I'm just wondering if having holes in the resulting array is a good idea.
It may complicate reading dumps and forces using "foreach" vs "for". I'm
also wondering if the original proposal wouldn't be better (having NULL for
*all* nonmatches, even trailing ones), if possible.

Anyway, I'm fine with either. It's just out of my skills right now so feel
free to take over my PR ... sorry.

Nicolas