RE: [PHP-DEV] Reserve even more type hints RFC
Hi, Le 30 avr. 2015 11:04, François Laupretre franc...@php.net a écrit : De : Christoph Becker [mailto:cmbecke...@gmx.de] Relying on documentation only seems to be insufficient to me. Consider a developer not reading the documentation and facing the issue that his/her code might break with PHP 7.1 (i.e. a minor version). +1. I already asked if we should enforce reserved names by a message and most replied that documentation was enough. This is the lazy (I could say 'political') option and can only lead to bad surprises when we decide to use the names. At this time, saying People should have read the doc won't help them in any way, especially if their code dates back from before 7.0, when this doc didn't exist yet. We don't need a warning there, we need a fatal error. These names are *invalid* as class names. Should we throw fatal errors for functions starting with 2 underscores too? Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Cheers, Florian Margaine
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] [RFC] Fix the Tenary Operator -- Please!? Please?
Hi, Michael Morris tendo...@gmail.com writes: Per PHPsadness... http://phpsadness.com/sad/30 Since 7 is allowed to have BC breaks this would be the time to fix this. It's too late. Feature freeze is gone. I'll let someone with more seniority actually write this up - but please, please fix this - it's a very long standing annoyance. Cheers, -- Florian Margaine signature.asc Description: PGP signature
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
Hi,
Le 18 mars 2015 11:06, Pavel Kouřil pajou...@gmail.com a écrit :
On Wed, Mar 18, 2015 at 11:01 AM, Pierre Joye pierre@gmail.com
wrote:
On Mar 18, 2015 4:56 PM, Pavel Kouřil pajou...@gmail.com wrote:
On Mon, Mar 16, 2015 at 10:03 PM, Anthony Ferrara ircmax...@gmail.com
wrote:
All,
Voting has been closed on the scalar type declarations v0.5 RFC:
https://wiki.php.net/rfc/scalar_type_hints_v5
At a final score of 108:48, it has been accepted for PHP 7.
Thank you.
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
how will these examples work btw?
// a.php
?php
declare(strict_types=1);
function foo($fn) {
$fn(1);
};
// b.php
?php
require 'a.php';
foo(function (int $a) { return $a * 2; });
// c.php
?php
function foo($fn) {
$fn(1);
};
// d.php
?php
declare(strict_types=1);
require 'c.php';
foo(function (int $a) { return $a * 2; });
I can't find this in the RFC. I'd intuitively expect error in the
first example and the second one to work OK.
But at the same time, if there will be an error in the first example,
it is IMHO a huge flaw with this RFC. :/
Git clone, compile, try, report.
It sounds pretty straight forward to me instead of asking the same
questions
(in various form but it ends to the same answer).
And the patch should be applied sooner rather than later. So we can fix
bugs
if there are actual ones in the current implementation.
Hello,
if I had time to set up the compilation of PHP on Windows, I'd do it -
but I don't. I wanted to try it myself via http://3v4l.org/, but it
unfortunately doesn't support multiple files.
You can emulate multiple files support by using eval().
Regards
Pavel Kouril
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Cheers,
Florian Margaine
Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints
Hi, Derick Rethans der...@php.net writes: On Wed, 11 Mar 2015, Zeev Suraski wrote: The vote on the Coercive Scalar Type Hints is now open for voting. The latest version of the RFC includes changes discussed on internals@ last week: 1. Accept string-bool and int-bool conversions (false-bool is not supported) 2. Accept leading/trailing spaces in string-number conversions. Aren't you supposed to leave it one week between annoucing the latest RFC with your changes, and the real vote? I'm reading that the delay is one week after announcing the intent to vote. Which means that the RFC is in final state before voting, and the author has announced intention to vote. I haven't seen the mail announcing this, did I miss it? There were a lot of mails on internals lately, it may be possible. If this mail wasn't sent, should the rules be different because there was a lot of debate on this RFC? Then which other rule should be broken? Actually, now I read it, it should actually be two weeks ... but then I guess it was just a tweak on an earlier version: https://wiki.php.net/rfc/voting#discussion_period I guess that since there was a lot of discussion, shortening to one week makes sense. cheers, Derick Cheers, -- Florian Margaine signature.asc Description: PGP signature
Re: [PHP-DEV] [RFC] UString
. On the bright side, anything chosen could always be aliased at the top of the file: use function __u as u; This also sucks, but it sucks a little bit less because the collisions are avoided - or at least, avoided in such a way that the onus is on the user - and one can still have the sane name. First-class support at the syntax level (presumably $foo = uunicode string since we already have $foo = bbinary string) would IMO be better and (hopefully?) a long-term goal, but I am aware that it is - and probably should be - outside the scope of the current proposal. [1] https://searchcode.com/?q=function+u+lang%3Aphp [2] https://github.com/facebook/hhvm/blob/master/hphp/test/slow/ext_icu/uspoof.php#L13 -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Cheers, Florian Margaine
Re: [PHP-DEV] Re: [RFC-Discuss] Scalar Type Declarations v0.5
think it's worth it to conflate those two together. Though if we did, the syntax strict namespace; would be supported for non-namespaced strict code. So in the end, my conclusion is that while it would be nice to support the compiled file use-case fully, it's not worth it from a technical level (the risk and degree of change required doesn't offset the benefit of it). So the proposal will remain unchainged and not support the block syntax (or changing the mode mid-file). Thanks Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Cheers, Florian Margaine
Re: [PHP-DEV] Travis support PHP Nightly builds (PHP 7)
Hi, Pascal Chevrel pascal.chev...@free.fr writes: Hi people, I hope this is not too much off topic but I saw today that Travis now supports nightly builds as a possible PHP version, they documented it here: http://docs.travis-ci.com/user/languages/php/#PHP-nightly-builds I think it would be good to incitate all the frameworks and projects using Travis CI to add nightly to their testing matrix so as to catch bugs in the upcoming PHP 7 version by testing real code and also so as to have as much real code as possible getting ready for PHP 7. It would also mean that PHP officially endorses travis. That would mean some kind of communication about it and basically being proactive promoting it but I don't know if PHP.net has some kind of experience with communicating to developers this way. Maybe at least Tweeting about it from the official Twitter account. Regards, Pascal Cheers, -- Florian Margaine signature.asc Description: PGP signature
Re: [PHP-DEV] PHP 5.6.6 is available
Hi, Le 20 févr. 2015 14:34, Ferenc Kovacs tyr...@php.net a écrit : On Fri, Feb 20, 2015 at 8:54 AM, Florian Margaine flor...@margaine.com wrote: Hi Ferenc, Ferenc Kovacs tyr...@php.net writes: Hello! The PHP development team announces the immediate availability of PHP 5.6.6. This release fixes several bugs and addresses CVE-2015-0235 and CVE-2015-0273. All PHP 5.6 users are encouraged to upgrade to this version. For source downloads of PHP 5.6.6 please visit our downloads page: http://www.php.net/downloads.php Windows binaries can be found on http://windows.php.net/download/ The list of changes is recorded in the ChangeLog: http://www.php.net/ChangeLog-5.php#5.6.6 Taken from the changelog: Removed support for multi-line headers, as the are deprecated by RFC 7230. Isn't this a BC break? Ferenc Kovacs Julien Pauli Cheers, -- Florian Margaine cc'ing Stas as he was the author for this change. but from my understanding this isn't a problem as we disallow setting multiple headers in a single header() call for years (even though we had a regression at one point). the current change was made to address https://bugs.php.net/bug.php?id=68978edit=1 which was an IE specific problem which was allowed by header(). maybe we should re-word the NEWS entry to make this a bit more clear. Fair enough then. The changelog makes it look like a BC break without any reason. Cheers, Florian Margaine
Re: [PHP-DEV] PHP 5.6.6 is available
Hi Ferenc, Ferenc Kovacs tyr...@php.net writes: Hello! The PHP development team announces the immediate availability of PHP 5.6.6. This release fixes several bugs and addresses CVE-2015-0235 and CVE-2015-0273. All PHP 5.6 users are encouraged to upgrade to this version. For source downloads of PHP 5.6.6 please visit our downloads page: http://www.php.net/downloads.php Windows binaries can be found on http://windows.php.net/download/ The list of changes is recorded in the ChangeLog: http://www.php.net/ChangeLog-5.php#5.6.6 Taken from the changelog: Removed support for multi-line headers, as the are deprecated by RFC 7230. Isn't this a BC break? Ferenc Kovacs Julien Pauli Cheers, -- Florian Margaine signature.asc Description: PGP signature
Re: [PHP-DEV] Annotated PHP 5-7 extension diff
Hi Rasmus, Rasmus Lerdorf ras...@lerdorf.com writes: It looks like this: https://gist.github.com/anonymous/15cbc9947edb4f0a71fd Any suggestions for how to handle annotating it? We could turn it into a fake PR and mark it up using github's PR comments. But is there something more suited for this out there? Maybe something like this would help? http://underscorejs.org/docs/underscore.html -Rasmus Cheers, -- Florian Margaine signature.asc Description: PGP signature
Re: [PHP-DEV] What do we need strict scalar type hints for?
Hi Leigh,
Le 4 févr. 2015 11:50, Leigh lei...@gmail.com a écrit :
What was wrong with:
function x(int $y, string $z) { // strict
function x((int) $y, (string) $z) { // casting
This was the best suggestion I've seen that covers the requirements of
both camps, and is still very clear how data is going to be handled.
Authors who want their APIs to adhered to strictly can do that,
authors who want to accept anything and have it end up as their
desired type can do that too.
Because it is then the callee who decides, not the caller, whether or not
he wants strict typing.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Cheers,
Florian Margaine
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Hi Stelian, Stelian Mocanita writes: Hello everyone, Might I suggest community feedback on this one in a reddit thread? My guess is that even though a lot of applications out there are still PHP 4 ctor reliant, a very low percentage of these applications might be under active development. Not under active development doesn't mean that the application shouldn't be able to upgrade PHP and enjoy the bug/security fixes or performance improvements that new versions provide. Best, Stelian Cheers, -- Florian Margaine signature.asc Description: PGP signature
Re: [PHP-DEV] [RFC][VOTE] Objects as Keys
Hi, Le 16 déc. 2014 13:45, Rowan Collins rowan.coll...@gmail.com a écrit : Patrick Schaaf wrote on 16/12/2014 11:46: Am 16.12.2014 12:36 schrieb Matteo Beccati p...@beccati.com: On 16/12/2014 11:52, Andrea Faulds wrote: I was previously in favour of this, but it’d prevent actual indexing by objects in future, and I can’t think of any use cases which aren’t better solved by explicitly converting to a string/integer. That's precisely the same reason why I voted Nay. And I wouldn't have been able to put it down in words better than Andrea did. That was my thought initially, too. But I think it is wrong. If PHP ever gets around to provide objects-themselves-as-array-keys support, it can easily do that 1) only if the object does not have such a __toKey() method, or 2) if the object has one, but it returns the object itself (which is forbidden now by the RFC) Hm, that's an interesting thought. My thought had been that an object-as-key would need to specify its hash anyway, so that two objects of the same value would be automatically de-duped, just as two strings are. But I guess an internally unique handle for the specific object would also be a reasonable approach for some uses. Just a random thought: the `__hash` method can just `return spl_object_hash($this);` to have an object id. -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Cheers, Florian Margaine
RE: [PHP-DEV] [RFC] PHP 5.7
Hi list, I think having a minor PHP version for the only sake of adding E_DEPRECATED is kind of pointless to be honest. Historically, PHP (or other languages for the matter, I'm thinking of python) minor versions have brought new features. Adding notices is not a reason for a new version imho. If what we want are notices, and helping people to migrate to PHP 7, then we can create tools for this. For example, python made a tool to help with the transition of python 2 to python 3. Go did the same for 0.x to 1.0, if my memory serves right. The point of new versions is to include new features or bug fixes for the language, static analysis can be done with external tools. The fact that we'll have to maintain one more version is also not something to be taken lightly, especially when I see examples of how things progress in php-src. (I'm thinking about the recent contributor who gave up.) Now, if the reason people want PHP 5.7 is to extend PHP 5 lifetime, then it's another matter, and the lifetime of existing versions could be extended. Just my $0.02. Cheers, Florian Margaine
Re: [PHP-DEV] [VOTE] Abstract final / Static classes
Hi,
On Fri, Dec 12, 2014 at 5:12 PM, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
Hi internals,
After a good round of discussion, I updated the original abstract final
class proposal into a static class proposal.
However, I kept both patches online so it's up to voters decide which one
it could be implemented.
Patches are now complete and voting phase starts now and will be active
until 12/19/2014.
As this is a language update, it requires 2/3 pro or against the feature.
https://wiki.php.net/rfc/abstract_final_class
Why does the example use `final`?
final static class Environment
{
private static $rootDirectory = '/var/www/project';
public static function getRootDirectory()
{
return self::$rootDirectory;
}
}
Also, the vote presents 2 options. The RFC is in a weird state where it
mentions abstract final but doesn't explain anything about them. The
votes don't seem to be what the example is...
Could you edit your RFC?
Happy voting!
Regards,
--
Guilherme Blanco
MSN: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
Cheers,
--
Florian Margaine
Re: [PHP-DEV] [VOTE] Abstract final / Static classes
Hi,
Le 12 déc. 2014 17:28, guilhermebla...@gmail.com
guilhermebla...@gmail.com a écrit :
It's part of the history of that RFC, accessible here:
https://wiki.php.net/rfc/abstract_final_class?rev=1417060830
But then it isn't clear as of right now. What is proposed? The example? The
votes? What does `final` has to do with `static`?
I'm confused.
On Fri, Dec 12, 2014 at 11:18 AM, Florian Margaine flor...@margaine.com
wrote:
Hi,
On Fri, Dec 12, 2014 at 5:12 PM, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
Hi internals,
After a good round of discussion, I updated the original abstract final
class proposal into a static class proposal.
However, I kept both patches online so it's up to voters decide which
one
it could be implemented.
Patches are now complete and voting phase starts now and will be active
until 12/19/2014.
As this is a language update, it requires 2/3 pro or against the
feature.
https://wiki.php.net/rfc/abstract_final_class
Why does the example use `final`?
final static class Environment
{
private static $rootDirectory = '/var/www/project';
public static function getRootDirectory()
{
return self::$rootDirectory;
}
}
Also, the vote presents 2 options. The RFC is in a weird state where it
mentions abstract final but doesn't explain anything about them. The
votes don't seem to be what the example is...
Could you edit your RFC?
Happy voting!
Regards,
--
Guilherme Blanco
MSN: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
Cheers,
--
Florian Margaine
--
Guilherme Blanco
MSN: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
Cheers,
Florian
Re: [PHP-DEV] [VOTE] Abstract final / Static classes
Hi, On Fri, Dec 12, 2014 at 5:35 PM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: RFC is updated exposing both possible usages with both explanations. Hope it doesn't confuse even more. Perfect! Thanks. Cheers, -- Florian Margaine
Re: [PHP-DEV] ./configure on PHP-5.6 modifies main/php_version.h
Hi, Le 11 déc. 2014 09:08, Sebastian Bergmann sebast...@php.net a écrit : $ git status On branch PHP-5.6 Your branch is up-to-date with 'origin/PHP-5.6'. nothing to commit, working directory clean $ ./configure --disable-all . . . Thank you for using PHP. config.status: error: cannot find input file: `php7.spec.in' $ git status On branch PHP-5.6 Your branch is up-to-date with 'origin/PHP-5.6'. Changes not staged for commit: (use git add file... to update what will be committed) (use git checkout -- file... to discard changes in working directory) modified: main/php_version.h no changes added to commit (use git add and/or git commit -a) If you built php7 (master) before, you'll have to make clean, or distclean, or vcsclean and rerun buildconf to be able to build php5.6. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Cheers, Florian
[PHP-DEV] getallheaders() in fpm
Hi list, Since it's an often-requested feature/often-brought up bug, I think this PR should be pushed for merging: https://github.com/php/php-src/pull/904 The patch itself is not very big, and the feature not complicated to test. I'd like to see this merged for the next version if possible :) Regards, -- Florian Margaine
Re: [PHP-DEV] SAPI refactoring
Hi Joe, On Mon, Nov 17, 2014 at 8:42 AM, Joe Watkins pthre...@pthreads.org wrote: On Sat, 2014-11-15 at 11:16 +0100, Florian Margaine wrote: Hi list, As of today, most of the SAPIs have a lot of code duplication with regards to HTTP headers parsing/handling. I'm about to completely duplicate a function from one SAPI to the other to add a feature to fpm (`getallheaders()`, see https://github.com/php/php-src/pull/523), and I'd like to avoid that. Should I create a `sapi/main/` folder for common functions across the SAPIs? Or should each SAPI remain completely independent from each other, even if it means duplicating code? Regards, Morning Florian, There is already a place to put shared SAPI code. main/SAPI.h main/SAPI.c There is also a SAPI_API decl that you will need to use. Thanks! Cheers Joe Cheers, -- Florian Margaine
[PHP-DEV] SAPI refactoring
Hi list, As of today, most of the SAPIs have a lot of code duplication with regards to HTTP headers parsing/handling. I'm about to completely duplicate a function from one SAPI to the other to add a feature to fpm (`getallheaders()`, see https://github.com/php/php-src/pull/523), and I'd like to avoid that. Should I create a `sapi/main/` folder for common functions across the SAPIs? Or should each SAPI remain completely independent from each other, even if it means duplicating code? Regards, -- Florian Margaine
Re: [PHP-DEV] Browser side PHP
Hi, On Wed, Nov 5, 2014 at 11:57 AM, Lester Caine les...@lsces.co.uk wrote: Before you fall of your chairs let me expand on that ... Many of the sites I'm supporting are being chased by the we want your work mob, and being told they Must have apps to stay in business. Of cause that means both an android and an apple one with a discount on the pair. BUT in most cases a restyling of the existing website to be more mobile/tablet friendly layout is all that is needed. To that end I've finally nailed a configuration of bootstrap3 which will work with my smarty templating and legacy jquery browser side actions. ( Fourth setup I've worked through as previous 'solutions' proved dead ends! ) Very few of us use PHP as a programming language in isolation to anything else? Although that is perhaps not obvious from some of the discussions. Areas like better JSON or HTTP support all fall into the camp of integration with the rest of the infrastructure? Something which is now totally different to what existed when PHP5 first came out! Eclipse provides me with a flat workbench where js, css, raw html, php, smarty tpl, sql, and even c/c++ all co-exist and the right highlighting and support tools are provided. Javascript is the obvious choice for browser side programming, and browser side templates like bootstrap rely on it to make elements of the layout work, and PHP is more than happy feeding that functionality, but trying to maintain two different languages between the two ends is perhaps not ideal? Am I totally mad thinking that a tool that converts perhaps a lite version of PHP into Javascript might plug a hole in the infrastructure? Parts like validation beyond what html5 has added is one I've just hit where the original site passed form data back to the server and pushed validation errors back, so we have the specialist bits in php already. But while html5 validation does some of the job, some javascript will be needed to fill the gaps ... with a fall back to PHP for non-html5 browsers. Perhaps something does already exist that I'm missing? This seems kind of off-topic for this mailing list, isn't it? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Regards, -- Florian Margaine
[PHP-DEV] Thresholds of backwards compatibility breaks
Hi list, I'd like to introduce thresholds of backwards compatibility breaks, i.e. maximum numbers of allowed BC breaks per version. Lester's mail from a couple days ago had me thinking about the BC breaks that occur now and then in all the RFCs or all the mails I see these days. Now, take what I say with a grain of salt, as I've only recently been involved in this mailing list, as well as in php-src development. Let me explain my reasoning. To allow the users of PHP to upgrade their versions, and enjoy the new features, as well as the security fixes, the least number of BC breaks should get in the new released versions. That is because a BC break can lead to many hours of a codebase adaptation, hours that many companies don't want to pay for if the benefits are minimal. However, to allow us to evolve the language, BC breaks are a necessary evil. Another issue is the short timeline of security fixes for the versions. PHP 5.4 will have a total lifetime of 3 years, a very short one for many people. I'm not advising to increase this timeline, just saying that it gets in the equation of my discussion. To mitigate the issue of BC breaks, I think introducing the concept of thresholds would greatly help the PHP adoption, and mostly upgrades of PHP versions. If people know that a limited amount of work is going to be needed when upgrading a PHP version, the upgrades should be done more often. For example, the following thresholds could be used: - major BC break: major versions only. 5 major BC breaks allowed per major version. - minor BC break: - minor versions: 5 minor BC breaks allowed. - patch versions: 1 BC break allowed. Thoughts? Am I thinking too much? Is this idea unfeasible? Is it a good idea? Regards, -- Florian Margaine
Re: [PHP-DEV] Debugging code ...
Hi, On Tue, Nov 4, 2014 at 2:03 PM, Lester Caine les...@lsces.co.uk wrote: On the basis of 'If it's not broken', what is actually broken, and what is just a matter of 'I don't like that way of working'? I have a working Annotation system that has not changed since I started working with PHP. PHPEclise simple displays the information from the docblock comments and allows me to open the relevant file. I can then review the other functions available. I can update the material and have even resorted to porting files and adding extra notes when trying to decipher other peoples work. The problem these days is that projects are stripping the docblock data as 'not the modern way of doing things' and we end up with code that does not work with the IDE. Fortunately DVCS systems have some other advantages and one can cherry pick code changes while maintaining a different style of working. In addition to 'Annotation', there is a lot of discussion about adding types into the code. Having moved to using arrays to pass data to functions, the docblock material includes details on what is required in the hash, something that you will never get from any of the current discussions? Just to add to the fun, PHPEclipse seems to have lost support and while I have learnt enough Java in the past to fix a few little niggles, currently it is unable to cope with a number of new developments in PHP so I'm stuck on just what IS the next move ... While it would be nice to get on with some new code, nothing is stable enough these days to allow that :( Right now, I'm afraid your emails looks like a rant more than anything else. I'm absolutely certain that you have something interesting to say, but the message just didn't get through. Could you elaborate? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Regards, -- Florian Margaine
Re: [PHP-DEV] Debugging code ...
Hi, On Tue, Nov 4, 2014 at 2:28 PM, Lester Caine les...@lsces.co.uk wrote: On 04/11/14 13:13, Florian Margaine wrote: On the basis of 'If it's not broken', what is actually broken, and what is just a matter of 'I don't like that way of working'? I have a working Annotation system that has not changed since I started working with PHP. PHPEclise simple displays the information from the docblock comments and allows me to open the relevant file. I can then review the other functions available. I can update the material and have even resorted to porting files and adding extra notes when trying to decipher other peoples work. The problem these days is that projects are stripping the docblock data as 'not the modern way of doing things' and we end up with code that does not work with the IDE. Fortunately DVCS systems have some other advantages and one can cherry pick code changes while maintaining a different style of working. In addition to 'Annotation', there is a lot of discussion about adding types into the code. Having moved to using arrays to pass data to functions, the docblock material includes details on what is required in the hash, something that you will never get from any of the current discussions? Just to add to the fun, PHPEclipse seems to have lost support and while I have learnt enough Java in the past to fix a few little niggles, currently it is unable to cope with a number of new developments in PHP so I'm stuck on just what IS the next move ... While it would be nice to get on with some new code, nothing is stable enough these days to allow that :( Right now, I'm afraid your emails looks like a rant more than anything else. I'm absolutely certain that you have something interesting to say, but the message just didn't get through. Could you elaborate? Just that what many of us have used for years is coming under increasing pressure as other people promote their own way of working. In the past we have been able to co-exist, but it is becoming increasingly difficult as people 'update' coding styles. Anything that is added to the 'core' WILL be used to update third party code, but the rest of the infrastructure is simply not keeping up. I'm sorry... I may be stupid. I'm not sure I understand what you want to say. I have a guess though: are you saying that, for example, PHPEclipse at its version from 2008 can't cope up with PHP at its version from 2014? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Regards, -- Florian Margaine
Re: [PHP-DEV] PHPDBG scope
Hi, Why should phpdbg scope be limited, and not extended? As far as I know, xdebug is nowhere like an official php project, so overlap shouldn't be an issue. I'm not saying phpdbg has to be extended, but I'm wondering why it should be limited. Regards, On Mon, Nov 3, 2014 at 10:03 PM, Derick Rethans der...@php.net wrote: Hi, This is based on an email conversation between Joe Watkins and me. I asked him what the original scope of phpdbg was, and I've summarized his reply here: - PHPDBG was originally envisioned as a gdb for the Zend VM, with gdb like commands to debug, and step through code. - Support for breaking on an opline, something that no userland PHP users would need. - Support for breaking on lines, was an additional step later. - For PHP programmers, which spend most of their time at the console. - Not intended to cover PHP's primary domain of HTTP requests. Then later, they documented a way that you could use it to emulate an HTTP request, by setting those superglobals and executing your index.php - your code doesn't know the difference between a real request, and a cli-like script with the same super globals set. And Joe indicates, that with that addition, the flood gates opened. He also said that he would still like to remain in that narrow scope, phpdbg is still useful in it's current (pre xml stuff) form. and that it was never meant to usurp xdebug, as that is not where we were aiming, and it's an extremely unrealistic thing to even want. And I very much agree that the above bullet points, is what phpdbg's scope should be. Joe, if I got this wrong, then please say so :-) cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Florian Margaine
Re: [PHP-DEV] setcookie() minor BC break - fixes issue #67736
Hi list,
On the PR https://github.com/php/php-src/pull/795/ of the setcookie patch
to become compliant with the HTTP RFC, a valid use case for not throwing a
warning when running setcookie() twice with the same name: deleting cookies
(setcookie('name', '', ...);). It's thus been proposed to add an
unsetcookie() method.
I'm not set on whether it's a good thing or not. I'm also not sure how to
handle this.
There are some facts:
- the current way does not follow the HTTP RFC.
- we cannot have the last come last served cookie because it's a BC break.
- the current functions cannot allow us to unset a cookie.
What should be done? Trying to keep BC at a minimum by adding an
unsetcookie() method and add warnings? Try to detect the deletion of
cookies (empty value) and add warnings to keep even more BC?
I'm unsure on what should be done and would like internals' opinion :-)
On Tue, Sep 9, 2014 at 4:53 PM, Chris Wright c...@daverandom.com wrote:
On 8 September 2014 09:09, Ferenc Kovacs tyr...@gmail.com wrote:
On Mon, Sep 8, 2014 at 9:15 AM, Sherif Ramadan theanomaly...@gmail.com
wrote:
Actually, we shouldn't be doing that all. We should simply just
overwrite
the header. It wouldn't make much sense to set two headers with the same
cookie name when we can just overwrite it.
that would be a bigger BC break, and without a warning, those people
affected by the change will have a harder time figuring out what went
wrong.
and as was discussed both in the PR and the bugreport the rfc discourages
but doesn't prohibit this behavior, so making it impossible for the
userland to do it would be a bit of an arbitrary restriction.
maybe we could do something like introducing a new $overwrite = true
option
to the function signature, but setcookie already has 7 arguments, so
probably isn't a great idea.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Regards,
--
Florian Margaine
Re: [PHP-DEV] New Standardized HTTP Interface
Hi,
Le 31 oct. 2014 18:28, Sherif Ramadan theanomaly...@gmail.com a écrit :
On Fri, Oct 31, 2014 at 1:09 PM, Rowan Collins rowan.coll...@gmail.com
wrote:
Let me repeat my question:
Say I write a class AwesomeHTTPReceive implements HttpMessageReceive,
what do I then do with this class in order for it to perform any
actions?
How does PHP know that my class is the one it should populate, or when
that population should happen?
It wouldn't. You would need to extend the base class, since it already
implements the necessary interface. PHP would simply call on the last
subtype of HttpRequest during the request init phase.
What if there is multiple subtypes?
class A extends HttpRequest {}
class B extends HttpRequest {}
What happens there?
Of course, this is an
implementation detail as of now. There could certainly be other/better
ways
to accomplish this. I just want to keep it as simple as possible for now
without introducing more configuration nightmares that people often
complain about. I really don't like the idea of adding yet another INI
directive to control this behavior (making it harder to port).
What do you propose?
Regards,
Florian Margaine
Re: [PHP-DEV] New Standardized HTTP Interface
Hi, On Thu, Oct 30, 2014 at 7:23 PM, Sherif Ramadan theanomaly...@gmail.com wrote: Hello Internals, I've been meaning to write up a full-blown RFC for introducing a new standardized HTTP interface for PHP core for some time now. I figure now with PHP 7 on the road map this might be a good time to start this discussion since it involves breaking some backwards compatibility that may have been out of the question in PHP 5. I've started a draft RFC, but please be patient as this is a working in progress, here https://wiki.php.net/rfc/http-interface on the wiki. The point here is to allow users to implement their own HttpRequest and HttpResponse classes that can deal directly with the raw request/response messages in any way the user deems fit. This alleviates cases like what about when I want to have $_PUT or $_DELETE and removes the ambiguity of the $_POST, $_GET superglobals to a more conforming way of handling the messages. Since it's an interface, it only dictates the facilitation of PHP's built-in functionality and the user's desired implementation, but no the implementation itself. I find this very... useless. Sure, interfaces are not useless. But I don't think php-src is there to dictate what userland code should look like. It should provide *implementations*, not interfaces. To remove all confusion, consider the way an HTTP message actually looks. GET /foo?bar=1 HTTP/1.1 Host: foobar.com baz=2 Instead of treating this with current $_GET, $_POST, let's consider for a moment how we might treat it in an HttpRequest object: If the HttpRequest class implements an HttpParameters object that parses and treats the entire HTTP request line as a string of parameters we could accomplish the following... var_dump(HttpRequest::$parameters-bar); // int(1) var_dump((string) HttpRequest::$parameters); // string(6)?bar=1 Now consider how the body can be treated... echo HttpRequest::$body; // baz=2 echo HttpRequest::$body-baz; // 2 Since the HttpRequest object can lazily parse the body it can also lazily apply custom filters directly to the request variables and parameters... For example, say you wish to treat baz only as an integer? This can be easily accomplished by setting the filters directly in the HttpRequest object and upon access the filter is directly applied to chosen variables. This also alleviates the need to worry about overwriting superglobal variables or having to copy from them. So from an efficiency stand-point this approach works much better. It also allows you to separate clearly between HTTP request parameters and HTTP request body as well as the HTTP request method. Since the request object should be capable of handling callbacks for each method to apply different sets of filters or rules on treating the request body given different request methods this could prove a lot more useful than existing techniques applied directly in PHP with php://input, for example. We don't need to copy the internal stream and we don't need to modify or copy superglobals around to different parts of our code. I'm in the process of writing up a cleaner implementation to introduce in the RFC, but in the mean time I'd like to open up to discussion and see what others think or how they feel we might approach this problem more cleanly. Thanks, Sherif The other thing I don't like in your RFC is the removal of superglobals. Sure, they're not the best interface out there, but breaking *every single* codebase out there is not the way to go. Especially if we don't want a perl6/python3-like failure to adoption. Regards, -- Florian Margaine
Re: [PHP-DEV] New globals for PUT and DELETE
Hi! On Sun, Oct 26, 2014 at 10:21 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! The only way to do this in PHP now is write a userland function that parses multipart form data, which is non-trivial. I had written one, but would It is true that PUT data need to be parsed, however it is not true you have to implement MIME parsing from scratch. There are frameworks that implement that. Not everything must be written in C. But if you want C, doesn't pecl/http already have the required bits? Having the ability to access the data provided in $_POST for other methods is ideal (by whatever means: $_PUT, $_FORM, get_parsed_form_data(), etc). There are a lot of HTTP verbs - PUT, DELETE, TRACE, PATCH... And what if you want to do WebDAV? Wouldn't having separate superglobal for each be taking it a bit too far? I think Rasmus made it clear what the original naming meant: it were form methods, not related at all to HTTP methods. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Regards, -- Florian Margaine
Re: [PHP-DEV] [RFC] Readonly Properties
Hi, On Fri, Oct 24, 2014 at 12:21 PM, Alain Williams a...@phcomp.co.uk wrote: On Fri, Oct 24, 2014 at 10:41:38AM +0200, Patrick Schaaf wrote: Am 24.10.2014 01:36 schrieb Andrea Faulds a...@ajf.me: Here’s another RFC: https://wiki.php.net/rfc/readonly_properties +1 for the general feature, I'd love to have that available. I have an idea regarding the additional keyword, with a small implication (improvement) to the functionality provided, but at the cost of being slightly quirky :) The idea is: public $foo as private; public $bar as protected; protected $baz as private; where the as X gives the writability scope. This introduces no new keywords, and is currently not valid syntax, as far as I can see. More as musing than anything else - might provide some insight via an analogy. Properties and methods have a scope that is: private, protected or public. This reminds me of the Unix: owner, group other file permissions. Unix allows: read, write execute. This RFC is trying to control how a property could be used with a readonly restriction. Are there times when one would want to be able to set a property value - but not read it ? Thinking about execute - would there be any mileage in an execute permission - could be useful for a property that had been assigned an anonymous function. Finally we could bring it all together and sidestep the scoping keywords using 'var' instead. Thus: var $callback as 0751; Would define a property that contains an anonymous function that could be called by anyone, inspected by the class related class, but only set by the class itself! To follow up on this, and to give more readable code, we could also use this: var $callback as rwxrw---x; -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Regards, -- Florian Margaine
Re: [PHP-DEV] [RFC] UString
Hi, @Philip: please read the discussion that happened a month ago (and follow up on it if necessary): http://marc.info/?l=php-internalsm=141145952422734w=2 Regards, On Tue, Oct 21, 2014 at 11:19 AM, Philip Hofstetter phofstet...@sensational.ch wrote: Hello Tangentially related: On Tuesday, October 21, 2014, Dmitry Stogov dmi...@zend.com wrote: It won't allow Unicode strings as array keys; I wish there was a way for specific objects to opt into this. Using __toString() we have something that mostly behaves just like a string and can be used wherever a string is required - with the exception of array keys. I seem to remember some earlier discussion that led to this being intentionally made impossible (and I understand why), but maybe there could be support for another magic underscore method that's called when an object is about to be put into an array as a key (or similar situations) Philip -- Sensational AG Giesshübelstrasse 62c, Postfach 1966, 8021 Zürich Tel. +41 43 544 09 60, Mobile +41 79 341 01 99 i...@sensational.ch, http://www.sensational.ch -- Florian Margaine
Re: [PHP-DEV] New globals for PUT and DELETE
Hi, If it were me, I'd rather delete all the superglobals. It's a horrible API, I don't think anyone can deny that. Now of course, it'd break a tons of code, so I don't suggest to actually delete it. However, instead of trying to work around current superglobals and trying to provide meaningful names, how about actually trying to provide a correct API? I won't suggest a Request class, because such an interface is best left to userland imho. However, I'd like to propose such an API: request_get(): gets a request array/object. It only has the unparsed request headers. request_cookie_parse(): parses the requests cookie header in an array similar to $_COOKIE. $_COOKIE could use this new function to build its array. request_cookie_get($name): gets the value of $name in the cookie. Calls request_cookie_parse() if it hasn't been called before. request_urlencoded_body_parse(): parses an urlencoded body. It'd give an array similar to $_POST. request_urlencoded_body_get($name): gets the value of $name in the parsed urlencoded body. Calls request_urlencoded_body_parse() if it hasn't been done before. request_query_string_parse(): parses the query strings of a request. It'd give an array similar to $_GET. request_query_string_get($name): gets the value of $name in the parsed query string. Calls request_query_string_parse() if it hasn't been called before. Basically, stop using the mess that superglobals currently are ($_REQUEST or $_SERVER), and start providing a sane, *very basic* API. The functionality remain the same, yet the API is actually sane. It allows userland to use this basic API and can easily build up on it. Maybe this is actually a non-issue and I'm thinking too much... just my $0.02. Regards, On Tue, Oct 14, 2014 at 6:18 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 10/14/2014 09:15 AM, Mike Dugan wrote: On October 14, 2014 at 11:57:26 AM, Rasmus Lerdorf (ras...@lerdorf.com mailto:ras...@lerdorf.com) wrote: On 10/14/2014 06:29 AM, Andrea Faulds wrote: On 14 Oct 2014, at 14:27, Kristopher kristopherwil...@gmail.com wrote: $_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake. Ew, non-superglobals. But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY (for $_GET) and $_BODY (for $_POST)? Then the variable set finally makes sense, but isn’t too long: * $_QUERY - query string parameters * $_BODY- request body parameters * $_REQUEST - query string and request body parameters Makes more sense than $_GET and $_POST. Any objections? It makes no sense to me to make $_BODY an alias for $_POST. $_POST implies the default body encoding that a broswer performs on a POST request. Making an alias called $_BODY that doesn't contain the body of a request unless it is POST-encoded would be super confusing. I think the pedantry level around this is rather high. Nobody is actually confused about $_GET and $_POST and how and when to use them. Adding vague aliases adds confusion to something that had no confusion before. -Rasmus For clarity, $_BODY was revised to $_FORM. I think there was some misunderstanding of the usage of $_GET earlier in this thread, although I may have misunderstood someone’s wording. Regardless, if I go out and sample 100 PHP folks, I’m fairly confident someone would make the association that either $_GET or $_POST is bound strictly to the HTTP verb of the same name. Adding aliases gives these vars a more semantic name while not causing a massive BC breakage. I think 20+ years of history has proven this to be a non-issue. Of all the things that people get confused by in PHP, $_GET/$_POST are right near the bottom of the list. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Florian Margaine
Re: [PHP-DEV] New globals for PUT and DELETE
Erratum: all the request_* functions except request_get() take the request object/array as 1st argument. Le 14 oct. 2014 18:21, Florian Margaine flor...@margaine.com a écrit : Hi, If it were me, I'd rather delete all the superglobals. It's a horrible API, I don't think anyone can deny that. Now of course, it'd break a tons of code, so I don't suggest to actually delete it. However, instead of trying to work around current superglobals and trying to provide meaningful names, how about actually trying to provide a correct API? I won't suggest a Request class, because such an interface is best left to userland imho. However, I'd like to propose such an API: request_get(): gets a request array/object. It only has the unparsed request headers. request_cookie_parse(): parses the requests cookie header in an array similar to $_COOKIE. $_COOKIE could use this new function to build its array. request_cookie_get($name): gets the value of $name in the cookie. Calls request_cookie_parse() if it hasn't been called before. request_urlencoded_body_parse(): parses an urlencoded body. It'd give an array similar to $_POST. request_urlencoded_body_get($name): gets the value of $name in the parsed urlencoded body. Calls request_urlencoded_body_parse() if it hasn't been done before. request_query_string_parse(): parses the query strings of a request. It'd give an array similar to $_GET. request_query_string_get($name): gets the value of $name in the parsed query string. Calls request_query_string_parse() if it hasn't been called before. Basically, stop using the mess that superglobals currently are ($_REQUEST or $_SERVER), and start providing a sane, *very basic* API. The functionality remain the same, yet the API is actually sane. It allows userland to use this basic API and can easily build up on it. Maybe this is actually a non-issue and I'm thinking too much... just my $0.02. Regards, On Tue, Oct 14, 2014 at 6:18 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 10/14/2014 09:15 AM, Mike Dugan wrote: On October 14, 2014 at 11:57:26 AM, Rasmus Lerdorf (ras...@lerdorf.com mailto:ras...@lerdorf.com) wrote: On 10/14/2014 06:29 AM, Andrea Faulds wrote: On 14 Oct 2014, at 14:27, Kristopher kristopherwil...@gmail.com wrote: $_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake. Ew, non-superglobals. But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY (for $_GET) and $_BODY (for $_POST)? Then the variable set finally makes sense, but isn’t too long: * $_QUERY - query string parameters * $_BODY- request body parameters * $_REQUEST - query string and request body parameters Makes more sense than $_GET and $_POST. Any objections? It makes no sense to me to make $_BODY an alias for $_POST. $_POST implies the default body encoding that a broswer performs on a POST request. Making an alias called $_BODY that doesn't contain the body of a request unless it is POST-encoded would be super confusing. I think the pedantry level around this is rather high. Nobody is actually confused about $_GET and $_POST and how and when to use them. Adding vague aliases adds confusion to something that had no confusion before. -Rasmus For clarity, $_BODY was revised to $_FORM. I think there was some misunderstanding of the usage of $_GET earlier in this thread, although I may have misunderstood someone’s wording. Regardless, if I go out and sample 100 PHP folks, I’m fairly confident someone would make the association that either $_GET or $_POST is bound strictly to the HTTP verb of the same name. Adding aliases gives these vars a more semantic name while not causing a massive BC breakage. I think 20+ years of history has proven this to be a non-issue. Of all the things that people get confused by in PHP, $_GET/$_POST are right near the bottom of the list. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Florian Margaine
Re: [PHP-DEV] ArrayPath
Hi!
How is it better than:
$idx3 = $_POST['idx1']['idx2']['idx3'];
?
Regards,
Florian Margaine
Le 7 oct. 2014 18:05, Mathias Grimm mathiasgr...@gmail.com a écrit :
Hi,
I would like to suggest something for php like a class I am using
https://github.com/mathiasgrimm/arraypath
The reason is to access arrays like this:
$idx3 = ArrayPath::get('idx1/idx2/idx3', $_POST, 'myDefaultValue');
Regards,
Mathias
Re: [PHP-DEV] Re: Remove generated lexers from git?
Hi, Sorry to intrude, but why would building be harder? Tbh I don't see the point of keeping generated files in git. Why not keep release binaries too! (I'm kidding ofc.) Also, there may be a small number of big diffs, but one is enough to introduce a bug. Generating the file every time ensures there is no hidden bug. Just my 2 cents. Regards, Florian Margaine Le 2 oct. 2014 21:04, Stas Malyshev smalys...@sugarcrm.com a écrit : Hi! Case in point: The current zend_language_scanner.c has been generated by Andrea, who uses a different re2c version from everybody else (0.13.6 instead of 0.13.5). This means that if I do some tiny change to zend_language_scanner.l I immediately get a 3000 line diff. So we just end up changing this file back and forth depending on the algorithm used by different versions. So, from time to time we'd get a big diff. But what's a big problem with that? It doesn't seem to hurt anything. And language scanner is not changed every day. I don't see any benefit in such change, just making building PHP harder. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Remove generated lexers from git?
Hi, On Thu, Oct 2, 2014 at 10:12 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Sorry to intrude, but why would building be harder? Tbh I don't see the Because there are more dependencies and tools needed to build the parsers. You'd have to have recent re2c, for example. Which does not come by default with many systems. I see no reason to add this hurdle with no benefit for anybody. It's already necessary; PHP won't pass the configure step without re2c. Also, there may be a small number of big diffs, but one is enough to introduce a bug. Generating the file every time ensures there is no hidden bug. Which bug? They are generated parsers from the same source, what kind of bug you're talking about? Slipping in a malicious code in such a diff could easily go unnoticed, for instance. Or simply going to the file to see the generated code, leave a letter by mistake because the cat jumps on the keyboard, and there you go. I just mean that such big diffs are simply unreviewable; you have to trust that it was generated and not touched after. Why this unnecessary trust to give, when we can simply not have the file? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- Florian Margaine
[PHP-DEV] Should we dev on master then backport, or the other way?
Hi internals, The question is in the title :-) As far as I know, most projects follow this convention: develop on the master branch, then backport the fixes/features to older versions. I had a discussion with another core dev who told me he did the opposite: develop on PHP-5.5, then move the fix/feature up to the new branches (first PHP-5.6, then master). Is there a convention for php-src? Or is it whatever the dev wants? -- Regards, *Florian Margaine*
Re: [PHP-DEV] Should we dev on master then backport, or the other way?
I see, thanks for the answer! On Fri, Sep 26, 2014 at 1:43 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Fri, Sep 26, 2014 at 1:29 PM, Florian Margaine flor...@margaine.com wrote: Hi internals, The question is in the title :-) As far as I know, most projects follow this convention: develop on the master branch, then backport the fixes/features to older versions. I had a discussion with another core dev who told me he did the opposite: develop on PHP-5.5, then move the fix/feature up to the new branches (first PHP-5.6, then master). Is there a convention for php-src? Or is it whatever the dev wants? -- Regards, *Florian Margaine* see https://wiki.php.net/vcs/gitworkflow if a change affects multiple branch we commit it to the lowest possible branch and merge it upwards. there were a recent discussion about whether or not to change this, as the current master (aka PHP7) has major changes which makes the merge everything up strategy a lot more painful, but this discussion didn't reached a consensus so there are no change in the old workflow. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- Regards, *Florian Margaine*
Re: [PHP-DEV] Invokation on __toString() for object used as array key
Hi, Joe Watkins wrote (for fun) a new operator, `addressof`. Code is here: https://github.com/krakjoe/php-src/compare/addressof I think it makes more sense than a new method on all objects. You could use it for any kind of value: scalar, resource, object. Building an array of sockets, for example, would be very easy with such an operator. It would also give better tools to deal with situations such as: $test = 1; $test2 = $test; I'm willing to write an RFC if necessary to include it. Thoughts? On Thu, Sep 25, 2014 at 11:50 AM, Pierre Joye pierre@gmail.com wrote: On Wed, Sep 24, 2014 at 9:44 PM, Andrea Faulds a...@ajf.me wrote: On 24 Sep 2014, at 20:39, Stas Malyshev smalys...@sugarcrm.com wrote: I also wonder why we still need them. Doing what has been done with gmp for all resources would be a good move for 7. In general, I think we do not - IIRC everything resources do objects can do better now, and the problems that prevented one from using objects instead of resources are long gone. However, is_resource() checks and lots of third-party extensions using resources may be a bit of a problem for eliminating them. I already figured out how to solve the `is_resource()` issue. Create an almost-useless, uninstantiatable class called Resource which any new resource-replacing classes inherit from. Then, make `is_resource()` check whether something is an instance of that class. Of course, 3rd-party extensions are still a problem, but this should mostly fix it. Of course, gettype() is still going to return “object” not “resource”, but I suspect people are more likely to use is_resource(). Is it really necessary? I could imagine a transition with 5.7 for that, similar to gmp. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- Regards, *Florian Margaine*
Re: [PHP-DEV] Invokation on __toString() for object used as array key
Hi, I do believe that the UString class would benefit from such a change. Why would it be confusing to implement this? Regards, *Florian Margaine* Le 23 sept. 2014 12:42, Michael Wallner m...@php.net a écrit : On 2014-09-23 11:45, Leigh wrote: On 23 September 2014 10:35, Michael Wallner m...@php.net wrote: On 2014-09-23 11:15, Leigh wrote: He doesn't want to add the object as a key, he wants to invoke __toString(). Did I write that? No, you didn't, sorry. I just didn't see how an object with an explicit method to convert it to a string compared to using a resource straight up as a key. If you were implying the resource would be cast to int, then I get the comparison. Does it really make bugs that hard to find? You'd expect the user to know when they're using this behaviour when they write the code... well, I would. I suppose explicit casting removes any ambiguity, we use $a[(int)$resource] all the time for arrays of sockets and that's served us fine over the years. Hmm, thinking about it $a[(string)$object] is a lot clearer than having some magic sort it out. You're right, I'll retreat now :) I'm a victim of $array[(int) $resource] myself. I just tried to explain that the behavior is intentional and not an oversight. That doesn't mean that is set in stone for all times. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] #68049 filter_var echo wrong result for a url
Oh, IE. *sigh* Adding a new flag sounds like a good idea indeed, `FILTER_VALIDATE_UNCOMPLIANT_URL` sounds good enough? I guess it should accept underscores and domain names starting with numbers too. Regards, *Florian Margaine* P.S: sorry Kevin for the double mail. Le 22 sept. 2014 09:03, Kévin Dunglas dung...@gmail.com a écrit : Some browsers do. Some versions of IE are buggy when the URL include underscores: http://stackoverflow.com/questions/794243/internet-explorer-ignores-cookies-on-some-domains-cannot-read-or-set-cookies I think that filter_var must follow the RFC by default. Maybe can we add a flag to allow malformed URL in use in the wild? 2014-09-21 10:42 GMT+02:00 Florian Margaine flor...@margaine.com: Hi, According to https://bugs.php.net/bug.php?id=51192 , valid URLs cannot contain underscores. The following bug was reported a couple days ago: https://bugs.php.net/bug.php?id=68049 The thing is, browsers *do* accept the underscore in URLs. Should the rfc3986 http://tools.ietf.org/html/rfc3986#section-3.2.2 be respected, or should PHP be lenient like browsers and accept more? Regards, *Florian Margaine* -- Kévin Dunglas Consultant et développeur freelance http://dunglas.fr Tél. : 06 60 91 20 20
Re: [PHP-DEV] #68049 filter_var echo wrong result for a url
Sounds like a great idea! Don't forget to update https://bugs.php.net/bug.php?id=68049 when it'll be done. Regards, *Florian Margaine* On Mon, Sep 22, 2014 at 9:20 AM, Kévin Dunglas dung...@gmail.com wrote: I've recently proposed a refactoring of FILTER_VALIDATE_URL: https://github.com/php/php-src/pull/826 I can easily add the support of this new flag is everyone agree. 2014-09-22 9:09 GMT+02:00 Florian Margaine flor...@margaine.com: Oh, IE. *sigh* Adding a new flag sounds like a good idea indeed, `FILTER_VALIDATE_UNCOMPLIANT_URL` sounds good enough? I guess it should accept underscores and domain names starting with numbers too. Regards, *Florian Margaine* P.S: sorry Kevin for the double mail. Le 22 sept. 2014 09:03, Kévin Dunglas dung...@gmail.com a écrit : Some browsers do. Some versions of IE are buggy when the URL include underscores: http://stackoverflow.com/questions/794243/internet-explorer-ignores-cookies-on-some-domains-cannot-read-or-set-cookies I think that filter_var must follow the RFC by default. Maybe can we add a flag to allow malformed URL in use in the wild? 2014-09-21 10:42 GMT+02:00 Florian Margaine flor...@margaine.com: Hi, According to https://bugs.php.net/bug.php?id=51192 , valid URLs cannot contain underscores. The following bug was reported a couple days ago: https://bugs.php.net/bug.php?id=68049 The thing is, browsers *do* accept the underscore in URLs. Should the rfc3986 http://tools.ietf.org/html/rfc3986#section-3.2.2 be respected, or should PHP be lenient like browsers and accept more? Regards, *Florian Margaine* -- Kévin Dunglas Consultant et développeur freelance http://dunglas.fr Tél. : 06 60 91 20 20 -- Kévin Dunglas Consultant et développeur freelance http://dunglas.fr Tél. : 06 60 91 20 20
Re: [PHP-DEV] ext/date arguments handling
Hi Derick, Thanks for your answer! Indeed, I did plan on doing another PR for 5.6 while keeping ZEND_ARG_INFO. I'll review your notes and take care of them. Regards, *Florian Margaine* On Mon, Sep 22, 2014 at 1:29 PM, Derick Rethans der...@php.net wrote: Hi Florian, On Sun, 21 Sep 2014, Florian Margaine wrote: I specifically mean to ask @derick about this issue I'm having, since he is the maintainer of ext/date. I wrote this pull request for the DateTimeZone::getOffset method to accept a DateTimeInterface instead of a DateTime object: https://github.com/php/php-src/pull/831 Instead of using ZEND_ARG_INFO, I use ZEND_ARG_OBJ_INFO rather than relying on zpp only. It makes the code consistent with the type hinting errors that should arise, and also gives a correct reflection. However, the rest of the code in this extension uses ZEND_ARG_INFO, only throwing warnings when the arguments are not of the right kind. Should I use ZEND_ARG_INFO and rely on zpp's warning, or should I use ZEND_ARG_OBJ_INFO, and eventually translate the other methods to use it too? This'd be out of this PR of course, but it makes sense to streamline the methods of ext/date. I think it should use ZEND_ARG_OBJ_INFO. However, I am not sure whether we can do that in 5.x because of BC reasons. It's these tiny mistakes that are the larger BC problems. So I would suggest that you make a PR for 5.6 without ZEND_ARG_OBJ_INFO, and one for 7 with ZEND_ARG_OBJ_INFO. I think the patch looks mostly good too. I would recommend you squash the commits into a single commit though. cheers, Derick
[PHP-DEV] VCS Account Request: fmargaine
Hi, Having done a few PRs now, I\#039;d like to assign bugs to myself on bugs.php.net to avoid having several people working on the same one. For this, I need a php.net account :-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Integer Semantics
Hi, Just a side remark: from an external point of view, it seems like you need an application to handle the RFCs. An application with a strict business logic, which leaves no ambiguity as to when and how an RFC should be valid. The what is more ambiguous however, and I'm not sure as to how it should be handled. Regards, *Florian Margaine* On Mon, Sep 22, 2014 at 10:05 PM, Levi Morrison le...@php.net wrote: On Mon, Sep 22, 2014 at 3:37 PM, Pierre Joye pierre@gmail.com wrote: On Sep 22, 2014 3:31 PM, Derick Rethans der...@php.net wrote: On Mon, 22 Sep 2014, Michael Wallner wrote: On 2014-09-22 14:08, Andrea Faulds wrote: On 22 Sep 2014, at 12:06, Derick Rethans der...@php.net wrote: I would also like to point out that, just like a 8:8 vote is not a 50% majority, 16:8 is technically also not a two thirds *majority*. The RFC, like with many other important things is of course too vague on this. The +1 is only for 50% majorities. An 8:8 vote is not a majority, no, but a 9:8 would be a 50%+1 majority. A 16:8 vote *is* a 2/3 majority. Yes, I think so, too. I disagree, but the main point was something else. Right, but what would be 2/3 of 24 votes for you then? The voting RFC should be more clear on this. I don't think it is now. It's a pretty vague RFC in the first place, and leaves way too much open for interpretation. For? # of votes? I have actually been working with several other people trying to come up with smarter rules for the way we work with RFCs. Undoubtably, confusion about what constitutes a language change is a huge issue. To be completely honest, I would prefer that we require 2/3 on all RFCs. PHP is a mature language; if we can't get 2/3 to agree on something it probably isn't good for the whole of the PHP project. I don't want to say anything else here, as technically this is thread hijacking (sorry Andrea) but I am very interested in collaborating with anyone who would like to try to improve the RFC process. Perhaps reply to me off-list if you are also interested.
[PHP-DEV] #68049 filter_var echo wrong result for a url
Hi, According to https://bugs.php.net/bug.php?id=51192 , valid URLs cannot contain underscores. The following bug was reported a couple days ago: https://bugs.php.net/bug.php?id=68049 The thing is, browsers *do* accept the underscore in URLs. Should the rfc3986 http://tools.ietf.org/html/rfc3986#section-3.2.2 be respected, or should PHP be lenient like browsers and accept more? Regards, *Florian Margaine*
[PHP-DEV] ext/date arguments handling
Hi list, I specifically mean to ask @derick about this issue I'm having, since he is the maintainer of ext/date. I wrote this pull request for the DateTimeZone::getOffset method to accept a DateTimeInterface instead of a DateTime object: https://github.com/php/php-src/pull/831 Instead of using ZEND_ARG_INFO, I use ZEND_ARG_OBJ_INFO rather than relying on zpp only. It makes the code consistent with the type hinting errors that should arise, and also gives a correct reflection. However, the rest of the code in this extension uses ZEND_ARG_INFO, only throwing warnings when the arguments are not of the right kind. Should I use ZEND_ARG_INFO and rely on zpp's warning, or should I use ZEND_ARG_OBJ_INFO, and eventually translate the other methods to use it too? This'd be out of this PR of course, but it makes sense to streamline the methods of ext/date. In my opinion, using ZEND_ARG_OBJ_INFO means that we're going to the right direction: fixing the type hints and the reflection of the classes. The PR could be backported to 5.* by using ZEND_ARG_INFO to avoid BC breaks. Regards, *Florian Margaine*
[PHP-DEV] Request #67949 DOMNodeList should implement ArrayAccess
Hi list,
The request is so that we can do this:
$html = HTML
divdata/div
HTML;
$doc = new DOMDocument;
$doc-loadHTML($html);
var_dump($doc-getElementsByTagName('div')[0]-textContent);
I started implementing this on my branch (
https://github.com/Ralt/php-src/tree/issue-67949), but then I was
thinking... ::offsetSet and ::offsetUnset don't really make sense in this
context.
From what I understand, SimpleXML does some magic to make it work without
implementing ArrayAccess.
I think it's cleaner to use ArrayAccess and to throw errors on ::offsetSet
and ::offsetUnset, but I'd like internals' opinion on this.
Regards,
*Florian Margaine*
[PHP-DEV] Bug #68063: session-related, how to fix it?
Hi list,
I saw this interesting bug: https://bugs.php.net/bug.php?id=68063
Basically, if `session_id('')` is run before `session_start()`, weird
things happen.
The bug reporter proposes 2 ways to fix this:
- `session_start()` should silently fix the situation
- or `session_start()` should noisely fail
Both solutions look fine to me, but I'm not sure what PHP should do. Should
it be resilient and silently fix the situation?
Regards,
*Florian Margaine*
[PHP-DEV] setcookie() minor BC break - fixes issue #67736
Hi, This is a minor BC break, but still a BC break, so worth discussing on this ML. When a second setcookie() is done with the same name, a warning is emitted, because the ietf rfc 6265 says it *should* only send one Set-Cookie header per name. This is fine when display_errors is set to off. When it's set to on, the warning prevents the header from being added because headers already sent (which is the minor BC break, as current PHP just sends 2 Set-Cookie headers with the same name). So, should it be merged? What should be done to comply with the ietf rfc 6265? PR: https://github.com/php/php-src/pull/795/ PHP issue: https://bugs.php.net/bug.php?id=67736 Regards, *Florian Margaine*
