Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 29/10/2014 00:35, Stas Malyshev a écrit : Hi! phpdbg is under php.net ; every decision about phpdbg should then be debatted with all the team, and new ideas, such as a protocol, RFC'ed, whoever are the maintainers of the code. It's like that for every piece of code, of every extension. This is PHP process. If you dont want to Do I understand it right that after all we've being discussing here about not putting big new stuff into PHP without discussion, we've got new stuff in phpdbg now merged not only to master but into the stable branch of 5.6? Am I missing something here? Can you please consider reverting everything to stable state (5.6.2), and start discussing about pending changes ? Remi. -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlRQijwACgkQYUppBSnxahiPugCfWBHUcWQlFqq4tx/KrC95VqUK CsAAoN4YcKahsp3WFIX0CkEA7g7gDhrV =p9SK -END PGP SIGNATURE- -- 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 29/10/2014, at 12:43 AM, Julien Pauli jpa...@php.net wrote: On Mon, Oct 27, 2014 at 6:27 PM, David Soria Parra d...@php.net wrote: On 2014-10-26, Bob Weinand bobw...@hotmail.com wrote: 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. step back a bit here, stay professional, there is no need for passive aggressiveness. 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. From what I see, the complan is about the initial protocol and not about how to improve it or not. This whole protocol business needed an RFC, which I haven't seen. So we should come up with a good way of deciding which protocol to use and how to implement it. Before this, I would strongly vote to not incldue the current verison in PHP 7 at all. Also let me point out that the code belogns to everyone and everyone will have to deal with it so we better make an informed decision now. Hello people. When PHP 5.6 has been released, few weeks/months ago, I explicitely stated Ferenc (RMing 5.6 together with me), that *it is not a normal thing to have an external domain for phpdbg* This has never happened before, FWIR FYI, PHP-FPM still has a separate website. Cheers, David -- 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 Wed, Oct 29, 2014 at 12:35 AM, Stas Malyshev smalys...@gmail.com wrote: Hi! phpdbg is under php.net ; every decision about phpdbg should then be debatted with all the team, and new ideas, such as a protocol, RFC'ed, whoever are the maintainers of the code. It's like that for every piece of code, of every extension. This is PHP process. If you dont want to Do I understand it right that after all we've being discussing here about not putting big new stuff into PHP without discussion, we've got new stuff in phpdbg now merged not only to master but into the stable branch of 5.6? Am I missing something here? If you are talking about the phpdbg new debugging protocol : this is right. I think it clearly lacks discussion, RFC, concensus here, particularly regarding the choice of the protocol. We must absolutely use something open and efficient. Using a closed protocol, that only one editor would be able to implement ; is just a no-go ; for example. Julien.P -- 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 Wed, Oct 29, 2014 at 9:10 AM, David Muir davidkm...@gmail.com wrote: On 29/10/2014, at 12:43 AM, Julien Pauli jpa...@php.net wrote: On Mon, Oct 27, 2014 at 6:27 PM, David Soria Parra d...@php.net wrote: On 2014-10-26, Bob Weinand bobw...@hotmail.com wrote: 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. step back a bit here, stay professional, there is no need for passive aggressiveness. 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. From what I see, the complan is about the initial protocol and not about how to improve it or not. This whole protocol business needed an RFC, which I haven't seen. So we should come up with a good way of deciding which protocol to use and how to implement it. Before this, I would strongly vote to not incldue the current verison in PHP 7 at all. Also let me point out that the code belogns to everyone and everyone will have to deal with it so we better make an informed decision now. Hello people. When PHP 5.6 has been released, few weeks/months ago, I explicitely stated Ferenc (RMing 5.6 together with me), that *it is not a normal thing to have an external domain for phpdbg* This has never happened before, FWIR FYI, PHP-FPM still has a separate website. Yep, this came to my ears recently. I forgot about it. I have nothing against external web site, as soon as the PHP doc is clear, up-to-date and detailed. For phpdbg , this is actually not the case (yet ?), there is WIP however. Julien.P -- 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, Bob Weinand wrote: 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. 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. That's good to hear. But I have been speaking to the PhpStorm people here at ZendCon, and they give a different version of the story why you didn't pick DBGp. From what I understand, having to do another debugging protocol is really the last thing that they want. Drop me a line (privately) to see whether we can resolve the issues with the protocol that you had. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] forbid use declaration outside of a namespace in PHP 7
Heya,
I always found it very ugly that it is possible to define a use outside of a
namespace. Consider the following:
namespace{ //default namespace
}
use foo\Bar;
namespace test{
new Bar(); //error, test\Bar not found
}
After some thoughts it is quite clear that Bar is test\Bar and not foo\Bar
inside of the namespace test. But consider
the following example which is not so obvious:
use foo\Bar;
namespace test;
new Bar(); //error, test\Bar not found
The use declaration looks like a normal use declaration at first glance.
I do not see why we should actually support this feature any longer and thus
suggest to remove it in PHP 7. Although,
it is not a bug (the use declaration is simply ignored as far as I can tell) I
suppose it confuses the user.
Nevertheless, even if we declare it as a feature I think it should at least
not be a feature of the specification of
PHP 7.
Thoughts?
Cheers,
Robert
ps: I first started the discussion @standards, just if you should wonder why it
pops up here now as well:
http://news.php.net/php.standards/528
--
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, Bob Weinand wrote: 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: 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. I think this hits something on the spot: we don't define scope in an RFC. And scope creep is never a good thing. I would suggest that you come up with what scope phpdbg should solve, and don't get out of it. 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? Sorry, I think that it should be called out *just* because it's not appropriate in any case. 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... http://code.activestate.com/komodo/remotedebugging/ http://en.wikipedia.org/wiki/Project_Zero#PHP_support http://hhvm.com/blog/6239/hhvm-3-3-0 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. I used virtually as adjective. I perhaps should have used de facto[1]. [1] http://dictionary.reference.com/browse/de%20facto 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. So I actually did talk to them (in person, at ZendCon), and their account of events is pretty much the exact opposite. But in any case, that doesn't mean that reinventing the wheel again makes sense. It's certainly not helpful to for users, for which you are now fragmenting support. 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. Where you there? I don't think so. So please don't judge people on here-say information. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Readonly Properties
On 29 Oct 2014, at 04:29, Jordi Boggiano j.boggi...@seld.be wrote:
Yup that's definitely better than having the readonly flag in the {} block as
I had it.
I'd however say that it should be possible to define a writable property with
only a getter and then the setter would implicitly be created. Since readonly
is the way to define writability why should I have to specify a setter (even
a default empty one) if none is needed?
P.S: Don't want to open pandora's box, but we could also have writeonly for
completeness perhaps. I don't really see the use case at all though
(immutability sure, mutant bottomless pit objects not so much:).
I don’t think allowing write-only properties is a good idea if we need a new
keyword for it.
To be honest, for such a use case, using a setter method is probably better
than assigning as if it were a normal property. While people would probably
tolerate and understand read-only (from their perspective outside the class)
properties, I think write-only properties will just lead to poor API design and
confusion.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Volunteering for sysadmin help
I've heard through grapevine that PHP was looking for some extra help with some of the system administration tasks. I've been doing Linux administration for about 8 years, and currently run servers for developers that don't want to go through setting up their own servers. If there's any help that I can provide, I'd be glad to throw in my time to help out. -- Chris Tankersley http://ctankersley.com 419.785.6408
[PHP-DEV] Native TLS
Anatol has been doing some great work with Thread Local Storage (under the native-tls branch). I have tested it on Windows and its performance and functionality are now the same as master builds (with phpng), though a few extensions included with Windows builds haven't been ported yet. Performance results are here: http://windows.php.net/downloads/snaps/ostc/pftt/perf/ including http://windows.php.net/downloads/snaps/ostc/pftt/perf/results-20141028-master_r87c28cc-native_tls_r5747327-7146.html Note: the master and native-tls builds for Windows have lower performance than 5.5 or 5.6 builds because 5.6 and 5.6 builds are optimized builds (using Profile Guided Optimization) which is not currently done for master or native-tls builds. Regards -M
