Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
Am 25.10.2014 um 20:20 schrieb Stas Malyshev: somewhat relaxed rules there, but even then introducing new debugging protocol into PHP core seems to be something that warrants some notification. That would have been my next question. I think it does not only warrant notification but adherence to the RFC process. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP-DEV] Thoughts on the PHP.net website
On 25/10/14 17:24, Levi Morrison wrote: The reason I bring this up in this discussion is that switching to something like Polymer is going to require a few changes on how we generate the HTML and CSS. The the best time to refactor code is when you are already changing it for something already, so it would be better to delay refactoring code until we have some need to change it. Can I make a simple request ... Rather than once again pushing yet more ways to render web pages can we take a look at something which is rather fundamental to good design. MVC is something which the likes of Zend Framework and other systems push but seems to be something alien to the php website? There is a substantial volume of material contained on the website and none of it is in a format that allows for easy access and more important searching. Each area has it's own material lost in some different 'favourite package' and currently even a 'search' does not even bring up - for example - the document sections or bug reports - when one searches on a wiki page. What use is a 'refactoring of code' when the whole structure is so badly broken? Providing a central 'database' of content such as articles about meetings, comments on ANY page, drafts for document improvements and so on will allow people to access that content in many more ways than currently possible, KEEP old versions of styles of layout if that is what they want, and allow a much more accessible and growing archive of material which can be translated as required. I understand that this brings up another debate on a standard for maintaining that data, but that is something of a red herring since HOW people store the data themselves is entirely up to them. It is purely how the data is accessed which matters here, and there are many existing standards for that. Much as I detest XML is does provide a very flexible platform for querying and transferring data with additional cleanly identified tag such as author, version, and the like. There will be several 'pet' solutions as to how a central store will be maintained, and I can almost even see a case for a flat file structure on git? Much as is currently used for some areas of the site anyway. Is there any support for at least looking at this? ( Copied back to internals as the mechanisms to support this need the expertise of people who probably do not follow the webmaster list ) -- 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
Re: [PHP-DEV] [RFC] Readonly Properties
On 24/10/2014 12:54, Andrea Faulds wrote: On 24 Oct 2014, at 10:29, Jordi Boggiano j.boggi...@seld.be wrote: Thanks for the work (again). It's an interesting small idea but I'd much prefer revisiting the original getter/setter RFC [1] which had a majority but just fell short of the 66% mark. This RFC only implements parts of the getter/setter functionality (readonly properties) but it does not address the fact that sometimes you want to add logic to a setter or a getter and if you don't have language level getters/setters you end up having to change the interface of the object from a public property to a getFoo/setFoo pair. This leads to everyone having getFoo/setFoo by default just to avoid interface changes or mixed interfaces of public properties and setFoo. On 24 Oct 2014, at 10:34, Pierre Joye pierre@gmail.com wrote: As much i really like the idea to have better properties management in PHP I see this RFC as an attempt to solve only part of the problem while dropping most of the other ideas implemented in the past RFCs. My take on that is that some will vote no, or won't like the idea of adding anything in this area. Making compromises and implement partial solutions will only delay the implementation of the complete solution. Many of us agree that __get/__set is a pain to deal with.The need of readonly, writeonly or properties with some logic to define or get a value is a lond due need. Many other languages support that out of the box since long already. Past RFCs, like the c# one, proposed that. I would rather focus on trying to find an acceptable syntax and implementation instead of doing baby steps like that. Baby steps work very well for scalar type hinting, solving one issue after another, etc. But for properties we are at the risk of hainvg a serie of separate RFCs solving the properties management problems in different ways bringing even more troubles and inconsistencies. I think I might be misunderstood, here. While getters and setters can do this, and I’m very much in favour of also reviving a simplified version of the getter/setter RFC (previous one was way too complex), I don’t see this as partly implementing them/baby steps/etc. I fact, I think readonly properties could work together with getters/setters. Fair enough, thanks for the clarification. It also sounds good to have very simple getter/setters when needed and simple properties + eventually readonly otherwise. issetters/unsetters aren't extremely needed. Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
On Sun, Oct 26, 2014 at 3:24 AM, Joe Watkins pthre...@pthreads.org wrote: I'd like to everyone to stay grounded in reality and say that we have been checking code into php-src for months, very very few people have expressed an interest in what we were actually doing, you aren't one of them Stas. As much as I do not like the way this topic was brought to the list. A point has been raised. The chnages done in the latest patches, like the XML based protocol, are not small changes and will affect us, our users and external tools for a long time.I understand that discussing things too much prior to apply it takes time, energy and sometimes could kill the motivation, but this is how we reach consensus. I do not think it is too late to have this discussion, maybe part of the php specification too.I am a big fan of phpstorm, but it is by far not the only tool around. The discussions here, if we filter out the classic bashing and not so well formulated critics, try to figure out if the choices are actually the best ofr php, now and for the next years. So. Yes, I also have to ask, humbly, both of you to also stay grounded and accept to participate in a constructive discussion. Maybe push up a RFC, documenting the current XML protocol, see the pros/cons, etc. Other can also join this effort. I am sure we can find answers to all these questions soon, if we leave the sentimental parts of this discussions out of this, focusing on the actual technical and design facts. 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] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
Am 26.10.2014 um 12:58 schrieb Pierre Joye pierre@gmail.com: On Sun, Oct 26, 2014 at 3:24 AM, Joe Watkins pthre...@pthreads.org wrote: I'd like to everyone to stay grounded in reality and say that we have been checking code into php-src for months, very very few people have expressed an interest in what we were actually doing, you aren't one of them Stas. As much as I do not like the way this topic was brought to the list. A point has been raised. The chnages done in the latest patches, like the XML based protocol, are not small changes and will affect us, our users and external tools for a long time.I understand that discussing things too much prior to apply it takes time, energy and sometimes could kill the motivation, but this is how we reach consensus. I do not think it is too late to have this discussion, maybe part of the php specification too.I am a big fan of phpstorm, but it is by far not the only tool around. The discussions here, if we filter out the classic bashing and not so well formulated critics, try to figure out if the choices are actually the best ofr php, now and for the next years. So. Yes, I also have to ask, humbly, both of you to also stay grounded and accept to participate in a constructive discussion. Maybe push up a RFC, documenting the current XML protocol, see the pros/cons, etc. Other can also join this effort. I am sure we can find answers to all these questions soon, if we leave the sentimental parts of this discussions out of this, focusing on the actual technical and design facts. Cheers, -- Pierre @pierrejoye | http://www.libgd.org http://www.libgd.org/ I’m fully aware that this is a phpng-style push in a bit smaller scope. And, despite whether that’s in spirit of open source (I’m not so sure if it really isn’t), it was something that had to be done. It’s not yet too late, we can still polish things which aren’t fine in the protocol. Also, it was *necessary* to write the patch first to see how the protocol will also fit a bit into the code. But then I had to restructure the code a lot. And later the thing got so big it got just too much maintenance work to simultaneously develop on the master branch (in krakjoe/phpdbg repo) and xml-protocol branch, so I merged everything. By that time I had a lot of unrelated features and the XML protocol then in master. (At that point I didn’t think it might become an issue). Then more than a week later I found it relatively stable (maybe some polishing left, but ± stable). I considered to have more discussion before, but it’d have blocked all the other improvements pending (would probably have been too much work to separate things again and push). And one really needs a starting base before real discussion can take place (The patch alone IMO is anyway too big to be reviewed as is). So, I pushed. But let us not discuss if it really was a good idea to have it done that way - or not. Please rather discuss where the protocol can be improved, if it’s missing some features etc. There is a Markdown file about the protocol in sapi/phpdbg/xml.md, which is documenting the XML responses one might get. I’m aware that it’s not really well structured, I appreciate any help there. But mainly, please first review if the design of the protocol is okay. Quick info (because it already caused some confusion): input commands are the same for xml protocol than for interactive mode. It’s just the output which differs. Bob p.s.: I don’t regret to have chosen XML - I mean, it’s now to late to discuss whether to choose XML or not, but I don’t regret the decisions I made there.
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
On Sat, 25 Oct 2014, Joe Watkins wrote: On Fri, 2014-10-24 at 23:06 -0400, Derick Rethans wrote: On Fri, 24 Oct 2014, Bob Weinand wrote: Commit:2bcac53bca8ea82d661f057b6d9ff3c7c84f05a7 Author:Bob Weinand bobw...@hotmail.com Fri, 24 Oct 2014 19:29:50 +0200 Parents: 53560ca06b333b71883269091f7d74c0a25e087b c03ac47bafd0ea55055a2f3d4de0bc6bb4d98d8d Branches: master Link: http://git.php.net/?p=php-src.git;a=commitdiff;h=2bcac53bca8ea82d661f057b6d9ff3c7c84f05a7 Log: Made phpdbg compatible with new engine snip AM sapi/phpdbg/xml.md Although this patch does make it work with PHP 7, it also does do something absolutely different: it reinvents a wheel by coming up with a new XML protocol for debugging. So far I've been silent on PHPDBG, but seriously, is it really not possible to cooperate instead of reimplementating something that already exists? PHPDBG is difficult to use with its odd command line commands. And then I haven't even spoken about the pretentious awesomesauce on http://phpdbg.com/ — a domain that's not even under the PHP group's control. A few weeks ago, I was at a conference where you told a room filled with hundreds of developers that phpdbg was no good, because you don't know how to use it. I was being polite. I should have told them it is useles for any of our users, instead of blaming it (wrongly) on my own ineptitude. This is a strange sort of silence, and does not invite us to co-operate. Neither does calling internals people dicks or knobs. When you invented dbgp there were other protocols in existence, There indeed where, but none of them were either open, or supporting more than one language. As that was the goal, the people from ActiveState—which *still, ten years later* have the best debugger frontend—and I sat around a table and implemented a language-agnostic debugging protocol. Used by Xdebug, and their debuggers for perl, python, tcl, ruby, and XSLT. not sure why we are expected to reuse a protocol. Because DBGp is virtually a standard in the PHP world. It so happens that the phpstorm guys working on integration seemed keen on something new. I don't see the problem in that. If the only reason it exists is for projects like phpstorm and they are actually going to put time into trying something new, then why the hell not. Well, if you'd have used DBGp, they wouldn't have to do any work. I'm not sure why it matters what kind of language we use on phpdbg.com, not sure why you think it should be under the control of the php group either. It shouldn't be anywhere near the PHP group either. It is run as a personal project with source dumps into PHP. Things run like that have no place in the core distribution. If you want to run your personal project, go ahead - but keep php.net out of it. If you had wanted to co-operate, you could have spoken to me at that conference in person, I tried. You disappeared after the first afternoon. 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
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
On 26 Oct 2014, at 15:09, Derick Rethans der...@php.net wrote: On Sat, 25 Oct 2014, Joe Watkins wrote: On Fri, 2014-10-24 at 23:06 -0400, Derick Rethans wrote: A few weeks ago, I was at a conference where you told a room filled with hundreds of developers that phpdbg was no good, because you don't know how to use it. I was being polite. I should have told them it is useles for any of our users, instead of blaming it (wrongly) on my own ineptitude. Perhaps you could’ve actually talked about its benefits. I went to that talk too. You showed off stuff vld can do… and neglected to mention that phpdbg could do the same things. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
On Sat, 25 Oct 2014, Weinand Bob wrote: Just a minor question, Derick. If you care about phpdbg, why are you only dropping any comment about it by the time it got into php-src repo? Yes, my mistake. I should have voted -1, but as I thought there was a conflict of interest, I stayed silent. It’s known that all the development currently (except for master, but that just was a merge and then a pure rewrite on top of that merge, nothing related to the protocol) is going on in krakjoe/phpdbg github repo. There was now an xml-protocol branch for three weeks before it got merged into krakjoe/phpdbg#master. You had vast time to notice it and complain before, if you’d really have cared. Sorry, but do you really expect people to follow some random person's github repo+branch for something that gets source-dumped into php-src? To reply to your question: why not use another debugger protocol? I had first really looked for other protocols, but none really fitted our needs. There was just DBGp which approximated our needs. At the beginning I had tried to implement a slightly modified variant of DBGp, but it accumulated minor differences here and there… And that then doesn’t make much sense again. Indeed - it's after all a documented protocol. That was the time where we decided to implement our own protocol. I don't even see *why* you want to write a whole new remote debugger in the first place. Before you ask, an incomplete list of such differences: - connecting: phpdbg is the server, not the client (as opposed to what DBGp requires) And for good reasons... as it doesn't require people to do fiddly command line stuff to debug multiple requests. - no need for the proxy thing - breakpoints: we have an opline-wise breaking (I have no idea, but maybe an IDE might want to break before the fcall is done) doesn’t fit into current list of attributes - It is under some circumstances possible to not be able to provide a full response (e.g. we’ve done a hard interrupt (that means, instant, asynchronous interrupt, even when engine is in control of it)) - DBGp provides no mechanism to handle it - stdout, stderr commands also don’t really work with phpdbg — it’s always redirect mode These three points are valid, but then there is (probably) also no reason why it couldn't be added. And there is also no requirement for stdout/stderr to be implemented. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
On Sat, 25 Oct 2014, Leigh wrote: On 25 October 2014 12:00, Weinand Bob bobw...@hotmail.com wrote: ... Thanks Bob. So my question is: Obviously the phpdbg requirements do not map to DBGp. However, can all of the requirements of DBGp be mapped to the phpdbg XML? Going forward does the XML protocol cover everything XDebug needs? Can we do DBGp over XML? DBGp is XML. This question makes no sense. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
On Sat, 25 Oct 2014, Stas Malyshev wrote: That said, we are where we are, and I think it would be great if this would somehow server as a starting point for developing a unified protocol for debugging PHP. It already exists: DBGp. It's implemented by dozens of editors and plugins. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
On Sat, 25 Oct 2014, Joe Watkins wrote: We will notify internals of our intentions to make such changes in future, if we thought there was any chance of any feedback before today, we would already be doing so. We will notify internals. Really? Sadly, this phpdbg stuff is part of internals, so the we and internals mean the same thing. If you want to run this as a private project, get it out of php-src. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
On Sun, 26 Oct 2014, Andrea Faulds wrote: On 26 Oct 2014, at 15:09, Derick Rethans der...@php.net wrote: On Sat, 25 Oct 2014, Joe Watkins wrote: On Fri, 2014-10-24 at 23:06 -0400, Derick Rethans wrote: A few weeks ago, I was at a conference where you told a room filled with hundreds of developers that phpdbg was no good, because you don't know how to use it. I was being polite. I should have told them it is useles for any of our users, instead of blaming it (wrongly) on my own ineptitude. Perhaps you could’ve actually talked about its benefits. I went to that talk too. You showed off stuff vld can do… and neglected to mention that phpdbg could do the same things. Some of it, certainly. A future version of the talk (ie, next week at ZendCon) will show the difference, so that the audience can judge for themselves what is better. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
Am 26.10.2014 um 16:17 schrieb Derick Rethans der...@php.net: On Sat, 25 Oct 2014, Weinand Bob wrote: Just a minor question, Derick. If you care about phpdbg, why are you only dropping any comment about it by the time it got into php-src repo? Yes, my mistake. I should have voted -1, but as I thought there was a conflict of interest, I stayed silent. That’s definitely your mistake. I also don’t remember that you seriously commented about the original RFC. It’s known that all the development currently (except for master, but that just was a merge and then a pure rewrite on top of that merge, nothing related to the protocol) is going on in krakjoe/phpdbg github repo. There was now an xml-protocol branch for three weeks before it got merged into krakjoe/phpdbg#master. You had vast time to notice it and complain before, if you’d really have cared. Sorry, but do you really expect people to follow some random person's github repo+branch for something that gets source-dumped into php-src? I agree, that was a bad argument. That was just in comparison to phpng which was developed completely closed-source. To reply to your question: why not use another debugger protocol? I had first really looked for other protocols, but none really fitted our needs. There was just DBGp which approximated our needs. At the beginning I had tried to implement a slightly modified variant of DBGp, but it accumulated minor differences here and there… And that then doesn’t make much sense again. Indeed - it's after all a documented protocol. That was the time where we decided to implement our own protocol. I don't even see *why* you want to write a whole new remote debugger in the first place. It wasn’t my idea. It was requested. There are issues on more than one bugtracker about phpdbg inclusion in the IDE. See, people want it. So, I just give them the underlying mechanisms so that they can use it inside their favorite IDE. Before you ask, an incomplete list of such differences: - connecting: phpdbg is the server, not the client (as opposed to what DBGp requires) And for good reasons... as it doesn't require people to do fiddly command line stuff to debug multiple requests. It still doesn’t. The IDE will handle it for you. (IDE creates a ssh connection and starts the phpdbg process - you don’t have to do anything.) - no need for the proxy thing - breakpoints: we have an opline-wise breaking (I have no idea, but maybe an IDE might want to break before the fcall is done) doesn’t fit into current list of attributes - It is under some circumstances possible to not be able to provide a full response (e.g. we’ve done a hard interrupt (that means, instant, asynchronous interrupt, even when engine is in control of it)) - DBGp provides no mechanism to handle it - stdout, stderr commands also don’t really work with phpdbg — it’s always redirect mode These three points are valid, but then there is (probably) also no reason why it couldn't be added. And there is also no requirement for stdout/stderr to be implemented. Sorry, but I had the impression you weren’t cooperative with anyone. That’s why I didn’t approach you and try to discuss friendly. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Thanks, Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
Am 26.10.2014 um 16:22 schrieb Derick Rethans der...@php.net: On Sat, 25 Oct 2014, Joe Watkins wrote: We will notify internals of our intentions to make such changes in future, if we thought there was any chance of any feedback before today, we would already be doing so. We will notify internals. Really? Sadly, this phpdbg stuff is part of internals, so the we and internals mean the same thing. If you want to run this as a private project, get it out of php-src. cheers, Derick As already said, it was an one-time mistake. If there are any major things to happen in phpdbg, we’ll drop a mail first here and only merge after eventual discussion. Thanks, Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
Am 26.10.2014 um 16:26 schrieb Derick Rethans der...@php.net: On Sun, 26 Oct 2014, Andrea Faulds wrote: On 26 Oct 2014, at 15:09, Derick Rethans der...@php.net wrote: On Sat, 25 Oct 2014, Joe Watkins wrote: On Fri, 2014-10-24 at 23:06 -0400, Derick Rethans wrote: A few weeks ago, I was at a conference where you told a room filled with hundreds of developers that phpdbg was no good, because you don't know how to use it. I was being polite. I should have told them it is useles for any of our users, instead of blaming it (wrongly) on my own ineptitude. Perhaps you could’ve actually talked about its benefits. I went to that talk too. You showed off stuff vld can do… and neglected to mention that phpdbg could do the same things. Some of it, certainly. A future version of the talk (ie, next week at ZendCon) will show the difference, so that the audience can judge for themselves what is better. cheers, Derick I’m certain it’ll still be biased somehow. Would be great if you could share with us what you’ll tell them, then maybe you can do a constructive talk about it. Thanks, Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
Am 26.10.2014 um 16:09 schrieb Derick Rethans der...@php.net: On Sat, 25 Oct 2014, Joe Watkins wrote: On Fri, 2014-10-24 at 23:06 -0400, Derick Rethans wrote: On Fri, 24 Oct 2014, Bob Weinand wrote: Commit:2bcac53bca8ea82d661f057b6d9ff3c7c84f05a7 Author:Bob Weinand bobw...@hotmail.com Fri, 24 Oct 2014 19:29:50 +0200 Parents: 53560ca06b333b71883269091f7d74c0a25e087b c03ac47bafd0ea55055a2f3d4de0bc6bb4d98d8d Branches: master Link: http://git.php.net/?p=php-src.git;a=commitdiff;h=2bcac53bca8ea82d661f057b6d9ff3c7c84f05a7 Log: Made phpdbg compatible with new engine snip AM sapi/phpdbg/xml.md Although this patch does make it work with PHP 7, it also does do something absolutely different: it reinvents a wheel by coming up with a new XML protocol for debugging. So far I've been silent on PHPDBG, but seriously, is it really not possible to cooperate instead of reimplementating something that already exists? PHPDBG is difficult to use with its odd command line commands. And then I haven't even spoken about the pretentious awesomesauce on http://phpdbg.com/ — a domain that's not even under the PHP group's control. A few weeks ago, I was at a conference where you told a room filled with hundreds of developers that phpdbg was no good, because you don't know how to use it. I was being polite. I should have told them it is useles for any of our users, instead of blaming it (wrongly) on my own ineptitude. No, xDebug has its use cases, phpdbg other use cases. They overlap many times. And it’s definitely not useless. I’ve already been able to debug real things with phpdbg and it works nicely for me. This is a strange sort of silence, and does not invite us to co-operate. Neither does calling internals people dicks or knobs“. That’s definitely a bad thing… could we please leave this genre of discussion out of internals? When you invented dbgp there were other protocols in existence, There indeed where, but none of them were either open, or supporting more than one language. As that was the goal, the people from ActiveState—which *still, ten years later* have the best debugger frontend—and I sat around a table and implemented a language-agnostic debugging protocol. Used by Xdebug, and their debuggers for perl, python, tcl, ruby, and XSLT. Hmm? I hardly could find anything about that with a few google searches... not sure why we are expected to reuse a protocol. Because DBGp is virtually a standard in the PHP world. Because something is used by the only open-source thing in a field, it doesn’t make it a standard. That you definitely have gotten wrongly. It so happens that the phpstorm guys working on integration seemed keen on something new. I don't see the problem in that. If the only reason it exists is for projects like phpstorm and they are actually going to put time into trying something new, then why the hell not. Well, if you'd have used DBGp, they wouldn't have to do any work. Ask them at PhpStorm. They were pleased to not have to use DBGp for it. They just initially requested it because they didn’t knew any better protocol. That’s all. I'm not sure why it matters what kind of language we use on phpdbg.com http://phpdbg.com/, not sure why you think it should be under the control of the php group either. It shouldn't be anywhere near the PHP group either. It is run as a personal project with source dumps into PHP. Things run like that have no place in the core distribution. If you want to run your personal project, go ahead - but keep php.net http://php.net/ out of it. phpdbg.com http://phpdbg.com/ is outdated, massively. That’s why we’re currently aiming to get a meaningful documentation to php.net http://php.net/. If you had wanted to co-operate, you could have spoken to me at that conference in person, I tried. You disappeared after the first afternoon. Maybe, but if you wouldn’t have given such a negatively talk on the phpdbg part, he maybe wouldn’t have disappeared. Maybe you just could have talked to Joe before and discussed constructively about phpdbg. cheers, Derick -- http://derickrethans.nl http://derickrethans.nl/ | http://xdebug.org http://xdebug.org/ Like Xdebug? Consider a donation: http://xdebug.org/donate.php http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
On 26/10/14 15:41, Bob Weinand wrote: Ask them at PhpStorm. They were pleased to not have to use DBGp for it. They just initially requested it because they didn’t knew any better protocol. That’s all. PHPStorm like PHP-FIG have their own agendas which do not play well with other groups of developers. Just because one thinks an idea is good does not mean that everybody else has to adopt it. So what becomes 'main stream' has to have common consensus and the voting rules provide that. When was the vote on this rework taken? -- 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
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
Am 26.10.2014 um 17:23 schrieb Lester Caine les...@lsces.co.uk: On 26/10/14 15:41, Bob Weinand wrote: Ask them at PhpStorm. They were pleased to not have to use DBGp for it. They just initially requested it because they didn’t knew any better protocol. That’s all. PHPStorm like PHP-FIG have their own agendas which do not play well with other groups of developers. Just because one thinks an idea is good does not mean that everybody else has to adopt it. So what becomes 'main stream' has to have common consensus and the voting rules provide that. When was the vote on this rework taken? -- 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 There wasn’t any vote and there won’t. /dev/null likes to listen to your complaints why we should have voted on it. But now it’s in, let’s rather try to improve what’s there than screaming for a vote - it won’t help anyone and hinder possible work on improving the current thing. Next time we’ll put a notice a few days before, it’s promised, yes. Thanks, Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
there's really nothing missing from PHP today to enable successful easy implementation of RESTful interfaces. Zeev, I could not create a REST interface that accepted multipart form data in uploading a file and form data in one PUT request. This is a valid part of a RESTful interface, yet PHP does not provide parsed data and file data for PUT like it does for POST (in the form of $_FILES and $_POST). 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 rather rely on the more-well tested parser which exists in PHP itself for POST. (A side-note: in my case it was deemed less risky to employ a load-balancer hack instead). 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). Dave. On 14 October 2014 14:56, Zeev Suraski z...@zend.com wrote: Personally, I like the idea of using more appropriately named aliases, particularly if they're roughly the same number of characters. However, we would need to allow at least several years for people to adopt the new globals before deprecating $_GET and $_POST. Ultimately, they will either need to be deprecated or the $_PUT and $_DELETE aliases will need to be added, otherwise the issue I raised would remain unresolved. Kris, Don't get this the wrong way, but $_GET and $_POST are not going to be deprecated. Whether or not we need $_PUT or $_DELETE is a separate, independent question from the axiom that $_GET and $_POST are here to stay. Personally, I don't think they make sense as Rasmus pointed out that $_GET and $_POST were never about HTTP methods but form methods, and there's really nothing missing from PHP today to enable successful easy implementation of RESTful interfaces. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Readonly Properties
On 24/10/2014 00:36, Andrea Faulds wrote:
Good evening once again,
Here’s another RFC: https://wiki.php.net/rfc/readonly_properties
It proposes, with a working implementation, a modifier for properties that
makes them readable and writeable from different scopes.
Since I am a big proponent of including specification patches in new RFCs, I
have decided to put my money (or rather, time) where my mouth is and I have
actually written a specification patch before writing an RFC. I would love to
see this become the new standard for RFCs affecting the language.
If you are curious at all about the behaviour, I suggest perusing the fairly
comprehensive set of twelve tests included in the main patch to php-src.
Thanks!
I just had a thought on both the naming and future-proofing concerns of
this proposal: what about pre-emptively reserving the skeleton of the
syntax needed for accessors, without actually implementing them?
For instance, one of the (confusingly many) syntaxes allowed by
https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 would have been this:
private $foo { public get; protected set; }
In that instance, this was seen as short-hand for the default proxy
method, but the effect is to modify the visibility of the property
without any extra behaviour.
If we remove the requirement to specify both get and set if the guard
clause is added, we get a simple syntax that covers the two cases the
RFC's readonly keyword does, plus one more:
// Current RFC
public readonly $foo; // read public, write protected
protected readonly $foo; // read protected, write private
// With only set keyword
public $foo { protected set; }
protected $foo { private set; }
public $foo { private set; } // read public, write private
// With only get keyword
protected $foo { public get; }
private $foo { protected get; }
private $foo { public get; }
// With both keywords, since var has been undeprecated
var $foo { public get; protected set; }
var $foo { protected get; private set; }
var $foo { public get; private set; }
This syntax does imply other combinations like private get; public
set; (effectively write-only from certain scopes), which may
complicate matters somewhat. To keep things simple, we could simply
enforce a rule at compile time that read visibility must not be more
restrictive than write visibility.
This gets rid of the ambiguity of the readonly keyword, and makes the
behaviour of read protected, write private much more obvious. It also
opens the door to syntax for accessors without placing much restriction
on how they could work...
// Forwards compatible to all these and more...
var $foo { public get { return $this-bar * 10; } private set; }
var $foo { public get() { return $this-bar * 10; } private set; }
var $foo { public get = $this-bar * 10; private set; }
var $foo { public get: existingMethod; private set; }
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Safe Casting Functions
On 24.10.2014 20:54, Andrea Faulds wrote: On 24 Oct 2014, at 19:52, Marc Bennewitz php@mabe.berlin wrote: Floats are special, they are not expected to be precise. If we reject this, then perhaps we should also reject 0.1, because it can’t be precisely represented by a float? It's a difference casting string to float or int to float. Floats are often used to make sure an argument is a valid number but this results in data loss incl. on internal functions. You’re not using the right function, then. That's not the point! We already have casting functions what will work in all cases even on data loss. I thought you are proposing safe casting functions with no data loss. If not, what are you proposing ? Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] disallow non-static method calls with self/static in PHP 7
On 12.10.2014 12:10, Nikita Popov wrote:
On Sun, Oct 12, 2014 at 10:37 AM, Robert Stoll p...@tutteli.ch wrote:
Hey,
I just stumbled over a method call of a non-static method with self and
was asking myself again, why does PHP support
this behaviour. An example to outline what I am writing of:
class A{
function foo(){
self::bar();
}
function bar(){}
}
IMO it should not be allowed to call non-static methods with self or
static. Sure, it is just a small detail but for
someone who starts learning PHP it is an unnecessary supplement.
Maybe it is too drastic to disallow it in PHP 7 but yeah. I would like to
know what you think about it and if someone
has a good reason why it is allowed nowadays then please help me out.
There's a common misconception that ::foo() denotes a static method call in
PHP. What it actually does is a *scoped* call (which is why :: is called
the scope resolution operator and not the static access operator).
What :: essentially does is give you the ability to call the implementation
of a method in a particular class. A common application is the use of
parent::foo() which will not call your implementation of foo(), but the one
found in the parent class. Similarly you can use A::foo() to target a
particular class that is even further up in the inheritance hierarchy
(like, the grandparent-class). You can also call call a class that is
completely outside your inheritance hierarchy, but that's deprecated since
PHP 5.6 and will hopefully be removed in PHP 7.
Theoretically spoken, the :: operator would be changeable to static
access operator.
Would that change any behavior outside of calling non static method
statically?
Would that open the possibility to register static methods in another
function table as object methods?
So e.g. it would be possible to have public static __call() instead of
public static __callStatic().
Nikita
Marc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
The only way to do this in PHP now is write a userland function that parses multipart form data, which is non-trivial. In addition to PECL HTTP, you might try PECL Mailparse, which is also going to be better-tested than anything written in userland. I sympathize with your overall point: even without a new superglobal, it would be cool to be able to reuse the same parser from $_POST. Still, just to put this out there: receiving multiparts via PUT can be part of a legit RESTful interface, but that doesn't mean that decoding multiparts should be automatic. It shouldn't be surprising that it PHP treats the entity as an opaque block of data by default, since it's perfectly RESTful for _the MIME-encoded body_ to be the stored resource. Imagine an e-mail archive that PUTs to /user/$username/sent/$messageid. Decoding the MIME message on resource create/update would be inappropriate in that case, a huge waste of resources. You might lazy-decode the resource only upon GET /user/$username/sent/$messageid/part/1. Within the same installation, you might want to decode other PUTs upon upload, so having a simple on/off for a new superglobal wouldn't work. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
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? -- 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] 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] New globals for PUT and DELETE
On Oct 26, 2014, at 4: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? 100% agree. Perhaps focusing on getting pecl/http v2 added as ext or core should be the real discussion: https://wiki.php.net/rfc/pecl_http https://wiki.php.net/rfc/pecl_http. 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? -- 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] New globals for PUT and DELETE
2014-10-26 23:24 GMT+02:00 Florian Margaine flor...@margaine.com: I think Rasmus made it clear what the original naming meant: it were form methods, not related at all to HTTP methods. Yes, this would be logical to have access to the input data, as single interface, do not make exceptions for POST, input data send methods PUT, DELETE, must be available in a single global variable, the variable name is not important file_get_contents(‘php://input') - uncomfortably -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Using objects as keys
Hi! I would like to present to your attention an RFC about using object as keys: https://wiki.php.net/rfc/objkey It was discussed in the past on the list: http://marc.info/?t=14114596961r=1w=2 and I think it makes sense to propose a formal RFC for it. Both the text and the code in the patch includes bits done by myself and Joe Watkins. The patch does not cover 100% of cases but should work for most reasonable scenarios, if something is wrong or you have ideas how to make it better please tell. The name __hash is not final, I am open to using __toKey instead or any reasonable alternative, we may also include a couple of options in the vote if that will be a point of disagreement. Thanks, Stas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On Oct 26, 2014, at 5:00 PM, Park Framework park.framew...@gmail.com wrote: 2014-10-26 23:24 GMT+02:00 Florian Margaine flor...@margaine.com: I think Rasmus made it clear what the original naming meant: it were form methods, not related at all to HTTP methods. Yes, this would be logical to have access to the input data, as single interface, do not make exceptions for POST, input data send methods PUT, DELETE, must be available in a single global variable, the variable name is not important file_get_contents(‘php://input') - uncomfortably Or, use pecl/http to handle it. GET/POST are form relative while all others are HTTP related. That’s been said quite a few times in this thread. You don’t have to use php://input php://input. pecl/http is available. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Using objects as keys
On Oct 26, 2014, at 8:37 PM, Stas Malyshev smalys...@gmail.com wrote: Hi! I would like to present to your attention an RFC about using object as keys: https://wiki.php.net/rfc/objkey Hi Stas! I’m trying to wrap my head around a real-world use-case with this. We have spl_object_hash, which effectively provides a unique hash for an object. If the intent is to provide an opportunity of individual classes to decide what their hash is, couldn’t they provide that via __toString? I know many frameworks use __toString to build out some implementation of an object (Zend form for example), but the point of __toString is to provide a string representation of an object. I want to say, I’m not at all against this - rather I support it. I’m just looking for the RFC to provide an example that I and others can relate to. It was discussed in the past on the list: http://marc.info/?t=14114596961r=1w=2 and I think it makes sense to propose a formal RFC for it. Both the text and the code in the patch includes bits done by myself and Joe Watkins. The patch does not cover 100% of cases but should work for most reasonable scenarios, if something is wrong or you have ideas how to make it better please tell. The name __hash is not final, I am open to using __toKey instead or any reasonable alternative, we may also include a couple of options in the vote if that will be a point of disagreement. Thanks, Stas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Using objects as keys
Hi! I’m trying to wrap my head around a real-world use-case with this. We have spl_object_hash, which effectively provides a unique hash for This hash has nothing to do with object's contents. But imagine number GMP(42) and imagine you actually want two GMP objects expressing 42 actually represent the same hash key. Or imagine you want to generate the key somehow in a way related to object's content and not just a random number. As I said in the RFC, evidence that so many languages implement it shows that this use case is quite real. Of course, you can always default to spl_object_hash, but now you have control over it. an object. If the intent is to provide an opportunity of individual classes to decide what their hash is, couldn’t they provide that via __toString? I know many frameworks use __toString to build out some implementation of an object (Zend form for example), but the point of __toString is to provide a string representation of an object. This is covered in the RFC, right in the introduction. -- 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] [RFC] Using objects as keys
On Oct 26, 2014, at 9:43 PM, Stas Malyshev smalys...@gmail.com wrote: Hi! I’m trying to wrap my head around a real-world use-case with this. We have spl_object_hash, which effectively provides a unique hash for This hash has nothing to do with object's contents. But imagine number GMP(42) and imagine you actually want two GMP objects expressing 42 actually represent the same hash key. Or imagine you want to generate the key somehow in a way related to object's content and not just a random number. As I said in the RFC, evidence that so many languages implement it shows that this use case is quite real. Of course, you can always default to spl_object_hash, but now you have control over it. Thank you for your clarity. With this new approach, wouldn’t we best be served by renaming/deprecating/removing spl_object_hash? I’m concerned these different approaches will introduce quite a bit of confusion with object hashing. This RFC’s approach gives the user more power to determine what’s best in this case, so I’d lean more towards renaming spl_object_hash to something that reflects getting a unique ID per object (e.g. spl_unique_object_id, etc). an object. If the intent is to provide an opportunity of individual classes to decide what their hash is, couldn’t they provide that via __toString? I know many frameworks use __toString to build out some implementation of an object (Zend form for example), but the point of __toString is to provide a string representation of an object. This is covered in the RFC, right in the introduction. -- 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] New globals for PUT and DELETE
pecl/http is available To a degree, but no binaries for Windows == not a universal prescription. Mailparse by contrast does have a shipping DLL. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On Oct 26, 2014, at 10:38 PM, Sanford Whiteman figureone...@gmail.com wrote: pecl/http is available To a degree, but no binaries for Windows == not a universal prescription. Mailparse by contrast does have a shipping DLL. I’m confused. pecl/http does have Windows binaries: http://windows.php.net/downloads/pecl/releases/http/ http://windows.php.net/downloads/pecl/releases/http/. Did I miss something? -- S.
Re: [PHP-DEV] New globals for PUT and DELETE
You're right. Guess the build system didn't update http://pecl.php.net/package/pecl_http with the DLL link as for other exts. -- S, On Mon, Oct 27, 2014 at 12:31 AM, Will Fitch willfi...@php.net wrote: On Oct 26, 2014, at 10:38 PM, Sanford Whiteman figureone...@gmail.com wrote: pecl/http is available To a degree, but no binaries for Windows == not a universal prescription. Mailparse by contrast does have a shipping DLL. I’m confused. pecl/http does have Windows binaries: http://windows.php.net/downloads/pecl/releases/http/. Did I miss something? -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
PUT, DELETE, must be available in a single global variable, the variable name is not important file_get_contents(‘php://input') - uncomfortably If the quibble were with file_get_contents(‘php://input') that's not sufficiently uncomfortable to warrant a new superglobal. I assume you mean parsing the contents of php://input into an associative array regardless of the content-type of the HTTP entity-body. However, you're glossing over the semantic difference between POSTing an entity-body and PUTing that same body. multipart/form-data is specified in RFC 1867 as POST-specific, with deliberate notes about expected server behavior. RFC 2388 expands form-data into a general mimetype regardless of transport, and theoretically regardless of HTTP method, but AFAIK there's no equivalent to 1867 that reasonably leads to auto-decoding PUT form-data into an associative array. Rather, the PUT payload has always been designed to _become_ the target resource, as-is. The POST payload is designed to be interpreted via the server's own semantics before changing any resource state. Thus there is a very strong reason to present POST data to the server in an easily accessible and mutable form. Not so for PUT. This doesn't mean PUT payloads must stay opaque to PHP, of course. If there's a need to validate the payload before overwriting the current resource state, that may require that it be passed through some binary image verification, validated against a DTD, or -- indeed -- decoded from multipart MIME into its parts for validation, even if it's the multipart representation that eventually gets stored. Yet if you feel that PUT content should be automatically decoded, you might as well apply this to other multipart content as well -- if I PUT an MHTML file or, as noted before, an RFC 822 e-mail, by this assumption those would also populate the new superglobal. Honestly if it didn't consume any extra resources to always populate, I wouldn't care. But to be unable to avoid decoding every giant multipart payload just because I _might_ want to look at the parts is highly inefficient. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Using objects as keys
On Sun, 2014-10-26 at 18:37 -0700, Stas Malyshev wrote: Hi! I would like to present to your attention an RFC about using object as keys: https://wiki.php.net/rfc/objkey It was discussed in the past on the list: http://marc.info/?t=14114596961r=1w=2 and I think it makes sense to propose a formal RFC for it. Both the text and the code in the patch includes bits done by myself and Joe Watkins. The patch does not cover 100% of cases but should work for most reasonable scenarios, if something is wrong or you have ideas how to make it better please tell. The name __hash is not final, I am open to using __toKey instead or any reasonable alternative, we may also include a couple of options in the vote if that will be a point of disagreement. Thanks, Stas Morning Stas, Nicely done. Whether SPL classes, or any other classes, should use the functionality should be left to another discussion. I wonder if it might be feasible to try and define what the contract of this method is, in the same kind of way as the Java docs do for Object.hashCode ? We can't have the exact same contract perhaps, but it might be useful to try to define it at this stage. It seems __toScalar might be a good name, this is what the method actually does, the engine then coerces to a type suitable for use as a key, but you can return a double. It might be more forward thinking therefore to use the name __toScalar, while today we'd only be using it for this, if we come up against the requirement to treat an object as a scalar for anything else, we have the machinery already and we don't have to add another magic method at that time. Not sure what others think about that ... I liked the name __hash better than __toKey, I like __toScalar better than those because it describes what the method is meant to do the best. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
