[PHP-DEV] Potential binary search optimization or feature
Recently, as part of school course on optimization, I have identified a potential optimization or feature for PHP. After looking through the array.c file(located in etc/standard in the PHP source code), I noticed that both the in_array and array_search are using the linear search C function php_search_array. The potential issue I see is that even though the linear search algorithm does not drastically effect performance when searching a relatively small array, it may slow performance down when iterating through a very large array(couple of million indexes). To back this fact up I preformed some benchmarks using a PHP script that measures the time it takes to preform a linear search and binary search. The benchmark was in favor of the binary search as it found its target many times quicker compared to the linear search. After researching more about different PHP search functions, I was not able to find one that uses a binary search algorithm. Based on these factors I believe that a binary search implementation into PHP will prove useful in certain situations and would like to implement that feature. At the moment I am debating between adding a separate binary search based function into array.c or modifying the current array_search_array function to utilize a binary search algorithm. Since the requirement for a binary search is that the array being searched is sorted, I thought is would be a good idea to have a Boolean parameter in the binary search function to specify if the input array should be sorted or not. something among the lines of function binary_search(string target, array arrayToSearch, bool sort). Doing this, the function can preform a sort if required to, thus not needing to sort a array that is already sorted. Before I can begin the implementation and create a pull request, I would like to know the PHP's community feedback on my potential contribution and if this is a wise feature to change or implement.
Re: [PHP-DEV] JSON float number as string
Hi Pierre,
On Mon, Mar 30, 2015 at 11:42 AM, Pierre Joye pierre@gmail.com wrote:
On Mon, Mar 30, 2015 at 9:14 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Pierre,
On Mon, Mar 30, 2015 at 10:54 AM, Pierre Joye pierre@gmail.com
wrote:
Same effects but totally unrelated topics. All functions dealing with
large external numbers had the same issues, since ever. It has nothing
to do with STH.
Yes, it is.
Developers make casting mistakes like this even when they are used to
strict
typing.
I understand and this is why I said it is the same symptom. But JSON
or any other external data decoding has nothing to do with STH. It
would be nice to do not clutter this discussion with yet another STH
argument :)
As you know, I'm an very unhappy person with the accepted RFC :)
Since Zeev closed the vote before the end date, I think we may have a little
chance to improve weak mode scalar type hint. i.e. Use Zeev's RFC for weak
mode.
Anyway, similar issue is not only external but also PHP internal.
For example,
[yohgaki@dev php-src]$ ./php-bin -r 'var_dump([9=1,
9=1]);'
array(2) {
[9]=
int(1)
[3875820019684212736]=
int(1)
}
Library that deals with array should use string key data type to have
correct key for
any number even when library expects integer keys. i.e. The library must
have string type hint for integer key to achieve correct behavior.
Database, JSON and array are good examples of confusions. Smart developers
will use string type hints for these, while less experienced developers
will use
int/float type hints for these. When users have to use both of them,
users are
forced to casting variable between string and int/float. This makes
impossible
to write correct code. This JSON bug is a proof that this will happen.
I just don't see the point to introduce new feature that makes impossible
to write
correct code while there is good solution. Fortunately, we still have time
to address
this.
Regards,
P.S. Does anyone have alternative ideas for this?
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] JSON float number as string
Hi Yasuo On Mon, Mar 30, 2015 at 1:07 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: int should be fixed also. http://3v4l.org/95dHM We have already fix for this: JSON_BIGINT_AS_STRING ( http://3v4l.org/vYXUk ) So option may be JSON_SCALAR_AS_STRING or additional JSON_INT_AS_STRING. I was actually thinking about JSON_INT_AS_STRING anyway as it might be useful for type consistency in decoding (when decoding number that are close to bigint limit) and allowing safe encoding from 64bit to 32bit. However this is a bit more controversial so I plan to open a new thread about it. Cheers Jakub
[PHP-DEV] Exception hierarchy: open issues
Hi internals! There are a number of open issues with regard to the exception hierarchy for recently introduced exception, for which I would like to open a new thread: * Naming and classiness of BaseException. There's an RFC to change this to a Throwable interface: https://wiki.php.net/rfc/throwable - If we want to move forward with that, it needs a patch, as turning it into an interface likely has non-trivial consequences that need to be addressed in the RFC. * Expectations introduced an AssertionException. Currently it extends Exception. Should it extend BaseException instead, as you usually should not catch assertion exceptions? This was discussed in the RFC thread, but the decision was postponed until engine exceptions land, which has happened by now. * The scalar type hints implementation added a TypeException extends EngineException. We didn't discuss this on-list, so I'd like to bring this up in case anyone disagrees. Imho TypeException may not be best name for it, as it's also thrown for non-type related error conditions, like mismatched argument count. Thanks, Nikita
Re: [PHP-DEV] JSON float number as string
On Mon, Mar 30, 2015 at 9:04 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Pierre,
On Mon, Mar 30, 2015 at 11:42 AM, Pierre Joye pierre@gmail.com
wrote:
On Mon, Mar 30, 2015 at 9:14 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Pierre,
On Mon, Mar 30, 2015 at 10:54 AM, Pierre Joye pierre@gmail.com
wrote:
Same effects but totally unrelated topics. All functions dealing with
large external numbers had the same issues, since ever. It has nothing
to do with STH.
Yes, it is.
Developers make casting mistakes like this even when they are used to
strict
typing.
I understand and this is why I said it is the same symptom. But JSON
or any other external data decoding has nothing to do with STH. It
would be nice to do not clutter this discussion with yet another STH
argument :)
As you know, I'm an very unhappy person with the accepted RFC :)
Since Zeev closed the vote before the end date, I think we may have a
little
chance to improve weak mode scalar type hint. i.e. Use Zeev's RFC for weak
mode.
Anyway, similar issue is not only external but also PHP internal.
For example,
[yohgaki@dev php-src]$ ./php-bin -r
'var_dump([9=1, 9=1]);'
array(2) {
[9]=
int(1)
[3875820019684212736]=
int(1)
}
Library that deals with array should use string key data type to have
correct key for
any number even when library expects integer keys. i.e. The library must
have string type hint for integer key to achieve correct behavior.
Database, JSON and array are good examples of confusions. Smart developers
will use string type hints for these, while less experienced developers
will use
int/float type hints for these. When users have to use both of them,
users are
forced to casting variable between string and int/float. This makes
impossible
to write correct code. This JSON bug is a proof that this will happen.
I just don't see the point to introduce new feature that makes impossible
to write
correct code while there is good solution. Fortunately, we still have time
to address
this.
Regards,
P.S. Does anyone have alternative ideas for this?
Please can this be discussed in a new thread? This thread is just about
adding a new option to json ext.
Cheers
Jakub
[PHP-DEV] What's our official stance on small self-contained additions in a micro version
Hi, I know that our official release process allows that, but there are some reasonable arguments against doing that and this topic was brought up multiple times related to specific fixes. I have two open PRs like that: https://github.com/php/php-src/pull/1204 https://github.com/php/php-src/pull/969 and of course there are a bunch of similar ones from other people, and there are cases when somebody simply pushes a change like that, other times somebody points out that it should require an RFC( https://wiki.php.net/rfc/json_preserve_fractional_part for example), but most of the times we simply don't know what to do, and eventually we just let the PR/patch to rot and die. I would like to know if we can come up with a rule which can have consensus behind it, and maybe formalize it as an extension to our current releaseprocess rfc. What do you think? -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
On Mon, Mar 30, 2015 at 1:15 PM, Michael Wallner m...@php.net wrote: On 30/03/15 12:04, Ferenc Kovacs wrote: Hi, I know that our official release process allows that, but there are some reasonable arguments against doing that and this topic was brought up multiple times related to specific fixes. I have two open PRs like that: https://github.com/php/php-src/pull/1204 https://github.com/php/php-src/pull/969 and of course there are a bunch of similar ones from other people, and there are cases when somebody simply pushes a change like that, other times somebody points out that it should require an RFC( https://wiki.php.net/rfc/json_preserve_fractional_part for example), but most of the times we simply don't know what to do, and eventually we just let the PR/patch to rot and die. I would like to know if we can come up with a rule which can have consensus behind it, and maybe formalize it as an extension to our current releaseprocess rfc. What do you think? How about: It's okay, if it does not need `version_compare(PHP_VERSION)` but can be tested by e.g. `defined(SOME_CONSTANT)` or `function_exists(fn)`? -- Regards, Mike hi, That is a good think to keep in mind, but I don't think that is the only thing matters. Adding a new function/constants - there is a chance that we break somebodys code in a micro version Adding a new class method - can be problematic if somebody extended the class and used the same method but with different signature. As of now, we don't really consider this kind of things as BC breaks (otherwise nothing but new optional arguments would be allowed in micro and minor versions), but it is a PITA for those whose app we break in a micro version. I tend to agree that it would be easier for all parties if we stop adding stuff in micro versions, as it is easier to remember and communicate that something was added in x.y (as in x.y.0) than the current situation where some stuff is just only present in 5.6.27, plus this would also eliminate the confusion, that something is present in 5.6.27 but not in 5.5.40(because 5.6.27 was released after 5.5.40, and this new stuff will land in 5.5.41). -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
On Mar 30, 2015 6:15 PM, Michael Wallner m...@php.net wrote: On 30/03/15 12:04, Ferenc Kovacs wrote: Hi, I know that our official release process allows that, but there are some reasonable arguments against doing that and this topic was brought up multiple times related to specific fixes. I have two open PRs like that: https://github.com/php/php-src/pull/1204 https://github.com/php/php-src/pull/969 and of course there are a bunch of similar ones from other people, and there are cases when somebody simply pushes a change like that, other times somebody points out that it should require an RFC( https://wiki.php.net/rfc/json_preserve_fractional_part for example), but most of the times we simply don't know what to do, and eventually we just let the PR/patch to rot and die. I would like to know if we can come up with a rule which can have consensus behind it, and maybe formalize it as an extension to our current releaseprocess rfc. What do you think? How about: It's okay, if it does not need `version_compare(PHP_VERSION)` but can be tested by e.g. `defined(SOME_CONSTANT)` or `function_exists(fn)`? We have php version constants, major, minor and patch. To me it all looks the same, ugly #ifdef like. Now that we release a x.y+1 every year, I do not see the point to continue to force our users to clutter their codes with such tests. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC][Accepted] Generator Delegation
Voting concluded yesterday on the Generator Delegation RFC; the proposal passed 25-0 for inclusion in PHP7. https://wiki.php.net/rfc/generator-delegation#vote Thanks to everyone who read the proposal and contributed either directly or indirectly. -Daniel
Re: [PHP-DEV] [RFC][VOTE] In Operator
This RFC has been declined with 21 Yes votes and 26 No votes. Regards, Niklas 2015-03-29 11:19 GMT+02:00 Pascal Martin, AFUP mail...@pascal-martin.fr: Le 15/03/2015 20:31, Niklas Keller a écrit : I just opened the vote for the in operator Hi, Discussing this RFC with other people at AFUP, it seems the majority of us ended up on the +1 side. The idea of a unified syntax to find whether or not something is *in* something else seems to be interesting for many. On the other hand, some noted this new operator doesn't feel like the PHP way and cannot be used as a callback (as it's not a function). A few also suggested if this is accepted, maybe it could be extended for objects in the future; with new a specific method? In any case, thanks for your work on this! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Naming of 'weak' type hints
All, One thing that I think we should change is how we refer to the ‘weak’ type hints. The word ‘weak’ has a negative ring to it, and considering this is how the language behaves across the board it’s a pretty bad name for this feature. Personally I think we should go for ‘dynamic’ when we document it, as this is the common way to refer to this behavior (dynamic languages). We could also consider going for ‘lax’ or ‘lenient’ as the opposite of ‘strict’, although I think we can easily do without introducing a new word into the vocabulary here. Thoughts? Zeev
Re: [PHP-DEV] Naming of 'weak' type hints
We could also consider going for ‘lax’ or ‘lenient’ as the opposite of ‘strict’, although I think we can easily do without introducing a new word into the vocabulary here. From an user perspective, I'd suggest that lax would potentially carry more negative connotations than weak. Lax implies (to me) that the engine is being negligent in not checking the types... Dynamic for weak types, and Strong for strict types would make the most sense to me. :)
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
On Mon, Mar 30, 2015 at 3:10 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Mon, Mar 30, 2015 at 1:15 PM, Michael Wallner m...@php.net wrote: On 30/03/15 12:04, Ferenc Kovacs wrote: Hi, I know that our official release process allows that, but there are some reasonable arguments against doing that and this topic was brought up multiple times related to specific fixes. I have two open PRs like that: https://github.com/php/php-src/pull/1204 https://github.com/php/php-src/pull/969 and of course there are a bunch of similar ones from other people, and there are cases when somebody simply pushes a change like that, other times somebody points out that it should require an RFC( https://wiki.php.net/rfc/json_preserve_fractional_part for example), but most of the times we simply don't know what to do, and eventually we just let the PR/patch to rot and die. I would like to know if we can come up with a rule which can have consensus behind it, and maybe formalize it as an extension to our current releaseprocess rfc. What do you think? How about: It's okay, if it does not need `version_compare(PHP_VERSION)` but can be tested by e.g. `defined(SOME_CONSTANT)` or `function_exists(fn)`? -- Regards, Mike hi, That is a good think to keep in mind, but I don't think that is the only thing matters. Adding a new function/constants - there is a chance that we break somebodys code in a micro version Adding a new class method - can be problematic if somebody extended the class and used the same method but with different signature. As of now, we don't really consider this kind of things as BC breaks (otherwise nothing but new optional arguments would be allowed in micro and minor versions), but it is a PITA for those whose app we break in a micro version. I tend to agree that it would be easier for all parties if we stop adding stuff in micro versions, as it is easier to remember and communicate that something was added in x.y (as in x.y.0) than the current situation where some stuff is just only present in 5.6.27, plus this would also eliminate the confusion, that something is present in 5.6.27 but not in 5.5.40(because 5.6.27 was released after 5.5.40, and this new stuff will land in 5.5.41). I agree. That was the case for 5.6 for example, that got added new functions etc... up to 5.6.3 AFAIR. As everything can be considered as beeing a BC break for at least someone on Earth, I admit it is hard to understand the meaning of small self-contained additions in a micro version :-p Julien.Pauli
Re: [PHP-DEV] Naming of 'weak' type hints
Hi Zeev, Le 30 mars 2015 16:17, Zeev Suraski z...@zend.com a écrit : All, One thing that I think we should change is how we refer to the ‘weak’ type hints. The word ‘weak’ has a negative ring to it, and considering this is how the language behaves across the board it’s a pretty bad name for this feature. Personally I think we should go for ‘dynamic’ when we document it, as this is the common way to refer to this behavior (dynamic languages). We could also consider going for ‘lax’ or ‘lenient’ as the opposite of ‘strict’, although I think we can easily do without introducing a new word into the vocabulary here. Dynamic is used in the context of static/dynamic typing though, and that's a different meaning. Strong/weak typing is a known definition, and the correct one here. Thoughts? Zeev
Re: [PHP-DEV] Naming of 'weak' type hints
On 30 March 2015 at 15:16, Zeev Suraski z...@zend.com wrote: All, One thing that I think we should change is how we refer to the ‘weak’ type hints. The word ‘weak’ has a negative ring to it, and considering this is how the language behaves across the board it’s a pretty bad name for this feature. Personally I think we should go for ‘dynamic’ when we document it, as this is the common way to refer to this behavior (dynamic languages). We could also consider going for ‘lax’ or ‘lenient’ as the opposite of ‘strict’, although I think we can easily do without introducing a new word into the vocabulary here. Thoughts? To me, dynamic implies subject to change. The rules are different but they are fixed and well defined. I would suggest loose if you want to avoid weak (personally I think weak is OK, but I can certainly see where you are coming from). Loose typing is not new terminology, indeed Google seem to consider it synonymous with weak typing - when I Google either the first hit is http://en.wikipedia.org/wiki/Strong_and_weak_typing Zeev
Re: [PHP-DEV] Deprecate or remove mbstring function overloads in PHP 7
On Fri, Mar 27, 2015 at 11:11 PM, Stanislav Malyshev smalys...@gmail.com wrote: Hi! I was never happy about this particular hack but that said, unless we *know* it is not used widely (and I suspect it is in Japan etc. where we don't have a lot of visibility due to language barrier) we can't really remove it. Also, I'm not sure why should we remove it. Yes, it's a PITA for the code, but looking at it in another direction, it is only a PITA if people actually turn it on, which means they're using it (otherwise why turn it on?). Deprecating it may be ok provided we actually have some proposal as to what people should do instead. If we have consensus on deprecating it, I don't think it's a problem have it done in 7.0 since it's not a substantial code/feature change and beta period provides ample time for people to scream if it's unacceptable. If there's no consensus yet, I'd go for 7.1. From this thread, I'd say we have a consensus to deprecate it. From the Japanese side, both Yasuo and Masaki agree that this should be dropped and Masaki also linked a bug report where it is stated that the original author of this functionality agrees that this should be deprecated. It also contains a link to a discussion on a Japanese PHP dev ML, where, as far as Google Translate can tell me, everyone agreed that that we should do away with it. As to what people should use instead: For the quick hack to make things work: a sed script. Apart from that, implementing proper multibyte handling in applications. Nikita
RE: [PHP-DEV] Exception hierarchy: open issues
Hey, Imho TypeException may not be best name for it, as it's also thrown for non-type related error conditions, like mismatched argument count. Would SignatureException be a more apt name for these error conditions? -Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
On 30/03/15 12:04, Ferenc Kovacs wrote: Hi, I know that our official release process allows that, but there are some reasonable arguments against doing that and this topic was brought up multiple times related to specific fixes. I have two open PRs like that: https://github.com/php/php-src/pull/1204 https://github.com/php/php-src/pull/969 and of course there are a bunch of similar ones from other people, and there are cases when somebody simply pushes a change like that, other times somebody points out that it should require an RFC( https://wiki.php.net/rfc/json_preserve_fractional_part for example), but most of the times we simply don't know what to do, and eventually we just let the PR/patch to rot and die. I would like to know if we can come up with a rule which can have consensus behind it, and maybe formalize it as an extension to our current releaseprocess rfc. What do you think? How about: It's okay, if it does not need `version_compare(PHP_VERSION)` but can be tested by e.g. `defined(SOME_CONSTANT)` or `function_exists(fn)`? -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate or remove mbstring function overloads in PHP 7
On Mar 30, 2015 5:29 PM, Nikita Popov nikita@gmail.com wrote: From this thread, I'd say we have a consensus to deprecate it. From the Japanese side, both Yasuo and Masaki agree that this should be dropped and Masaki also linked a bug report where it is stated that the original author of this functionality agrees that this should be deprecated. It also contains a link to a discussion on a Japanese PHP dev ML, where, as far as Google Translate can tell me, everyone agreed that that we should do away with it. Yes, and if it helps, I asked around here (South Eastern Asia) and could not find anyone using it, not representative but representing quite a lot of companies. As to what people should use instead: For the quick hack to make things work: a sed script. Apart from that, implementing proper multibyte handling in applications. Nikita
Re: [PHP-DEV] Naming of 'weak' type hints
Hi! One thing that I think we should change is how we refer to the ‘weak’ type hints. The word ‘weak’ has a negative ring to it, and considering this is I would really prefer we stop calling it hints. It is misleading as it is implying this is something which can be easily ignored if wished and only provides an unimportant small piece of information not directly related to the important things. In fact, it would either change the type of the value or produce fatal error, it's hardly a hint. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Naming of 'weak' type hints
Zeev Suraski wrote: One thing that I think we should change is how we refer to the ‘weak’ type hints. The word ‘weak’ has a negative ring to it, and considering this is how the language behaves across the board it’s a pretty bad name for this feature. Personally I think we should go for ‘dynamic’ when we document it, as this is the common way to refer to this behavior (dynamic languages). We could also consider going for ‘lax’ or ‘lenient’ as the opposite of ‘strict’, although I think we can easily do without introducing a new word into the vocabulary here. It appears to me that all of these suggestions may hide the fact that the arguments are converted to the hinted types. So perhaps converting type hints might be a good name. Then again, the respective declare directive is called strict_types, so maybe it's best to speak of non-strict type hints. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
On 30/03/2015 19:50, Stanislav Malyshev wrote: Hi! I tend to agree that it would be easier for all parties if we stop adding stuff in micro versions, as it is easier to remember and I don't think it is a good idea. Imagine you are a PHP developer working on a project, and you noticed there's some small functionality missing that would improve things a lot for you - like parameter to some function or returning some value that is missing. You could easily contribute it, but if it can't go in minor version there's no point for you to even bother. Because even if your org is super-up-to-date, they run 5.6, most realistically - 5.5, and if it's like the majority - it'd be 5.4 and worse. You could hope to convince your bosses and your ops to go to 5.6 and keep it reasonably updated within 5.6, but if the only addition you can make is 7.1, it's the lost cause - by the time your org could go to 7.1 your project will be long done (or at least long designed to work without this new feature) and you may be already working in another company. If an organisation has standardised on an old version of PHP, there's a fair chance that the builds they are using are not from php.net, but from their OS distribution. As has been mentioned here before, these generally track a particular patch release and cherry-pick fixes - Ubuntu 14.04 maintains a patched version of PHP 5.5.9 vs the official 5.5.23, for instance. Anyone working in such an environment won't receive the benefit of a new feature however far it is backported. The obvious alternative avenues are to write a forward-compatible userland version, or package an extension, both of which are likely to reach a larger audience than a tail-end release like 5.5.23. I can certainly see value in a special case for including things in both 5.6 and 7.x, both before and after 7.0 is released, but the the case for backporting anything other than a genuine bug fix to 5.5.x right now seems fairly weak, as will the case for backporting to 7.0.x after 7.1.0 is released (by which point 5.6.x will presumably be in its security-only phase). As everything can be considered as beeing a BC break for at least someone on Earth, I admit it is hard to understand the meaning of small self-contained additions in a micro version :-p I do not think we should consider adding functions/options BC break, not by any sane definition of it. Of course, nothing prevents somebody from using insane definitions, but it's of no concern to us. The problem is that there is no way to know, as a user, which function names may become reserved in the future. There is an officially reserved namespace php\, but it remains unused. So if functions can be added at any time, the only way to guarantee your code won't break on a patch upgrade is to treat the entire global namespace as additionally reserved. I don't think it's at all insane to say that a patch version shouldn't usurp non-reserved names. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exception hierarchy: open issues
Am 30.03.2015 um 12:58 schrieb Thomas Punt: Hey, Imho TypeException may not be best name for it, as it's also thrown for non-type related error conditions, like mismatched argument count. Would SignatureException be a more apt name for these error conditions? We already have an InvalidArgumentException but this one extends LogicException extends Exception -Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
Hi! I tend to agree that it would be easier for all parties if we stop adding stuff in micro versions, as it is easier to remember and I don't think it is a good idea. Imagine you are a PHP developer working on a project, and you noticed there's some small functionality missing that would improve things a lot for you - like parameter to some function or returning some value that is missing. You could easily contribute it, but if it can't go in minor version there's no point for you to even bother. Because even if your org is super-up-to-date, they run 5.6, most realistically - 5.5, and if it's like the majority - it'd be 5.4 and worse. You could hope to convince your bosses and your ops to go to 5.6 and keep it reasonably updated within 5.6, but if the only addition you can make is 7.1, it's the lost cause - by the time your org could go to 7.1 your project will be long done (or at least long designed to work without this new feature) and you may be already working in another company. Yes, we have releases (almost) each year, but adoption of them is much slower, and with all BC breaks in 7.0 it would probably be even slower when going from 5 to 7, so this means doing small improvements to PHP is essentially of no practical value for PHP developer since there's no chance this improvement can be used in the lifetime of a typical project. I do not think it would be good for PHP. As everything can be considered as beeing a BC break for at least someone on Earth, I admit it is hard to understand the meaning of small self-contained additions in a micro version :-p I do not think we should consider adding functions/options BC break, not by any sane definition of it. Of course, nothing prevents somebody from using insane definitions, but it's of no concern to us. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: What's our official stance on small self-contained additions in a micro version
Hi! I know that our official release process allows that, but there are some reasonable arguments against doing that and this topic was brought up multiple times related to specific fixes. Adding an option I think it's ok provided it's not controversial and not an attempt to create entirely different large functionality hidden behind the option (e.g. let's add an option to make mysql_connect also connect to Postgres databases). If it's something that clearly a small functional piece that is missing, adding it I think is OK. If it's bigger (like entirely new functionality or substantial change in existing one) then it'd be better to go into next version. I would like to know if we can come up with a rule which can have consensus behind it, and maybe formalize it as an extension to our current releaseprocess rfc. I'm not sure there's a formal rule that would be good for all cases. We can have guidelines but unless we reject all changes completely (which I strongly disagree with) I think we'll still have to consider them on the substance. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: What's our official stance on small self-contained additions in a micro version
Hi! even agreeing upon something like adding features in a micro version needs a format RFC and a 2/3 vote would allow us to have a conservative default while we could still make exceptions with a clear process to follow. I'm still not sure which problem we're trying to solve. Can someone give me 3-4 examples of some important code that was in the past broken by adding option to json_decode or get_headers or creating a function like get_error_handler? -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Naming of 'weak' type hints
Zeev Suraski wrote: One thing that I think we should change is how we refer to the ‘weak’ type hints. The word ‘weak’ has a negative ring to it, and considering this is how the language behaves across the board it’s a pretty bad name for this feature. Borrowing from C#, I would suggest the names implicit and explicit argument types. There is nothing weak about them, they just do an implicit conversion which can be quite powerful if used correctly. In the future, I hope that we will have implicit object conversions in addition to the scalar ones. Lazare INEPOLOGLOU Ingénieur Logiciel
Re: [PHP-DEV] What's our official stance on small self-containedadditions in a micro version
Stanislav Malyshev wrote: I can certainly see value in a special case for including things in both 5.6 and 7.x, both before and after 7.0 is released, but the the case for backporting anything other than a genuine bug fix to 5.5.x right now seems fairly weak, as will the case for backporting to 7.0.x after 7.1.0 is released (by which point 5.6.x will presumably be in its security-only phase). That means right now any enhancement somebody would propose would be just released somewhere towards the end of next year. And since nobody switches instantly, especially to the next major, their timeframe to use it would be something like 4-5 years. I would have zero motivation as a userland developer to work on a small change like adding an option that I could benefit from in 5 years maybe. Would you? Have you considered developers targeting shared hosting? Working on an improvement they have to wait for five years to use it is most certainly annoying. However, introducing this feature in a revision might not really help them at all. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
Hi! If an organisation has standardised on an old version of PHP, there's a By old you're meaning current stable, I presume. fair chance that the builds they are using are not from php.net, but from their OS distribution. As has been mentioned here before, these There are no builds on php.net, except for windows.php.net. Most organizations I've encountered indeed use either distros or their own distro-like packages (which usually mimick distro ones but have modifications like additional packages, tweaking paths, adding/removing configs or data, etc.). generally track a particular patch release and cherry-pick fixes - Ubuntu 14.04 maintains a patched version of PHP 5.5.9 vs the official 5.5.23, for instance. Anyone working in such an environment won't receive the benefit of a new feature however far it is backported. As per above, it's much easier to get 5.5.23 installed in the org than 7.1. I'm not overly familiar with particulates of Debian policies, but if they have whole distro sitting on 5.5.9 when there's 5.5.23 out it's bad, as their customers do not get bugfixes which may be essential for them. I sincerely hope it's not the case. In any case, burden of creating 5.5.23 package from debian 5.5.9 package is very low, most competent ops would be able to do this, and the risk of following 5.5 line is not comparable to the risk of switching from 5.5 to 7.1. The obvious alternative avenues are to write a forward-compatible userland version, or package an extension, both of which are likely to reach a larger audience than a tail-end release like 5.5.23. I'm not sure how you mean to write an extension that would add an option to json_encode for example. I can certainly see value in a special case for including things in both 5.6 and 7.x, both before and after 7.0 is released, but the the case for backporting anything other than a genuine bug fix to 5.5.x right now seems fairly weak, as will the case for backporting to 7.0.x after 7.1.0 is released (by which point 5.6.x will presumably be in its security-only phase). That means right now any enhancement somebody would propose would be just released somewhere towards the end of next year. And since nobody switches instantly, especially to the next major, their timeframe to use it would be something like 4-5 years. I would have zero motivation as a userland developer to work on a small change like adding an option that I could benefit from in 5 years maybe. Would you? The problem is that there is no way to know, as a user, which function names may become reserved in the future. There is an officially reserved That's true in general. But if you name your function something like get_error_handler or mysql_connect_something, you must know you're on a shaky ground. The argument we can not add anything in the main namespace because somebody could have named function exactly the same sounds hollow to me. Of course, for some cases it must be true, but most people that don't use classes long learned to prefix or namespace their functions, and And, of course, this does not apply to adding options, etc. reserved. I don't think it's at all insane to say that a patch version shouldn't usurp non-reserved names. I think in this form it is. There are no reserved names in functions, and if you use mysql_* namespace functions and it clashes with functions added by mysql extension, it's your fault. Same for other obvious cases. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: What's our official stance on small self-contained additions in a micro version
On Mon, Mar 30, 2015 at 10:52 PM, Stanislav Malyshev smalys...@gmail.com wrote: Hi! I know that our official release process allows that, but there are some reasonable arguments against doing that and this topic was brought up multiple times related to specific fixes. Adding an option I think it's ok provided it's not controversial and not an attempt to create entirely different large functionality hidden behind the option (e.g. let's add an option to make mysql_connect also connect to Postgres databases). If it's something that clearly a small functional piece that is missing, adding it I think is OK. If it's bigger (like entirely new functionality or substantial change in existing one) then it'd be better to go into next version. I would like to know if we can come up with a rule which can have consensus behind it, and maybe formalize it as an extension to our current releaseprocess rfc. I'm not sure there's a formal rule that would be good for all cases. We can have guidelines but unless we reject all changes completely (which I strongly disagree with) I think we'll still have to consider them on the substance. even agreeing upon something like adding features in a micro version needs a format RFC and a 2/3 vote would allow us to have a conservative default while we could still make exceptions with a clear process to follow. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
AW: [PHP-DEV] Re: Naming of 'weak' type hints
-Ursprüngliche Nachricht- Von: Lazare Inepologlou [mailto:linep...@gmail.com] Gesendet: Dienstag, 31. März 2015 00:01 An: Christoph Becker Cc: Zeev Suraski; PHP internals Betreff: Re: [PHP-DEV] Re: Naming of 'weak' type hints Zeev Suraski wrote: One thing that I think we should change is how we refer to the ‘weak’ type hints. The word ‘weak’ has a negative ring to it, and considering this is how the language behaves across the board it’s a pretty bad name for this feature. Borrowing from C#, I would suggest the names implicit and explicit argument types. There is nothing weak about them, they just do an implicit conversion which can be quite powerful if used correctly. [Robert Stoll] It's probably hard to come up with something which does not conflict with another concept, but implicit and explicit typing is used to refer to two sub categories of static typing. Explicit typing refers to code which requires explicit type specifications written by the user and implicit typing is the case where type inference infers the types. I am not so sure if it is clever to use an own name for type hints when strict_types=1 since the type hint as such is not different, the context is different. I am think about it in the sense that a function has different overloads and depending on the context some are available and others are not (similar to the callee of a method call, strict_types=1 can be seen as another argument). But I guess that is too complicated for a documentation. Nevertheless, I would put emphasis on the fact that the context is different. In the future, I hope that we will have implicit object conversions in addition to the scalar ones. [Robert Stoll] That would be nice :) Lazare INEPOLOGLOU Ingénieur Logiciel -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
On Mon, Mar 30, 2015 at 8:50 PM, Stanislav Malyshev smalys...@gmail.com wrote: Hi! I tend to agree that it would be easier for all parties if we stop adding stuff in micro versions, as it is easier to remember and I don't think it is a good idea. Imagine you are a PHP developer working on a project, and you noticed there's some small functionality missing that would improve things a lot for you - like parameter to some function or returning some value that is missing. You could easily contribute it, but if it can't go in minor version there's no point for you to even bother. Because even if your org is super-up-to-date, they run 5.6, most realistically - 5.5, and if it's like the majority - it'd be 5.4 and worse. You could hope to convince your bosses and your ops to go to 5.6 and keep it reasonably updated within 5.6, but if the only addition you can make is 7.1, it's the lost cause - by the time your org could go to 7.1 your project will be long done (or at least long designed to work without this new feature) and you may be already working in another company. Yes, we have releases (almost) each year, but adoption of them is much slower, and with all BC breaks in 7.0 it would probably be even slower when going from 5 to 7, so this means doing small improvements to PHP is essentially of no practical value for PHP developer since there's no chance this improvement can be used in the lifetime of a typical project. I do not think it would be good for PHP. As everything can be considered as beeing a BC break for at least someone on Earth, I admit it is hard to understand the meaning of small self-contained additions in a micro version :-p I do not think we should consider adding functions/options BC break, not by any sane definition of it. Of course, nothing prevents somebody from using insane definitions, but it's of no concern to us. The problem is always a definition question, a very subjective question. I do not really buy the I am stuck with x.y as one has the same problem already. And he has barely a 2 years window to add them. About 7, yes, that's our only next release. We rejected any 5.7, so we have to live with it. Now, about the BC breaks, I do not see that much BC breaks for modern apps and even WP or D7 work quite well. Let focus on that instead of starting to using 5.6 as a solution of our frustration not being able to move to 7, that would be terrible to have new features every patch release. Let do not do that. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What's our official stance on small self-containedadditions in a micro version
Hi! Have you considered developers targeting shared hosting? Working on an improvement they have to wait for five years to use it is most certainly annoying. However, introducing this feature in a revision might not really help them at all. Not immediately, but shared hoster much faster would upgrade from 5.5.9 to 5.5.23 than from 5.5.9 to 7.1. Also, if adding feature does not help some specific group, it doesn't mean it shouldn't be done - because not adding doesn't help *all* groups. So at least we can help people that do have option to upgrade. What is being proposed that everybody has to wait for years for even tiniest feature to become available. I don't think it is a good idea. If that were the principle in PHP in its early days, many people - probably including myself - would never start contributing to core, since what's the point if they have to wait for results of their labor to be useful to them for several years? -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Constructor behaviour of internal classes
Hi Dan, The updated patch is at https://github.com/php/php-src/pull/1205 The main difference is in ext/intl. If you don't see any problems I can commit it. I didn't think about the classes you missed. Thanks. Dmitry. On Fri, Mar 27, 2015 at 7:32 PM, Dan Ackroyd dan...@basereality.com wrote: On 26 March 2015 at 20:19, Dmitry Stogov dmi...@zend.com wrote: Hi Dmitry, however the patch looks a bit surprising to me. We have special function to do this - zend_ctor_make_null() and some tricks in the VM. I made just a quick look over your patch but didn't find any references to them. Surprising is usually not good, so let me see if I can explain. I touched the minimal amount of code needed to achieve the desired behaviour. For the intl classes, the exception is being thrown by telling the intl error handling code to use an exception, no matter what the intl.use_exceptions setting is, if the error was emitted during a constructor: https://github.com/Danack/php-src/blob/InternalClassClean/ext/intl/intl_error.c#L114 I didn't touch any of the code zend_ctor_make_null. I guess if it's only used in these special cases, and they are going away it could also be removed? But it sounds like that would be a job for someone who understands that bit. Please don't commit it yet. That won't be difficult, I don't have commit rights, and don't particularly want them. Nikita, could you also take a quick look. Nikita pointed out that I may have missed a couple of classes. I'll try to get those updated before you have a look. cheers Dan
Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
On Mon, Mar 30, 2015 at 4:04 AM, Ferenc Kovacs tyr...@gmail.com wrote: Hi, I know that our official release process allows that, but there are some reasonable arguments against doing that and this topic was brought up multiple times related to specific fixes. I have two open PRs like that: https://github.com/php/php-src/pull/1204 https://github.com/php/php-src/pull/969 and of course there are a bunch of similar ones from other people, and there are cases when somebody simply pushes a change like that, other times somebody points out that it should require an RFC( https://wiki.php.net/rfc/json_preserve_fractional_part for example), but most of the times we simply don't know what to do, and eventually we just let the PR/patch to rot and die. I would like to know if we can come up with a rule which can have consensus behind it, and maybe formalize it as an extension to our current releaseprocess rfc. I personally do not want to see *any* features go into a patch release (the Z in X.Y.Z). It's not just a pain to document, but there's no real reason to do this because we have minor releases (the Y in X.Y.Z) each year. I'd even like to tighten up on what bug fixes we allow into patch releases, as I think we have been far too accepting in the past. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
