Re: [PHP-DEV][RFC][DISCUSSION] Group Use Declarations

Hi, Robert > I agree with Markus, the benefits for users which are using IDEs is marginal. But I suppose all other users could actually benefit from it. > Yet, with the drawback described by Markus - searching for use statements without a clever IDE will be more difficult. No syntax will be perfe

Re: [PHP-DEV][RFC][DISCUSSION] Group Use Declarations

Hi, Markus > [...] with proper tooling I almost > can't remember when I wrote the statements by hand; they usually a) get > automatically managed b) thus alphabetically sorted and c) folded away > in general. You're basically stating we don't need to improve language syntax because your IDE alrea

Re: [PHP-DEV][RFC][DISCUSSION] Group Use Declarations

Hi, Leigh > Feels a lot like Rust > > http://doc.rust-lang.org/reference.html#use-declarations Yes, indeed Rust language is cited on the references section. > I'm not opposed to the suggestion, we really should have a shorthand > for condensing use declarations That's good to know, During the r

Re: [PHP-DEV] [RFC] Fix "foreach" behavior

I also thought about similar approach for "object by value case". I think, first we should accept the proposed in thic RFC behavior. It's consistent, and more comatible with PHP5. Later, if we decide to merge zend_array with HashTable we may try to change it. Thanks. Dmitry. On Jan 31, 2015 4:18 P

Re: [PHP-DEV] [RFC] Immutable variables and objects

On 01/31/2015 06:55 PM, Stanislav Malyshev wrote: It is great that this is fast, but I wonder (maybe off-topic?) why do it? I.e. it is clear that in something like: $a = new Request->withHeaders(...)->withBody(...) ->withEncoding(...)->withETag(...) the intermediate objects are useless and nob

Re: [PHP-DEV] [RFC] Fix "foreach" behavior

Thanks for benchmarks. This time I didn't see so good results myself :) I actually, started this work with performance in mind, but after understanding all existing incosistencies, think that consistency is more important. Thanks. Dmitry. On Jan 31, 2015 11:18 AM, "Rasmus Lerdorf" wrote: > On 01

Re: [PHP-DEV] [RFC] Immutable variables and objects

Hi, > On 1 Feb 2015, at 02:09, Stanislav Malyshev wrote: > >> Here, there’s no redundant objects made, but if you pass $a on, it’d >> be automatically copied by PHP, so you don’t need to worry about it >> being modified. > > I don't think it's a particularly good solution in this case, as in ma

Re: [PHP-DEV] [RFC] Immutable variables and objects

Hi! > Here, there’s no redundant objects made, but if you pass $a on, it’d > be automatically copied by PHP, so you don’t need to worry about it > being modified. I don't think it's a particularly good solution in this case, as in many cases (especially DI setups, many design patterns, etc.) the

Re: [PHP-DEV] [RFC][DISCUSSION] ReflectionParameter::getClassName()

> On 1 Feb 2015, at 01:23, Dan Ackroyd wrote: > > On 31 January 2015 at 17:31, Philip Sturgeon wrote: >> On Sat, Jan 31, 2015 at 3:12 AM, Matteo Beccati wrote: >>> >>> 2) There's a tiny bit of overlap with "scalar type hints", >> >> 2) There might be some overlap in the scalar type hint stuf

Re: [PHP-DEV] [RFC][DISCUSSION] ReflectionParameter::getClassName()

On 31 January 2015 at 17:31, Philip Sturgeon wrote: > On Sat, Jan 31, 2015 at 3:12 AM, Matteo Beccati wrote: >> >> 2) There's a tiny bit of overlap with "scalar type hints", > > 2) There might be some overlap in the scalar type hint stuff kinda, > but I'd like to think there isn't. getClassName()

Re: [PHP-DEV] [RFC] Immutable variables and objects

Hi Stas, > On 1 Feb 2015, at 00:55, Stanislav Malyshev wrote: > > >> The with*() methods in PSR-7 are documented to return a new instance, >> not modify the existing instance. Yes, there's no way in PHP itself to >> force that syntactically, which is why documentation exists. :-) >> >> Also,

Re: [PHP-DEV] Use "caller" keyword, to access object caller.

Hi! > Everything is relative, when there is an experience in a dynamic > context (this) in JS, while unwieldy structure in PHP code look > something old and not comfortable. In this case I'd suggest you to write your PHP code in wieldy structure so it would be comfortable ;) I'm not sure what exa

Re: [PHP-DEV] [RFC] Immutable variables and objects

Hey Larry, > On 1 Feb 2015, at 00:42, Larry Garfield wrote: > > Immutability, generally, offers two advantages: > > 1) It makes it easier for humans to reason about code. > > 2) It makes it easier for compilers/runtimes to reason about code. > > For the former, good programming practices/stan

Re: [PHP-DEV] [RFC] Immutable variables and objects

Hi! > The with*() methods in PSR-7 are documented to return a new instance, > not modify the existing instance. Yes, there's no way in PHP itself to > force that syntactically, which is why documentation exists. :-) > > Also, in the benchmarks we've run the performance cost of all those new > ob

Re: [PHP-DEV] [RFC] Immutable variables and objects

On 01/30/2015 12:05 PM, Rowan Collins wrote: On 30/01/2015 13:07, Alexander Lisachenko wrote: What is wrong here? Emulated immutability. All methods will create a separate instance of request, so $baseRequest->withUri()->withMethod()->withHeader()->withBody() will create total 5 object instance

Re: [PHP-DEV] Use "caller" keyword, to access object caller.

2015-02-01 2:23 GMT+02:00 Stanislav Malyshev : > Hi! > >> If the caller explicitly send the object as an argument, it worsens >> loose depending API. >> >> And agreed this code looks weird and not well thought-out: >> > >> $holder->object->call($holder); > > This code explicitly says "object->call

Re: [PHP-DEV] Use "caller" keyword, to access object caller.

Hi! > If the caller explicitly send the object as an argument, it worsens > loose depending API. > > And agreed this code looks weird and not well thought-out: > > $holder->object->call($holder); This code explicitly says "object->call() is using $holder". It is clear and unambiguous. If you

Re: [PHP-DEV] Use "caller" keyword, to access object caller.

2015-02-01 1:52 GMT+02:00 Stanislav Malyshev : > Hi! > >> The reason for creating circular references, usually due to the need to >> bind objects. >> >> But this relationship can often be obtained from the context of the call. > > If the API behaves differently depending on who is calling it, or >

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecate INI set/get aliases.

On 31/01/15 18:39, Yasuo Ohgaki wrote: > On Sat, Jan 31, 2015 at 5:48 PM, Lester Caine wrote: > >> > My only comment would be the one that the rfc displays perfectly ... >> > >> > In 'Before' if I click on session_cache_limiter I get taken directly to >> > the manual page for it. >> > >> > How do

Re: [PHP-DEV] Use "caller" keyword, to access object caller.

Hi! > The reason for creating circular references, usually due to the need to > bind objects. > > But this relationship can often be obtained from the context of the call. If the API behaves differently depending on who is calling it, or requires some information from the caller, it should be pa

Re: [PHP-DEV] Use "caller" keyword, to access object caller.

2015-02-01 0:10 GMT+02:00 Rowan Collins : > On 31/01/2015 19:41, S.A.N wrote: >> >> No, I'm not describing this behavior, but I chose the wrong name >> keyword, this is not perceived correctly. >> >> My source code examples, it is clear that no returns previous object >> from the call stack, me nee

Re: [PHP-DEV] Use "caller" keyword, to access object caller.

On 31/01/2015 19:41, S.A.N wrote: No, I'm not describing this behavior, but I chose the wrong name keyword, this is not perceived correctly. My source code examples, it is clear that no returns previous object from the call stack, me need return references to the holder object. It's more like t

[PHP-DEV] Re: Session: More strict session data management

Hi all, On Sun, Feb 1, 2015 at 5:30 AM, Yasuo Ohgaki wrote: > On Sat, Jan 31, 2015 at 11:44 AM, Yasuo Ohgaki wrote: > >> As I described already, current session management is lazy to delete >> obsolete >> session data. New behavior is much stricter than now and there is no >> exposed >> interna

[PHP-DEV] Re: Session: More strict session data management

Hi all, On Sat, Jan 31, 2015 at 11:44 AM, Yasuo Ohgaki wrote: > As I described already, current session management is lazy to delete > obsolete > session data. New behavior is much stricter than now and there is no > exposed > internal data to users(script). The "hidden" timestamp only exists in

Re: [PHP-DEV] Why does session.gc_maxlifetime default to 1440 seconds?

Hi Leigh, On Sat, Jan 31, 2015 at 8:24 PM, Leigh wrote: > On 31 January 2015 at 11:12, Bas van Beek wrote: > > > > Well the number 1440 itself is not so arbitrary as it's the amount of > minutes in a day. Maybe that's why the number popped up. > > > > In the end 24 minutes does seem to be fine

Re: [PHP-DEV] Use "caller" keyword, to access object caller.

No, I'm not describing this behavior, but I chose the wrong name keyword, this is not perceived correctly. My source code examples, it is clear that no returns previous object from the call stack, me need return references to the holder object. It's more like the dynamic of "this" in JavaScript.

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecate INI set/get aliases.

Hi Lester, On Sat, Jan 31, 2015 at 5:48 PM, Lester Caine wrote: > My only comment would be the one that the rfc displays perfectly ... > > In 'Before' if I click on session_cache_limiter I get taken directly to > the manual page for it. > > How do I get to the same page in 'After'? > If I drop '

AW: [PHP-DEV][RFC][DISCUSSION] Group Use Declarations

> -Ursprüngliche Nachricht- > Von: Markus Fischer [mailto:mar...@fischer.name] > Gesendet: Samstag, 31. Januar 2015 16:11 > An: internals@lists.php.net > Betreff: Re: [PHP-DEV][RFC][DISCUSSION] Group Use Declarations > > On 31.01.15 01:09, Marcio Almada wrote: > > After a period of resea

Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Revert "Disable PEAR by default": configure.in

Are we discussing the PEAR installer or everything related to PEAR? I see no reason to include the PEAR installer by default. Heck, on most distros it's already split out into a separate package. If I already have to install a package installer (php-pear) to install extensions using pecl, the

Re: [PHP-DEV] Enable error_handler callback parameters to be passed by reference

error_log() is a good point. In the future, set_error_handler() might be changed to be called multiple times with different custom error handlers, similar to how register_shutdown_function() and spl_autoload_register() act on multiple calls. Having a chain of error handlers appending data to $er

Re: [PHP-DEV] [RFC][DISCUSSION] ReflectionParameter::getClassName()

On Sat, Jan 31, 2015 at 3:12 AM, Matteo Beccati wrote: > Hi Phil, > > > On 31/01/2015 05:14, Philip Sturgeon wrote: >> >> This RFC adds a new method to ReflectionParameter to allow easy access >> to a class name in a type hint, avoiding the need to actually load the >> class and use `get_class()`

Re: [PHP-DEV] OpenSSL ext. improvements for authenticated cipher modes.

On 31 January 2015 at 16:13, Jason Gerfen wrote: > On Sat, Jan 31, 2015 at 8:53 AM, Leigh wrote: >> At the very basic end of the spectrum, we could have openssl_get_tag >> and openssl_set_tag, or add an extra parameter to the end of >> openssl_encrypt and openssl_decrypt (pass by ref for encrypt,

Re: [PHP-DEV] OpenSSL ext. improvements for authenticated cipher modes.

On Sat, Jan 31, 2015 at 8:53 AM, Leigh wrote: > Hi list, > > A couple of bug reports have highlighted the fact that our > openssl_encrypt and openssl_decrupt functions have no way of getting > or setting tags required for authenticated cipher modes (i.e. GCM, > CCM, OCB (not sure if this is avail

[PHP-DEV] OpenSSL ext. improvements for authenticated cipher modes.

Hi list, A couple of bug reports have highlighted the fact that our openssl_encrypt and openssl_decrupt functions have no way of getting or setting tags required for authenticated cipher modes (i.e. GCM, CCM, OCB (not sure if this is available in OpenSSL)). https://bugs.php.net/bug.php?id=68962 h

Re: [PHP-DEV][RFC][DISCUSSION] Group Use Declarations

On 31.01.15 01:09, Marcio Almada wrote: > After a period of research along with part of the PHP community I'd > like to present this RFC which aims to improve PHP namespaces. > > The RFC: https://wiki.php.net/rfc/group_use_declarations > Along with its pull request: https://github.com/php/php-src/

Re: [PHP-DEV] Delete PHPNG branch from repo?

Hey: On Fri, Jan 30, 2015 at 10:14 PM, Ferenc Kovacs wrote: > > > On Fri, Jan 30, 2015 at 3:04 PM, Xinchen Hui wrote: >> >> Hey: >> >>there already are more than 2 people tell me they are trying to >> play with PHP7, but turns out they are playing with PHPNG branch(since >> we used to call

Re: [PHP-DEV] [RFC] [VOTE] pecl_http

On Jan 31, 2015 9:08 PM, "Pavel Kouřil" wrote: > > On Sat, Jan 31, 2015 at 1:41 PM, Pierre Joye wrote: > > > > There is zero reason to discuss what has been approved and followed for > > years already. > > > > I will simply post the link to our CS as a reminder and ask everyone to > > read it if

Re: [PHP-DEV] [RFC] Fix "foreach" behavior

On Fri, Jan 30, 2015 at 8:23 AM, Dmitry Stogov wrote: > Hi, > > I'd like to start discussion about fixing inconsistent "foreach" statement > behavior. > The implementation is almost done. It not only fixes inconsistencies in a > defined by RFC way but also improves performance in most usual cases

Re: [PHP-DEV] [RFC] [VOTE] pecl_http

On Sat, Jan 31, 2015 at 1:41 PM, Pierre Joye wrote: > > There is zero reason to discuss what has been approved and followed for > years already. > > I will simply post the link to our CS as a reminder and ask everyone to > read it if they never did: > > https://github.com/php/php-src/blob/master/C

Re: [PHP-DEV] [RFC] [VOTE] pecl_http

On Jan 31, 2015 5:57 PM, "Tony Marston" wrote: > > "Yasuo Ohgaki" wrote in message news:caga2bxzgljrp6i2vdnkdga8dw7nothc9ie17tst40kpbbha...@mail.gmail.com... >> >> >> Hi Tony, >> >> On Fri, Jan 30, 2015 at 7:08 PM, Tony Marston >> wrote: >> >>> ""Pavel Kouril"" wrote in message >>> news:cab6yzu

Re: [PHP-DEV] [RFC] [VOTE] pecl_http

On Jan 30, 2015 6:09 PM, "Tony Marston" wrote: > > ""Pavel Kouril"" wrote in message > news:cab6yzuzymbaa5i3f9nsvebg2b7yjvo4ryvpy-eac78rsojx...@mail.gmail.com... > >> >> On Wed, Jan 28, 2015 at 1:17 PM, Michael Wallner wrote: >>> >>> Hi, >>> > > > > > >> Hello, >> >> just one observation - would

Re: [PHP-DEV] Why does session.gc_maxlifetime default to 1440 seconds?

On 31 January 2015 at 11:12, Bas van Beek wrote: > > Well the number 1440 itself is not so arbitrary as it's the amount of minutes > in a day. Maybe that's why the number popped up. > > In the end 24 minutes does seem to be fine for the majority of people and > with people that care about sessio

Re: [PHP-DEV] Why does session.gc_maxlifetime default to 1440 seconds?

Well the number 1440 itself is not so arbitrary as it's the amount of minutes in a day. Maybe that's why the number popped up. In the end 24 minutes does seem to be fine for the majority of people and with people that care about session duration it's really easy to update :) > Op 31 jan. 2015

Re: [PHP-DEV] Why does session.gc_maxlifetime default to 1440 seconds?

Hey Yasuo, Yes, there can surely be no other reason for the existence of the value, than that someone wrote it :) I think what I'm interested in is the reasoning behind it, since it seems so arbitrary. It's not 20 or 30 minuts, for example. I have tried emailing the author a long time ago but ne

Re: [PHP-DEV] [RFC] [VOTE] pecl_http

"Larry Garfield" wrote in message news:54cbb0cd.9010...@garfieldtech.com... On 1/30/15 4:08 AM, Tony Marston wrote: ""Pavel Kouril"" wrote in message news:cab6yzuzymbaa5i3f9nsvebg2b7yjvo4ryvpy-eac78rsojx...@mail.gmail.com... On Wed, Jan 28, 2015 at 1:17 PM, Michael Wallner wrote: just one

Re: [PHP-DEV] Magic getter bug tickled by Moodle

Hey: On Sat, Jan 31, 2015 at 3:15 PM, Rasmus Lerdorf wrote: > On 01/30/2015 11:13 PM, Michael Wallner wrote: >> >> On 31 Jan 2015 06:04, "Rasmus Lerdorf" > > wrote: >>> >>> There is something weird going on with PHP7 and the moodle_page class >>> and all its magic metho

Re: [PHP-DEV] [RFC] [VOTE] pecl_http

"Yasuo Ohgaki" wrote in message news:caga2bxzgljrp6i2vdnkdga8dw7nothc9ie17tst40kpbbha...@mail.gmail.com... Hi Tony, On Fri, Jan 30, 2015 at 7:08 PM, Tony Marston wrote: ""Pavel Kouril"" wrote in message news:cab6yzuzymbaa5i3f9nsvebg2b7yjvo4ryvpy-eac78rsojx...@mail.gmail.com... On Wed, J

Re: [PHP-DEV] [RFC] [VOTE] pecl_http

"Stanislav Malyshev" wrote in message news:54cbd947.7050...@gmail.com... Hi! Just because that most of the code YOU have seen uses CamelCase does not mean that CamelCase is the "standard". I programmed in other languages for over 20 years before I switched to PHP, and in those languages the

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecate INI set/get aliases.

On 31/01/15 01:08, Yasuo Ohgaki wrote: > Hi all, > > This is the RFC for INI set/get alias function deprecation. > > https://wiki.php.net/rfc/deprecate_ini_set_get_aliases > > Open issue is exception. Almost all aliases should be deprecated, but there > may > be exceptions. I hope everyone agree

Re: [PHP-DEV] [RFC] Fix "foreach" behavior

On Sat, Jan 31, 2015 at 4:18 PM, Rasmus Lerdorf wrote: > On 01/30/2015 09:10 PM, Dmitry Stogov wrote: >> Hi, >> >> Nikita got an idea about stopping changing of array/object internal >> pointers even in forech by reference. >> I've added an additional RFC section: >> >> https://wiki.php.net/rfc/ph

Re: [PHP-DEV] [RFC] Fix "foreach" behavior

On 01/30/2015 09:10 PM, Dmitry Stogov wrote: > Hi, > > Nikita got an idea about stopping changing of array/object internal > pointers even in forech by reference. > I've added an additional RFC section: > > https://wiki.php.net/rfc/php7_foreach#additional_behavoir_change > > Trivial implementati

Re: [PHP-DEV] [RFC][DISCUSSION] ReflectionParameter::getClassName()

Hi Phil, On 31/01/2015 05:14, Philip Sturgeon wrote: This RFC adds a new method to ReflectionParameter to allow easy access to a class name in a type hint, avoiding the need to actually load the class and use `get_class()` or `::class`. https://wiki.php.net/rfc/reflectionparameter-getclassname