Re: [PHP-DEV] [RFC][DISCUSSION] Constructor behaviour of internal classes

>> Consistency with userland is beneficial, because the majority of PHP >> developers probably do not expect `new` to yield anything than a >> concrete instance or an exception. > > Of course, consistency with userland is beneficial. However, in userland > we do not have many things that we have

[PHP-DEV] Re: Bug #69127 session_regenerate_id(true) randomly generates a warning and loses session data

Hi all, On Sun, Mar 1, 2015 at 1:53 PM, Yasuo Ohgaki wrote: > > > https://bugs.php.net/bug.php?id=69127 > > This bug is known fatal bug for session module. I proposed "lazy_destroy" > to fix > this before, but it declined. > > I think the name was wrong. With the proposal, session module destori

Re: [PHP-DEV] Consistent function names

Hi Michael, On Tue, Mar 3, 2015 at 3:03 PM, Michael Schuett wrote: > I can't think of any good use case for a bulk import outside of laziness. > Any good IDE will handle this for you and if you are importing as \ then > why don't you just not namespace them in the first place. Bulk import is n

Re: [PHP-DEV] Consistent function names

I can't think of any good use case for a bulk import outside of laziness. Any good IDE will handle this for you and if you are importing as \ then why don't you just not namespace them in the first place. On Mon, Mar 2, 2015 at 11:33 PM, Stanislav Malyshev wrote: > Hi! > > > I would love to have

Re: [PHP-DEV] Consistent function names

Hi! > I would love to have namespace that could be imported like > > namespace \php\7\function\* as \; // Import all functions to \ > namespace \php\7\function\* as \; Please no. When we designed namespaces, we explicitly omitted bulk imports, and the reasons that were true then are still true n

Re: [PHP-DEV] Consistent function names

Hi Lester, On Tue, Mar 3, 2015 at 9:19 AM, Lester Caine wrote: > On 02/03/15 23:54, Yasuo Ohgaki wrote: > > This looks awful... just cannot put up with... > Rasmus has already answered, but are you prposing to rewrite -> > http://www.gnu.org/software/gettext/manual/gettext.html I know we used

Re: [PHP-DEV] [RFC][DISCUSSION] Constructor behaviour of internal classes

Hi! > I'm not sure I can understand your crusade against this topic. I would start with trying to address my actual arguments, as opposed to dismissing it as a "crusade". I've described my arguments for it in my previous emails, is there something unclear there? I'd be happy to explain any point

Re: [PHP-DEV] Consistent function names

On 02/03/15 23:54, Yasuo Ohgaki wrote: > This looks awful... just cannot put up with... Rasmus has already answered, but are you prposing to rewrite -> http://www.gnu.org/software/gettext/manual/gettext.html -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?

Re: [PHP-DEV] Consistent function names

Hi Rasmus, On Tue, Mar 3, 2015 at 9:03 AM, Rasmus Lerdorf wrote: > These come from the underlying libaries. You can type "man dcgettext" or > "man bind_textdomain_codeset" at your Linux command line and learn a lot > about how these work. Plus, if you are a C dev, much like strlen(), > these are

Re: [PHP-DEV] Consistent function names

On 03/02/2015 03:54 PM, Yasuo Ohgaki wrote: > Hi Markus, Larry and Rowan, > > On Tue, Mar 3, 2015 at 8:36 AM, Markus Fischer wrote: > >> On 03.03.15 00:10, Yasuo Ohgaki wrote: >>> I would love to have new & clean APIs. >>> >>> Please think my proposal as legacy API cleanups. Many of candidates w

Re: [PHP-DEV] Consistent function names

Hi Markus, Larry and Rowan, On Tue, Mar 3, 2015 at 8:36 AM, Markus Fischer wrote: > On 03.03.15 00:10, Yasuo Ohgaki wrote: > > I would love to have new & clean APIs. > > > > Please think my proposal as legacy API cleanups. Many of candidates will > > remain > > without CORDING_STANDARSDS confirm

Re: [PHP-DEV] Consistent function names

On 03.03.15 00:10, Yasuo Ohgaki wrote: > I would love to have new & clean APIs. > > Please think my proposal as legacy API cleanups. Many of candidates will > remain > without CORDING_STANDARSDS confirmed names almost forever. This is what > I would like to improve. If you don't care about legacy

Re: [PHP-DEV] Consistent function names

On 3/2/15 5:10 PM, Yasuo Ohgaki wrote: I would love to have new & clean APIs. Please think my proposal as legacy API cleanups. Many of candidates will remain without CORDING_STANDARSDS confirmed names almost forever. This is what I would like to improve. If you don't care about legacy stuff cle

Re: [PHP-DEV] Consistent function names

On 02/03/2015 22:59, Yasuo Ohgaki wrote: Hi Rowan, On Tue, Mar 3, 2015 at 7:50 AM, Rowan Collins > wrote: On 02/03/2015 22:36, Yasuo Ohgaki wrote: I like scalar objects, but it does not resolve that PHP has non standard function name

Re: [PHP-DEV] Consistent function names

Hi Larry, On Tue, Mar 3, 2015 at 8:02 AM, Larry Garfield wrote: > On 3/2/15 4:50 PM, Rowan Collins wrote: > >> On 02/03/2015 22:36, Yasuo Ohgaki wrote: >> >>> I like scalar objects, but it does not resolve that PHP has non standard >>> function names. >>> It does not change old names, therefore

Re: [PHP-DEV] Consistent function names

On Mon, Mar 2, 2015 at 2:53 PM, Yasuo Ohgaki wrote: > Hi Rowan, > > On Tue, Mar 3, 2015 at 7:40 AM, Rowan Collins > wrote: > >> The issue here is PHP will keep inconsistent names forever or not. >>> IMHO. >>> >> >> Have you noticed the slight contradiction here? You want to get rid of the >> inco

Re: [PHP-DEV] Consistent function names

On 3/2/15 4:50 PM, Rowan Collins wrote: On 02/03/2015 22:36, Yasuo Ohgaki wrote: I like scalar objects, but it does not resolve that PHP has non standard function names. It does not change old names, therefore it's impossible to resolve issue. This is the reason why I'm proposing while I like sc

Re: [PHP-DEV] Consistent function names

Hi Rowan, On Tue, Mar 3, 2015 at 7:50 AM, Rowan Collins wrote: > On 02/03/2015 22:36, Yasuo Ohgaki wrote: > >> I like scalar objects, but it does not resolve that PHP has non standard >> function names. >> It does not change old names, therefore it's impossible to resolve issue. >> This is the r

Re: [PHP-DEV] Consistent function names

Hi Rowan, On Tue, Mar 3, 2015 at 7:40 AM, Rowan Collins wrote: > The issue here is PHP will keep inconsistent names forever or not. >> IMHO. >> > > Have you noticed the slight contradiction here? You want to get rid of the > inconsistent names, but you propose to keep the old, inconsistent, name

Re: [PHP-DEV] Consistent function names

On 02/03/2015 22:36, Yasuo Ohgaki wrote: I like scalar objects, but it does not resolve that PHP has non standard function names. It does not change old names, therefore it's impossible to resolve issue. This is the reason why I'm proposing while I like scalar object, use of namespace, etc. Aga

Re: [PHP-DEV] Consistent function names

On 02/03/15 22:09, Yasuo Ohgaki wrote: > > Old names works. No one forces users to use new names. > I'll update PHP documents. It's a lot of work, but I'll. > 3rd party documents may be update if they would like to. Some developers will drop PHP5 support for third party libraries in much the same

Re: [PHP-DEV] Consistent function names

On 02/03/2015 22:09, Yasuo Ohgaki wrote: I think old function names should exist forever, so there wouldn't be issue you mentioned. ... The issue here is PHP will keep inconsistent names forever or not. IMHO. Have you noticed the slight contradiction here? You want to get rid of the incons

Re: [PHP-DEV] Consistent function names

Hi Larry, On Tue, Mar 3, 2015 at 7:22 AM, Larry Garfield wrote: > > Sorry, I do not see how a new thread helps. Namespace either. These >> will only be duplicated APIs for little to no gain. Existing codes >> won't move as they won't be compatible with 5.x. >> >> We should really consider Nikit

Re: [PHP-DEV] Consistent function names

On 3/2/15 4:01 PM, Pierre Joye wrote: Sorry, I do not see how a new thread helps. Namespace either. These will only be duplicated APIs for little to no gain. Existing codes won't move as they won't be compatible with 5.x. We should really consider Nikita's experiment instead,as it acutally brin

Re: [PHP-DEV] Consistent function names

Hi Lester, On Tue, Mar 3, 2015 at 7:00 AM, Lester Caine wrote: > On 02/03/15 21:39, Yasuo Ohgaki wrote: > > I wrote almost complete list. Please take a look at > > > https://wiki.php.net/rfc/consistent_function_names#list_of_functions_to_be_renamed > > While the idea of this is well meant, this

Re: [PHP-DEV] Consistent function names

On 02/03/15 21:39, Yasuo Ohgaki wrote: > I wrote almost complete list. Please take a look at > https://wiki.php.net/rfc/consistent_function_names#list_of_functions_to_be_renamed While the idea of this is well meant, this is another major problem for developers working with substantial legacy code

Re: [PHP-DEV] Consistent function names

On Mon, Mar 2, 2015 at 1:58 PM, Yasuo Ohgaki wrote: > Hi Pierre, > > On Tue, Mar 3, 2015 at 6:40 AM, Pierre Joye wrote: >> >> On Sun, Mar 1, 2015 at 3:29 AM, Yasuo Ohgaki wrote: >> > Hi all, >> > >> > First of all, I have no intention removing old function names. >> > >> > PHP function names are

Re: [PHP-DEV] Consistent function names

Hi Pierre, On Tue, Mar 3, 2015 at 6:40 AM, Pierre Joye wrote: > On Sun, Mar 1, 2015 at 3:29 AM, Yasuo Ohgaki wrote: > > Hi all, > > > > First of all, I have no intention removing old function names. > > > > PHP function names are subject of critics for a long time. > > http://www.phpsadness.com

[PHP-DEV] PHP hackers

Hey guys. De-lurking here briefly to ask for a favor. I need to hire one or two people to hack on a pretty complex PHP extension plus supporting C/C++ code and I’m at the end of my wits with going via the usual avenues. If you have any suggestions on where to look next or know of anyone, could you

[PHP-DEV] [RFC] [DISCUSSION] Consistent Function Names

Hi all, First of all, I have no intention to remove nor deprecate old function names. Old function names must exist for compatibility and should be able to use forever. We have CODING_STANDARDS[1] for a long time. However, PHP has so many functions that do not confirm this. Many of violating func

Re: [PHP-DEV] Consistent function names

Hi Markus, On Mon, Mar 2, 2015 at 4:47 PM, Markus Fischer wrote: > On 01.03.15 21:19, Yasuo Ohgaki wrote: > >>> The answer is no, it's just not worth it. Having a function called > >> str_pos which is an alias of strpos, but only on some versions, is more > >> confusing, not less. > >> > >> My s

Re: [PHP-DEV] Consistent function names

hi, On Sun, Mar 1, 2015 at 3:29 AM, Yasuo Ohgaki wrote: > Hi all, > > First of all, I have no intention removing old function names. > > PHP function names are subject of critics for a long time. > http://www.phpsadness.com/sad/4 > http://www.phpsadness.com/sad/15 > http://www.phpsadness.com/sad/

Re: [PHP-DEV] [RFC Discuss] Generator Delegation

Rowan Collins wrote on 02/03/2015 14:44: > Could you explain a bit more about how the generator return > functionality is necessary for this? It seems to me like it's still just > a "nice to have", and that the main functionality - delegating from one > generator to another - is completely separat

AW: [PHP-DEV] [Discussion] Last chance for case-sensitive engine

> -Ursprüngliche Nachricht- > Von: julienpa...@gmail.com [mailto:julienpa...@gmail.com] Im Auftrag von > Julien Pauli > Gesendet: Donnerstag, 26. Februar 2015 10:27 > An: Dmitry Stogov > Cc: Alexander Lisachenko; PHP internals list > Betreff: Re: [PHP-DEV] [Discussion] Last chance for cas

Re: [PHP-DEV] Re: About optimization for compiler

Julien, > Bob's code optimizes things by adding a new OPCode. > This is different from compiler optimizations. > > Compiler optimizations are about changing native, supported OPCode > structures to other native supported OPCode structure, but that will run > faster at runtime. > > I agree with dm

Re: [PHP-DEV] About optimization for compiler

On Feb 27, 2015 5:23 PM, "Xinchen Hui" wrote: > > Hey Internals: > > I was looking Bob's switch optimization.. > > then I start to worry about where is the place optimization should goes.. > > in generally, PHP is a interpreted language. IMO, it should > compiler the PHP codes t

Re: [PHP-DEV] Question/comment about the Array to String conversion RFC

On Mar 3, 2015 4:31 AM, "Julien Pauli" wrote: > Same to me, I voted no because we're gonna break something which is not > "that bad" and turn it to a clear breakage in one step. > I would prefer we E_DEPRACTE before E_ERRORing , we can deprecate in 7.0 > and remove in 7.1 or 7.2 or whatever. > We

Re: [PHP-DEV] [RFC Discuss] Generator Delegation

Daniel Lowrey wrote on 01/03/2015 23:52: Hi folks, I'd like to initiate discussion on a proposal to implement generator delegation via the following new syntax inside generator functions: yield * The Generator Delegation RFC is available here: https://wiki.php.net/rfc/generator-delegati

Re: [PHP-DEV] [RFC Discuss] Generator Delegation

Gr, top-posting... On 3/2/15 1:05 PM, Niklas Keller wrote: I prefer yield from, because it yields that value from the generator. Yield use doesn't make any sense to me if I read those words. Additionally, it's already used by another language. Regards, Niklas ^^ Agreed on all points. --Larr

Re: [PHP-DEV] Re: About optimization for compiler

On Fri, Feb 27, 2015 at 4:30 PM, Dmitry Stogov wrote: > On Fri, Feb 27, 2015 at 6:22 PM, Bob Weinand wrote: > > > > > > Am 27.02.2015 um 16:12 schrieb Xinchen Hui : > > > > > > On Fri, Feb 27, 2015 at 11:08 PM, Bob Weinand > > wrote: > > >> Am 27.02.2015 um 07:53 schrieb Xinchen Hui : > > >> >

Re: [PHP-DEV] [RFC Discuss] Generator Delegation

I prefer yield from, because it yields that value from the generator. Yield use doesn't make any sense to me if I read those words. Additionally, it's already used by another language. Regards, Niklas Daniel Lowrey schrieb am Mo., 02.03.2015, 17:13: > From initial discussions it seems prudent

Re: [PHP-DEV] Reclassify E_STRICT notices

Hi! > About the accessing static property non statically, I would have thrown an > E_ERROR : the property simply doesn't exist. Class properties should be > accessed using the class, not an instance of it , IMO. Sometimes, there's no fixed class but there's an object of this class. Doing somethin

Re: [PHP-DEV] Reclassify E_STRICT notices

On Wed, Feb 25, 2015 at 10:32 AM, Derick Rethans wrote: > On Sun, 22 Feb 2015, Nikita Popov wrote: > > > I would like to propose reclassifying our few existing E_STRICT > > notices and removing this error category: > > > > https://wiki.php.net/rfc/reclassify_e_strict > > > > As we don't reall

Re: [PHP-DEV] VCS Account Request: ivangabriele

On Tue, Oct 21, 2014 at 12:03 AM, Ivan Gabriele wrote: > Hi, > > I would like to get a Git account to translate missing parts in French. I > am French, perfectly fluent in English and I have been developing in PHP > for more than 10 years. > > > -- > PHP Internals - PHP Runtime Development Mailin

Re: [PHP-DEV] Question/comment about the Array to String conversion RFC

On Mon, Mar 2, 2015 at 4:10 PM, Patrick ALLAERT wrote: > Le lun. 2 mars 2015 à 15:24, Zeev Suraski a écrit : > > > All, > > > > > > > > https://wiki.php.net/rfc/array-to-string (which I voted yes to) deviates > > from our guidelines of deprecating features first, and removing them > > later; It

[PHP-DEV] Re: VCS Account Request: ocramius

VCS Account Approved: ocramius approved by tyrael \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC Discuss] Generator Delegation

>From initial discussions it seems prudent to modify the Generator Delegation RFC to use either of: - yield from - yield use The `yield from` form would add a single T_YIELD_FROM token (as opposed to a new "from" reserved word). The `yield use` form would reuse existing keywords. I'd like t

Re: [PHP-DEV] Re: Feature request and RFC

Rowan Collins wrote on 02/03/2015 10:52: Thomas Gielfeldt wrote on 02/03/2015 07:43: 2015-02-24 17:17 GMT+01:00 Thomas Gielfeldt : Hi internals. I've made PR proposing a feature request: A new interface Sortable. https://github.com/php/php-src/pull/1116 If possible, I would like to create a

Re: [PHP-DEV] Question/comment about the Array to String conversion RFC

Le lun. 2 mars 2015 à 15:24, Zeev Suraski a écrit : > All, > > > > https://wiki.php.net/rfc/array-to-string (which I voted yes to) deviates > from our guidelines of deprecating features first, and removing them > later; It’s addressed in the RFC – but I’m a bit worried that this opens > the door

Re: [PHP-DEV] [RFC Discuss] Generator Delegation

On Mon, Mar 2, 2015 at 1:34 AM, Patrick Schaaf wrote: > > Am 02.03.2015 00:52 schrieb "Daniel Lowrey" : > > > > I'd like to initiate discussion on a proposal to implement generator > > delegation via the following new syntax inside generator functions: > > > > yield * > > > > The Generator De

[PHP-DEV] Question/comment about the Array to String conversion RFC

All, https://wiki.php.net/rfc/array-to-string (which I voted yes to) deviates from our guidelines of deprecating features first, and removing them later; It’s addressed in the RFC – but I’m a bit worried that this opens the door to jumping from any sort of notice/warning into errors or removed

[PHP-DEV] VCS Account Request: ocramius

Providing additional functional tests for the PHP runtime -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Improve array to string conversion

Le lun. 2 mars 2015 à 13:39, Patrick ALLAERT a écrit : > Le mer. 25 févr. 2015 à 12:16, Xinchen Hui a écrit : > > Hey: >> >> On Tue, Feb 24, 2015 at 12:06 AM, François Laupretre >> wrote: >> > Hi, >> > >> > Starting the vote for https://wiki.php.net/rfc/array-to-string. >> > >> > Please note th

Re: [PHP-DEV] [RFC][VOTE] Improve array to string conversion

Le mer. 25 févr. 2015 à 12:16, Xinchen Hui a écrit : Hey: > > On Tue, Feb 24, 2015 at 12:06 AM, François Laupretre > wrote: > > Hi, > > > > Starting the vote for https://wiki.php.net/rfc/array-to-string. > > > > Please note that, while the initial RFC proposed both options of either > > fully su

Re: [PHP-DEV] Re: Feature request and RFC

Thomas Gielfeldt wrote on 02/03/2015 07:43: 2015-02-24 17:17 GMT+01:00 Thomas Gielfeldt : Hi internals. I've made PR proposing a feature request: A new interface Sortable. https://github.com/php/php-src/pull/1116 If possible, I would like to create and RFC describing this in more detail, and

Re: [PHP-DEV] [RFC Discuss] Generator Delegation

> Am 02.03.2015 um 11:28 schrieb Niklas Keller : > 2015-03-02 11:11 GMT+01:00 Bob Weinand >: > > Am 02.03.2015 um 01:17 schrieb Niklas Keller > >: > > > > 2015-03-02 0:52 GMT+01:00 Daniel Lowrey > >: > > > >> Hi folks,

Re: [PHP-DEV] [RFC Discuss] Generator Delegation

2015-03-02 11:11 GMT+01:00 Bob Weinand : > > Am 02.03.2015 um 01:17 schrieb Niklas Keller : > > > > 2015-03-02 0:52 GMT+01:00 Daniel Lowrey : > > > >> Hi folks, > >> > >> I'd like to initiate discussion on a proposal to implement generator > >> delegation via the following new syntax inside genera

RE: [PHP-DEV] Coercive STH - some real world tests and updated RFC

> -Original Message- > From: Lester Caine [mailto:les...@lsces.co.uk] > Sent: Monday, March 02, 2015 12:10 PM > To: Zeev Suraski > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] Coercive STH - some real world tests and updated > RFC > > On 02/03/15 09:47, Zeev Suraski wrote: > > I'm o

Re: [PHP-DEV] [RFC Discuss] Generator Delegation

> Am 02.03.2015 um 01:17 schrieb Niklas Keller : > > 2015-03-02 0:52 GMT+01:00 Daniel Lowrey : > >> Hi folks, >> >> I'd like to initiate discussion on a proposal to implement generator >> delegation via the following new syntax inside generator functions: >> >>yield * >> >> The Generator

Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC

On 02/03/15 09:47, Zeev Suraski wrote: > I'm obviously biased but I believe that the coercive rules actually cover a > lot more ground than the weak+strict sets. In other words, with > weak+strict, overall, you're going to have to add custom code in a lot more > cases than with the coercive rule s

RE: [PHP-DEV] Coercive STH - some real world tests and updated RFC

> -Original Message- > From: Lester Caine [mailto:les...@lsces.co.uk] > Sent: Monday, March 02, 2015 11:31 AM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] Coercive STH - some real world tests and updated > RFC > > Andrea's post highlights the fact that we did try a fix when PHP5 c

Re: [PHP-DEV] [RFC Discuss] Generator Delegation

On 2 March 2015 at 00:17, Niklas Keller wrote: > > The proposed syntax has an issue: > > > function a () { > echo yield * 3; > } > > $a = a(); > $a->send(42); > > http://3v4l.org/n1sGb#v550 > > This is currently valid PHP. > > I've created a test for this, so we don't forget it in future ht

Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC

On 02/03/15 08:39, Zeev Suraski wrote: >> One scenario I have in mind for this is validating $_GET information for a >> > RESTful web service. Having potentially an infinite number of URIs that all >> > point to the same resource isn't good: >> > >> > /users/1 >> > /users/%201 >> > /users/1%20 >> >

Re: [PHP-DEV] [RFC][DISCUSSION] Constructor behaviour of internal classes

On 02/03/15 07:57, Michael Wallner wrote: > I'm not sure I can understand your crusade against this topic. > > Consistency with userland is beneficial, because the majority of PHP > developers probably do not expect `new` to yield anything than a > concrete instance or an exception. > > Quoting p

Re: [PHP-DEV] [RFC] UString

On Mon, Mar 2, 2015 at 12:48 AM, Nikita Popov wrote: > On Tue, Oct 21, 2014 at 9:06 AM, Joe Watkins wrote: > >> Morning internalz, >> >> https://wiki.php.net/rfc/ustring >> >> This is the result of work done by a few of us, we won't be >> opening any >> vote in a fortnight. We hav

Re: [PHP-DEV] [RFC] UString

On Tue, Oct 21, 2014 at 9:06 AM, Joe Watkins wrote: > Morning internalz, > > https://wiki.php.net/rfc/ustring > > This is the result of work done by a few of us, we won't be > opening any > vote in a fortnight. We have a long time before 7, there is no rush > whatever. > >

RE: [PHP-DEV] Coercive STH - some real world tests and updated RFC

> -Original Message- > From: Thomas Punt [mailto:tp...@hotmail.co.uk] > Sent: Sunday, March 01, 2015 4:03 PM > To: Zeev Suraski; PHP internals > Subject: RE: [PHP-DEV] Coercive STH - some real world tests and updated > RFC > > Hey Zeev, > > > Another change being considered and not yet in t

Re: [PHP-DEV] [RFC][DISCUSSION] Constructor behaviour of internal classes

On 02/03/15 04:10, Stanislav Malyshev wrote: >> Because the programmer should only be passing in valid paramters any >> > failure is by it's nature an unexpected error. > That's exactly like saying programmer should only try to open existing > files so any failure by its nature is an unexpected err