Re: [PHP-DEV] [RFC] [VOTE] pecl_http
On Jan 31, 2015 9:08 PM, Pavel Kouřil pajou...@gmail.com wrote: On Sat, Jan 31, 2015 at 1:41 PM, Pierre Joye pierre@gmail.com 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/CODING_STANDARDS Well, the coding standard doesn't mention namespaces. So shouldn't it be updated to include namespaces? If there's an RFC for including something using namespaces, the should be rules for naming namespaces in the coding standard, IMHO. It sounds pretty obvious but yes it should be mentioned for completeness. Pavel Kouril
[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 https://bugs.php.net/bug.php?id=67304 Further to this, we have no way of setting any associated data. I think we absolutely must provide a method for users to be able to use authenticated encryption, and would like some opinions on how much flexibility we give users, and the best method for exposing this functionality. 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, like preg $matches) this would cover the majority of use cases. However I absolutely think that the associated data also needs to be supported, and possibly the ability to change the tag length. At this point we're starting to get into the territory where an $options array is needed, or we add a lot of parameters to the end of functions. I don't really think it's good to add up to 3 more params to these functions. What do you guys and girls think is the best way of tackling this? Cheers, Leigh. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Delete PHPNG branch from repo?
Hey: On Fri, Jan 30, 2015 at 10:14 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Fri, Jan 30, 2015 at 3:04 PM, Xinchen Hui larue...@php.net 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 it phpng). as it already be merged into master. and there is also no tags against it. maybe we should delete it? any objections? thanks -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php no, please go ahead. we even have tags of PRE_PHPNG_MERGE and POST_PHPNG_MERGE, so there is absolutely no reason to keep it around. thanks, deleted. :) -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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/pull/1005 Needless to say, I'm open to suggestions that could improve the proposal. The RFC says: Group use statements makes it easier to identify that multiple imported entities are from the same module. IMHO that's too subjective. What is hard with the current state of affairs? Btw, here's a CON you can add to the RFC (and, btw., it doesn't contain any): - Prevents searching sources literally for used namespaces Another observation thing from my side: 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. What is the real benefit of using groups it and who's the group benefiting from that change? Maybe you can expand on that in the RFC. sincerely, - Markus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OpenSSL ext. improvements for authenticated cipher modes.
On Sat, Jan 31, 2015 at 8:53 AM, Leigh lei...@gmail.com 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 available in OpenSSL)). https://bugs.php.net/bug.php?id=68962 https://bugs.php.net/bug.php?id=67304 Further to this, we have no way of setting any associated data. I think we absolutely must provide a method for users to be able to use authenticated encryption, and would like some opinions on how much flexibility we give users, and the best method for exposing this functionality. 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, like preg $matches) this would cover the majority of use cases. I think exposing this to the user will only cause confusion and allow users to implement mistakes to the algorithm and mode usage. However I absolutely think that the associated data also needs to be supported, and possibly the ability to change the tag length. At this point we're starting to get into the territory where an $options array is needed, or we add a lot of parameters to the end of functions. I don't really think it's good to add up to 3 more params to these functions. What do you guys and girls think is the best way of tackling this? Cheers, Leigh. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php According to the OpenSSL documentation regarding encryption/decryption using CCM, GCM OCB modes for authenticated usage would require the additions of the following constants: EVP_CTRL_OCB_SET_TAGLEN EVP_CTRL_SET_IVLEN EVP_CTRL_GET_TAG EVP_CTRL_CCM_SET_L EVP_CTRL_CCM_SET_IVLEN EVP_aes_256_gcm() EVP_aes_128_gcm() That coupled with the use of the EVP_CIPHER_CTX_ctrl() should provide the needed functionality as described in http://wiki.openssl.org/index.php/EVP_Authenticated_Encryption_and_Decryption the documentation for using the EVP authenticated modes for encryption/decryption.
Re: [PHP-DEV] OpenSSL ext. improvements for authenticated cipher modes.
On 31 January 2015 at 16:13, Jason Gerfen jason.ger...@gmail.com wrote: On Sat, Jan 31, 2015 at 8:53 AM, Leigh lei...@gmail.com 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, like preg $matches) this would cover the majority of use cases. I think exposing this to the user will only cause confusion and allow users to implement mistakes to the algorithm and mode usage. set/get tag functions are alto my least favourite options. According to the OpenSSL documentation regarding encryption/decryption using CCM, GCM OCB modes for authenticated usage would require the additions of the following constants: EVP_CTRL_OCB_SET_TAGLEN EVP_CTRL_SET_IVLEN EVP_CTRL_GET_TAG EVP_CTRL_CCM_SET_L EVP_CTRL_CCM_SET_IVLEN EVP_aes_256_gcm() EVP_aes_128_gcm() That coupled with the use of the EVP_CIPHER_CTX_ctrl() should provide the needed functionality as described in http://wiki.openssl.org/index.php/EVP_Authenticated_Encryption_and_Decryption the documentation for using the EVP authenticated modes for encryption/decryption. Thanks, I have done some cursory research into how it should be implemented, but I wanted this discussion to be about how we should present the functionality to the user. Implementation details can come second once we have a consensus on what is/isn't too much, and what method we should use to allow this functionality to be used. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Fix foreach behavior
On Fri, Jan 30, 2015 at 8:23 AM, Dmitry Stogov dmi...@zend.com 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, because now foreach by value over array doesn't require array duplication. https://wiki.php.net/rfc/php7_foreach https://github.com/php/php-src/pull/1034 I'm going to continue work on implementation improvement and may be fixing related behavior of some internal functions when they used on array iterated by foreach by reference (e.g. array_unshift()). However, the conceptual behavior defined in RFC is not going to be changed anymore. Thanks. Dmitry. I think the new behavior introduced by this RFC is much more consistent than what we have right now. Previously things depended on details of refcounting and hashing and had very weird interaction with current() etc. Now the behavior looks clear for all cases. There's just one thing I'd like to discuss: The object by-value case: Currently this is handled in much the same way as array by-reference, i.e. changes to the object will influence iteration. Currently we can't implement this any differently, however if we always use zend_array instead of HashTable (and fully support refcounting for this), as has been suggested in another thread, we could handle this case the same way as arrays (i.e. just add a refcount to the properties zend_array). Assuming we can implement it this way, I'm not totally sure which behavior makes more sense. On one hand it would make arrays and plain objects work the same way. On the other hand arrays and objects have different copying semantics in other places as well. Anyway, big +1 on this, thanks for implementing it. Nikita
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 implementation on top of the main patch: https://gist.github.com/dstogov/63b269207ba0aed8b776 and an additional proposed voting question. Also, the implementation now must be almost complete. I built your branch and applied Nikita's patch as well and ran it through my benchmark box here. Before - After numbers in requests/sec: Drupal8-b4182 - 184 Wordpress-4.1 661 - 675 phpbb-3.1.2 1071 - 1084 Mediawiki-1.24.1 304 - 306 Opencart-2.0.1.1 458 - 459 WardrobeCMS-1.2.0 993 - 999 Geeklog-2.1.0 823 - 825 Traq-3.5.2 1869 - 1902 So about a 1% boost across the board except for Opencart, but it spends most of its time creating sessions on disk and writing to MySQL. No obvious visible things broke in any of these. Overall, even without the performance boost, I think making the edge-case foreach behaviour consistent and predictable is a good thing on its own. -Rasmus signature.asc Description: OpenPGP digital signature
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 agrees to deprecation by document at least. Thank you for your time to address this RFC. 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 'session.cache_limiter' into the search I have the usual hassle of trying to get to the right pigging section of the website before it works, but I still have to search around for the session_cache_limiter entry as one gets 'session.cache_limiter doesn't exist. Closest matches: ' Many deprecated features exhibit this problem, but this one seems a lot more critical to resolve if you want to simplify things. ini_set values like max_execution_time don't even come up in a search! -- 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][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 Looks good to me! Just a couple of minor things. 1) The RFC does not mention what happens if the parameter is not type hinted, or what happens when hints are namespaced and/or use clauses are used. 2) There's a tiny bit of overlap with scalar type hints, if it is accepted (in any form) and reflection support added to it. Depending on the way such reflection support is implemented, the method proposed here could be a perfect match. Or perhaps it could be in the way. Cheers -- Matteo Beccati Development Consulting - http://www.beccati.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Fix foreach behavior
On Sat, Jan 31, 2015 at 4:18 PM, Rasmus Lerdorf ras...@lerdorf.com 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/php7_foreach#additional_behavoir_change Trivial implementation on top of the main patch: https://gist.github.com/dstogov/63b269207ba0aed8b776 and an additional proposed voting question. Also, the implementation now must be almost complete. I built your branch and applied Nikita's patch as well and ran it through my benchmark box here. Before - After numbers in requests/sec: Drupal8-b4182 - 184 Wordpress-4.1 661 - 675 phpbb-3.1.2 1071 - 1084 Mediawiki-1.24.1 304 - 306 Opencart-2.0.1.1 458 - 459 WardrobeCMS-1.2.0 993 - 999 Geeklog-2.1.0 823 - 825 Traq-3.5.2 1869 - 1902 So about a 1% boost across the board except for Opencart, but it spends most of its time creating sessions on disk and writing to MySQL. Nice~ thanks No obvious visible things broke in any of these. Overall, even without the performance boost, I think making the edge-case foreach behaviour consistent and predictable is a good thing on its own. -Rasmus -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] ReflectionParameter::getClassName()
On Sat, Jan 31, 2015 at 3:12 AM, Matteo Beccati p...@beccati.com 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()` or `::class`. https://wiki.php.net/rfc/reflectionparameter-getclassname Looks good to me! Just a couple of minor things. 1) The RFC does not mention what happens if the parameter is not type hinted, or what happens when hints are namespaced and/or use clauses are used. 2) There's a tiny bit of overlap with scalar type hints, if it is accepted (in any form) and reflection support added to it. Depending on the way such reflection support is implemented, the method proposed here could be a perfect match. Or perhaps it could be in the way. Cheers -- Matteo Beccati Development Consulting - http://www.beccati.com/ Thanks! Good questions. 1) Thanks for your help on GitHub in making tests for this. Implemented nicely. 2) There might be some overlap in the scalar type hint stuff kinda, but I'd like to think there isn't. getClassName() is just getClass()-name without loading the actual class. Getting string' or int back is likely to have its own logic in the scalar type hint RFC so I'd rather stay clear of it altogether. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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, then I see no reason why we can't say install this other installer instead. If PEAR works with php7, then great, you can use that as your installer. If not, use pickle, your distro's package manager, or download a precompiled binary. Exactly. Catch: Many distributions use packaging automation which installs libraries *as pear packages* - as long as there is no way to mimic pear's system-wide installation with composer or as long as the have not retooled to make it look alike. We're working on it. Pear will not vanish from repos anytime soon - but it should not be part of php proper. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 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/pull/1005 Needless to say, I'm open to suggestions that could improve the proposal. The RFC says: Group use statements makes it easier to identify that multiple imported entities are from the same module. IMHO that's too subjective. What is hard with the current state of affairs? Btw, here's a CON you can add to the RFC (and, btw., it doesn't contain any): - Prevents searching sources literally for used namespaces Another observation thing from my side: 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. What is the real benefit of using groups it and who's the group benefiting from that change? Maybe you can expand on that in the RFC. sincerely, - Markus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php [Robert Stoll] 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. Anyway, thinking in terms of scripting it seems to be a nice feature. Therefore +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Deprecate INI set/get aliases.
Hi Lester, On Sat, Jan 31, 2015 at 5:48 PM, Lester Caine les...@lsces.co.uk 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 'session.cache_limiter' into the search I have the usual hassle of trying to get to the right pigging section of the website before it works, but I still have to search around for the session_cache_limiter entry as one gets 'session.cache_limiter doesn't exist. Closest matches: ' Many deprecated features exhibit this problem, but this one seems a lot more critical to resolve if you want to simplify things. ini_set values like max_execution_time don't even come up in a search! Good point. But whole site search shows these INI on top. Document search could be improved. I agree. The same applies to all INI values. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
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 $errstr makes it difficult
to use error_log(), because this is a one-time operation.
Also, error_log() has the ability to override the error_log property from
php.ini, which might not be the desired behaviour.
So I would prefer $errstr to be passed by reference.
For completeness, error_log() currently has no parameters for $errno, $line and
$file, so an example would look like this:
function myErrorHandler($errno, $errstr, $errfile, $errline) {
switch($errno){
case E_WARNING: $errnoStr='Warning'; break;
case E_NOTICE:$errnoStr='Notice'; break;
case E_STRICT:$errnoStr='Strict'; break;
case E_RECOVERABLE_ERROR: $errnoStr='Recoverable Error'; break;
case E_DEPRECATED:$errnoStr='Deprecated'; break;
case E_USER_ERROR:$errnoStr='User Error'; break;
case E_USER_WARNING: $errnoStr='User Warning'; break;
case E_USER_NOTICE: $errnoStr='User Notice'; break;
case E_USER_DEPRECATED: $errnoStr='User Deprecated'; break;
}
if (!empty($_SESSION['username'])) {
$errstr .= ', username: '.$_SESSION['username'];
}
error_log('PHP '.$errnoStr.': '.$errstr.' in '.$errfile.' on line
'.$errline);
return true;
}
Regards
Thomas
Dan Ackroyd wrote on 30.01.2015 10:38:
On 21 January 2015 at 04:39, Thomas Bley ma...@thomasbley.de wrote:
In userland it is sometimes necessary to extend PHP's notices/warnings with
additional information (e.g. username from session, stack trace, etc.)
Why can't you just use in the error handler function to write the
exact message you want?
http://php.net/manual/en/function.error-log.php
cheers
Dan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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.
Dynamic this, sometimes very convenient for the event model, so I
proposed to implement this feature in PHP.
In PHP, there traits, extends, but it's all static bind, in runtime
can not be added or redefined.
I'll show a simple JS example, in which needed behavior dynamic this.
script language=JavaScript
function A(){}
function B(){}
function getHolder()
{
console.log(this.constructor.name)
}
var oA = new A
var oB = new B
oA.getHolder = getHolder
oB.getHolder = getHolder
oA.getHolder() // return A
oB.getHolder() // return B
getHolder() // return Window
/script
Perhaps we should use the keyword this instead of caller? :)
Then the code in PHP will look like this:
?php
class A
{
public $object;
}
class B
{
public $object;
}
class C
{
public function getHolder() {
return this::class;
}
}
$a = new A;
$b = new B;
$c = new C;
$a-object = $c;
$b-object = $c;
$a-object-getHolder(); // return A
$b-object-getHolder(); // return B
$c-getHolder(); // Fatal Error - undefined context
?
What do you think?
Thank.
2015-01-30 18:43 GMT+02:00 Ferenc Kovacs tyr...@gmail.com:
On Fri, Jan 30, 2015 at 3:53 AM, S.A.N ua.san.a...@gmail.com wrote:
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.
It will be very convenient to have a keyword that will return reference to
an object, which caused this object.
Sorry for my English, I'm not a native speaker.
A simple example below shows the behavior that we need.
?php
class A
{
public function __construct() {
$this-object = new C;
}
}
class B
{
public function __construct() {
$this-object = new C;
}
}
class C
{
public function getCaller() {
return caller::class;
}
}
$a = new A;
$b = new B;
$c = new C;
$a-object-getCaller(); // return A
$b-object-getCaller(); // return B
$c-getCaller(); // Fatal Error - undefined caller context
?
Create a new keyword can cause problems with backward compatibility...
Perhaps you can solve a problem to using an existing keyword?
Thank you for any feedback.
see the previous discussion on this topic:
http://grokbase.com/t/php/php-internals/099g86x7k6/reference-caller-object
I think having it as a magic constant would be better, but I still don't
like the idea (it is already possible, there aren't really a good usecase
for it, the example you mentioned is a prime example how would it be misused
to cause debugging nightmares, etc.).
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Session: More strict session data management
Hi all, On Sat, Jan 31, 2015 at 11:44 AM, Yasuo Ohgaki yohg...@ohgaki.net 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 obsolete session data. New behavior requires less GC also. Current session manager is lazy for expiration also. The same method, hidden timestamp, can be used for housekeeping. If the timestamp is updated always, lazy_write option is spoiled. To prevent that, last modified time updates could be done with longer resolution, i.e. Update timestamp by every minute, not second. With this, GC is only need for true GC. i.e. GC will not be used to expire session data. Therefore, GC may be done once a day, for example. Any comment? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Why does session.gc_maxlifetime default to 1440 seconds?
Hi Leigh,
On Sat, Jan 31, 2015 at 8:24 PM, Leigh lei...@gmail.com wrote:
On 31 January 2015 at 11:12, Bas van Beek b...@tobin.nl 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 session duration it's really easy to update
:)
I like the idea of this being a 15+ year old bug where minutes were
used instead of seconds :)
session.cache_expire? It's minutes. Do you mean session.cache_expire should
be seconds?
session.gc_maxlifetime is second.
files/mm take it as seconds.
mod_files.c - master
295 /* check whether its last access was more than
maxlifet ago */
296 if (VCWD_STAT(buf, sbuf) == 0
297 (now - sbuf.st_mtime) maxlifetime) {
298 VCWD_UNLINK(buf);
299 nrdels++;
mod_mm.c - master
458 limit -= maxlifetime;
459
460 mm_lock(data-mm, MM_LOCK_RW);
461
462 ehash = data-hash + data-hash_max + 1;
463 for (ohash = data-hash; ohash ehash; ohash++) {
464 for (sd = *ohash; sd; sd = next) {
465 next = sd-next;
466 if (sd-ctime limit) {
467 ps_mm_debug((purging %s\n, sd-key));
468 ps_sd_destroy(data, sd);
469 (*nrdels)++;
470 }
471 }
472 }
Current session module does not keeping last update time and relayed on
probability based GC solely. gc_maxlifetime value does not have precise
meaning.
I proposed precise session data deletion in other thread. The same can be
done for precise session data expiration.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
[PHP-DEV] Re: Session: More strict session data management
Hi all, On Sun, Feb 1, 2015 at 5:30 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: On Sat, Jan 31, 2015 at 11:44 AM, Yasuo Ohgaki yohg...@ohgaki.net 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 obsolete session data. New behavior requires less GC also. Current session manager is lazy for expiration also. The same method, hidden timestamp, can be used for housekeeping. If the timestamp is updated always, lazy_write option is spoiled. To prevent that, last modified time updates could be done with longer resolution, i.e. Update timestamp by every minute, not second. With this, GC is only need for true GC. i.e. GC will not be used to expire session data. Therefore, GC may be done once a day, for example. Any comment? If there aren't comments, I shall start writing a RFC for this in a few days. Please comment, if you have. Thank you. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
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 nobody needs 5 new objects when you do it. Am I missing something here? Primarily for the reasons Andrea listed: Avoid spooky-action-at-a-distance. In the particular case of a request (or ServerRequest), it's very tempting to use as an over-engineered global with all of the problems that causes. When doing sub requests, or recursive requests, any code that relies on a global request object is now invalid and introduces all sorts of weirdness. By not allowing that object to change without the system knowing about it explicitly you eliminate a lot of sources of weird bugs. (There were several very long threads on the FIG list about mutability and I'm greatly over-simplifying them here. There are also still dissenters who would favor a mutable object, still, although right now the group is leaning immutable.) On 01/31/2015 08:56 PM, Andrea Faulds wrote: Hi, I'd rather just have a clear separation between mutating and non-mutating APIs, and instruct people to use the right ones in right situation - i.e. if you created the object or own it, use mutating ones, if you got object from outside and do not have full ownership of it, use non-mutating ones. This isn’t very nice in practice, though. Mutating APIs are easy to use and performant, non-mutating APIs are neither of these things. What you want is the benefits of the first without the disadvantages of the second. I disagree here. In the micro-sense, mutating APIs may be easier and more performant at first. At scale, though, immutable APIs tend to be much more predictable and less prone to mysterious behavior. Drupal 7's render API is an excellent demonstration of how mutable data structures can result in completely incomprehensible, almost non-deterministic code. :-) Would that make sense? It’s no different than how our existing value types like scalars and arrays work. Scalars don't have this problem as, except for string offsets (IMHO not the best idea to have mutable strings too) scalars can not really be changed, just replaced with other scalars. But implementing value objects in PHP is not hard right now - if you don't provide any methods that allow changing state, you've got an immutable object. It's just not always what people using it would want, especially with something as complex as HTTP message. You’re ignoring arrays, which *also* have our copy-on-write behaviour. Also, the bigint RFC (if passed) would be another kind of mutable scalar. It’s not mutable in very many cases, but it is in some places as a performance optimisation. We have value objects, sure, but they’re not efficient. Every mutation requires the creation of a new object, because you can’t do copy-on-write. Compare that to arrays: mutations there only create new arrays if the refcount is 1. The following code using immutable value objects requires the creation of five new objects: $a = $somefoo -withBar(…) -withBaz(…) -withQux(…) -withoutFooBar(); Yet the following code using arrays, which are passed by value in PHP, requires the creation of only one new array, and modifies in-place: $a = $somefoo; $a[‘bar’] = …; $a[‘baz’] = …; $a[‘qux’] = …; unset($a[‘foobar’]); Is that not superior? Depends what it is you're prioritizing. Arrays-as-junior-structs only scale so far, and in my experience they break down surprisingly fast. (See above regarding Drupal's Array-Oriented APIs.) They also don't have any natural mechanism to do anything but CRUD, so methods that derive information from provided data, or provide defaults for various values, or do anything to provide a nice developer experience (DX) are impossible. They're also completely non-self-documenting, whereas a class with defined properties and methods, mutable or not, is much easier to learn how to use. Having some objects that are pass-by-value and others that are pass-by-handle/reference... honestly scares me. The potential for confusion there is huge. Last I recall there was discussion of trying to revamp arrays to be more like objects to finally resolve the array_*() functions and iterators are incompatible and the world sucks problem, so that would seem to go the other direction. (Did anyone end up working on that for PHP 7? Please?) If you really wanted a compound variable (like objects and arrays) that was just for data and passed by value but had a nicer DX than undocumentable array keys... now you're talking about actual structs, and letting them have actor functions a la Go. But I should probably stop talking now before someone shoots me. :-) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To
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 instances. It's a memory overhead and time consumption
for
each method call.
Like Andrea, I don't see how immutable variables/objects solve this
problem. The overhead is not from emulating the immutability, it is a
consequence of the design pattern choosing immutability. In fact, from
the code shown, there is no way to know that immutability is in any
way relevant, since the definition of withUri() could be a mutator
which ends return $this, a pattern I've frequently used to create
such fluent interfaces. Copy-on-write doesn't help, either, since
all 5 calls are writes, so will still make 5 copies.
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
objects is measured in nanoseconds, ie, small enough that we're not
worried about it. (Hats off to the PHP Internals folks for making that
fast!)
What I want to discuss is true immutability flag for variables and
parameters. There are a lot of languages that use final or const
keywords to prevent modification of variables.
On the concrete suggestion, though, I do think there are possible
advantages to this. I've long felt the confusion people have over
pass-by-value for primitives,
pass-by-value-which-is-actually-a-pointer for objects, and
pass-by-reference for a variable which might or might not be an object
pointer, is a failure not of the programmer but of the programming
language. In a blog post about it a few years ago [1], I suggested
that deep immutability (along with deep cloning) could provide a
better framework than by-value vs by-reference in modern OO languages.
This is rather different from defining a *type* that is immutable,
since it implies temporary immutability of a particular instance; but
it seems to be what at least some of your examples are hinting at.
The problem is that deep cloning and deep immutability are
non-trivial; PHP notably doesn't support deep cloning of objects,
requiring each class to define what to do with any non-primitive
members, since some may represent resources which can't be
meaningfully cloned just by copying data in memory.
*snip*
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/standards can often suffice
as there are cases where immutability makes code uglier, not better.
For the latter, it allows the compiler/runtime to do two things: Catch
code errors early and optimize based on assumptions.
In practice, I don't see much value in a language allowing a variable to
be flagged as mutable or immutable *unless* the default is immutable, as
in F# or Rust. In those cases it encourages the developer to take more
functional, immutable approaches most of the time, which (it is argued)
lead to better code, and more optimizable code (because the compiler can
make more assumptions). Switching PHP to default-immutable variables is
clearly off the table, so allowing individual variables to be explicitly
marked as immutable, particularly scalars as Stanislav points out,
doesn't sound like it would offer much.
What *could* be valuable, however, is flagging *parameters*. Ie:
function foo(const MyClass $c, const $s) {
$s = 'abc'; // Compiler error
$c = new MyClass(); // Compiler error.
$c-foo = 'abc'; // Some kind of error?
}
With PHP's existing copy-on-write there's not much memory-savings to be
had with const reference parameters, as in C. What the above would
allow is for the compiler to catch certain errors, especially if the
parameters are on a method in an interface. Ie, the following:
interface Foo {
public function setFromThing(const Thing $t);
}
Makes it explicitly clear that an implementer is *not allowed* to modify
$t in their setFromThing() implementation. Of course, as Rowan notes
object encapsulation makes enforcing that quite difficult, which is
arguably by design.
So I suppose the more general question is, are there code annotations
(immutable values, marking a function as pure, explicit scalar types,
etc.) that developers could insert that would:
1) Provide guidance for developers reasoning about the code.
2) Allow the compiler to catch more bugs.
3) Allow the compiler to better optimize the code by safely making more
assumptions.
4) Some combination of the above.
Eg, if the compiler knows a given function is pure (explicit input and
output, no
Re: [PHP-DEV] Use caller keyword, to access object caller.
2015-02-01 2:23 GMT+02:00 Stanislav Malyshev smalys...@gmail.com: 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: ?php $holder-object-call($holder); This code explicitly says object-call() is using $holder. It is clear and unambiguous. If you did it implicitly - i.e. wrote $holder-object-call() and that used $holder under the hood in call() - then you could have modified or even completely destroyed $holder under the assumption that nobody depends on it, but in fact whatever is in $holder-object, unknown to you, would depend on it and would break. Such hidden dependencies are not a good design. But if have an easy way to get a pointer to the owner, in practice, is very convenient. It may be convenient in short run, but I think in the long run creating hidden dependencies would make code less robust so it is better not to enable it as a best practice. -- Stas Malyshev smalys...@gmail.com 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. I think, that purchased experience will be the use of safety culture dynamic runtime context, many developers it would be appreciated, to implement this PHP frameworks. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] ReflectionParameter::getClassName()
On 31 January 2015 at 17:31, Philip Sturgeon pjsturg...@gmail.com wrote: On Sat, Jan 31, 2015 at 3:12 AM, Matteo Beccati p...@beccati.com 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() is just getClass()-name I think Matteo's point is that if any scalar type RFC passes, a type-hint for a parameter would not always be the name of a class, so the method name 'getClassName()' would be misleading. It would be good to choose a better name to avoid that problem. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 PM, Nikita Popov nikita@gmail.com wrote: On Fri, Jan 30, 2015 at 8:23 AM, Dmitry Stogov dmi...@zend.com 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, because now foreach by value over array doesn't require array duplication. https://wiki.php.net/rfc/php7_foreach https://github.com/php/php-src/pull/1034 I'm going to continue work on implementation improvement and may be fixing related behavior of some internal functions when they used on array iterated by foreach by reference (e.g. array_unshift()). However, the conceptual behavior defined in RFC is not going to be changed anymore. Thanks. Dmitry. I think the new behavior introduced by this RFC is much more consistent than what we have right now. Previously things depended on details of refcounting and hashing and had very weird interaction with current() etc. Now the behavior looks clear for all cases. There's just one thing I'd like to discuss: The object by-value case: Currently this is handled in much the same way as array by-reference, i.e. changes to the object will influence iteration. Currently we can't implement this any differently, however if we always use zend_array instead of HashTable (and fully support refcounting for this), as has been suggested in another thread, we could handle this case the same way as arrays (i.e. just add a refcount to the properties zend_array). Assuming we can implement it this way, I'm not totally sure which behavior makes more sense. On one hand it would make arrays and plain objects work the same way. On the other hand arrays and objects have different copying semantics in other places as well. Anyway, big +1 on this, thanks for implementing it. Nikita
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 passed explicitly - as a parameter/method call/etc. - not hidden. Otherwise it would lead to nasty surprises when the user of the API assumes caller does not matter but the implementor assumes it does. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 les...@lsces.co.uk 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 'session.cache_limiter' into the search I have the usual hassle of trying to get to the right pigging section of the website before it works, but I still have to search around for the session_cache_limiter entry as one gets 'session.cache_limiter doesn't exist. Closest matches: ' Many deprecated features exhibit this problem, but this one seems a lot more critical to resolve if you want to simplify things. ini_set values like max_execution_time don't even come up in a search! Good point. But whole site search shows these INI on top. Document search could be improved. I agree. The same applies to all INI values. The whole site search only provides some ini_set/get values. (and not being able to access that from a wiki page is irritating at times like these!) This is not such a problem with the ones you are looking to add to the list but previous tidying has left manual entries somewhat lacking which tends to prevent any lookup. While the proposed changes only require a replacement of each entry with the alternate text, it is important that the manual has a better means of identifying all of the ini_set keys. -- 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] Use caller keyword, to access object caller.
2015-02-01 0:10 GMT+02:00 Rowan Collins rowan.coll...@gmail.com:
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 the dynamic of this in JavaScript.
Dynamic this, sometimes very convenient for the event model, so I
proposed to implement this feature in PHP.
In PHP, there traits, extends, but it's all static bind, in runtime
can not be added or redefined.
I'll show a simple JS example, in which needed behavior dynamic this.
script language=JavaScript
function A(){}
function B(){}
function getHolder()
{
console.log(this.constructor.name)
}
var oA = new A
var oB = new B
oA.getHolder = getHolder
oB.getHolder = getHolder
oA.getHolder() // return A
oB.getHolder() // return B
getHolder() // return Window
/script
Perhaps we should use the keyword this instead of caller? :)
Then the code in PHP will look like this:
?php
class A
{
public $object;
}
class B
{
public $object;
}
class C
{
public function getHolder() {
return this::class;
}
}
$a = new A;
$b = new B;
$c = new C;
$a-object = $c;
$b-object = $c;
$a-object-getHolder(); // return A
$b-object-getHolder(); // return B
$c-getHolder(); // Fatal Error - undefined context
?
What do you think?
Thank.
Hi,
I think I get what you're trying to do, but I'm not sure the PHP code you
suggest is quite equivalent to the JavaScript. In JavaScript, you are
setting a single function (getHolder) as a direct member of your objects:
oA.getHolder = getHolder
oB.getHolder = getHolder
But in the PHP, you are attaching a whole object to a property:
$a-object = $c;
$b-object = $c;
When you call getHolder in PHP, the holder of that method is always $c,
because you could split the code up like this:
$something = $a-object;
$something-getHolder();
In general, a method can't be copied from one object to another in PHP like
it can in JS, so the concept of dynamic this doesn't normally make any
sense. However, you can do something similar by binding a closure; you
just need to invoke it a bit differently because properties and methods are
not interchangeable like they are in JS:
?php
class A {
public $getHolder;
}
class B {
public $getHolder;
}
$getHolderDefinition = function() { return get_class($this); };
$a = new A;
$b = new B;
$a-getHolder = $getHolderDefinition-bindTo($a);
$b-getHolder = $getHolderDefinition-bindTo($b);
echo $a-getHolder-__invoke(), \n;
echo $b-getHolder-__invoke(), \n;
// Or
$method = $a-getHolder;
echo $method(), \n;
$method = $b-getHolder;
echo $method(), \n;
For many callback / event scenarios, you don't actually need to treat the
closure as a property / method of the object at all, you just want the $this
reference, so the -bindTo() part is all you need, maybe more like this:
class SomeEventTarget {
function triggerEvent($someCallback) {
$boundCallback = $someCallback-bindTo($this);
$boundCallback($some, $arguments);
}
}
(PS: The house rules for this list asks for replies to be below quoted text,
not above.)
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Yes, you're right, in PHP you can solve this problem by other methods, I know...
But the problem is that PHP is no nice and convenient for solving this problem.
So I suggested to add new keyword, not to do manually bindTo($this)
for each methods.
Thank.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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: ?php $holder-object-call($holder); This code explicitly says object-call() is using $holder. It is clear and unambiguous. If you did it implicitly - i.e. wrote $holder-object-call() and that used $holder under the hood in call() - then you could have modified or even completely destroyed $holder under the assumption that nobody depends on it, but in fact whatever is in $holder-object, unknown to you, would depend on it and would break. Such hidden dependencies are not a good design. But if have an easy way to get a pointer to the owner, in practice, is very convenient. It may be convenient in short run, but I think in the long run creating hidden dependencies would make code less robust so it is better not to enable it as a best practice. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Immutable variables and objects
Hi Stas, On 1 Feb 2015, at 00:55, Stanislav Malyshev smalys...@gmail.com 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, in the benchmarks we've run the performance cost of all those new objects is measured in nanoseconds, ie, small enough that we're not worried about it. (Hats off to the PHP Internals folks for making that fast!) 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 nobody needs 5 new objects when you do it. Am I missing something here? I assume the reason for doing this is so you can’t ever modify the object from a distance, you must always create a new one to avoid messing up anything with an existing handle on it. As you mention, though, this means that you get useless intermediate objects. This use case could be solved much better if we had copy-on-write/value-type classes like PHP 4 had. If Request was a value-type class, then you could do this: $a = new Request(); $a-addHeaders(…); $a-setBody(…); $a-setEncoding(…); $a-setETag(…); 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. Would that make sense? It’s no different than how our existing value types like scalars and arrays work. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Immutable variables and objects
Hi, On 1 Feb 2015, at 02:09, Stanislav Malyshev smalys...@gmail.com 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 many cases (especially DI setups, many design patterns, etc.) the whole point of creating the object is to pass it around. Just pointlessly copying it out of fear somebody somewhere could modify it doesn't sound the best way. Well, that’s the advantage of copy-on-write: you can avoid needless manual copies, and instead have automatic copying done for you by the language, where needed. Although implementing copy-on-write for object methods might be a challenge, give PHP doesn’t track which functions have side effects. I'd rather just have a clear separation between mutating and non-mutating APIs, and instruct people to use the right ones in right situation - i.e. if you created the object or own it, use mutating ones, if you got object from outside and do not have full ownership of it, use non-mutating ones. This isn’t very nice in practice, though. Mutating APIs are easy to use and performant, non-mutating APIs are neither of these things. What you want is the benefits of the first without the disadvantages of the second. Would that make sense? It’s no different than how our existing value types like scalars and arrays work. Scalars don't have this problem as, except for string offsets (IMHO not the best idea to have mutable strings too) scalars can not really be changed, just replaced with other scalars. But implementing value objects in PHP is not hard right now - if you don't provide any methods that allow changing state, you've got an immutable object. It's just not always what people using it would want, especially with something as complex as HTTP message. You’re ignoring arrays, which *also* have our copy-on-write behaviour. Also, the bigint RFC (if passed) would be another kind of mutable scalar. It’s not mutable in very many cases, but it is in some places as a performance optimisation. We have value objects, sure, but they’re not efficient. Every mutation requires the creation of a new object, because you can’t do copy-on-write. Compare that to arrays: mutations there only create new arrays if the refcount is 1. The following code using immutable value objects requires the creation of five new objects: $a = $somefoo -withBar(…) -withBaz(…) -withQux(…) -withoutFooBar(); Yet the following code using arrays, which are passed by value in PHP, requires the creation of only one new array, and modifies in-place: $a = $somefoo; $a[‘bar’] = …; $a[‘baz’] = …; $a[‘qux’] = …; unset($a[‘foobar’]); Is that not superior? -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 perfect from all POVs, but it's still very handy to use shorthands whenever they become advantageous. The RFC has a lot of examples regarding this. Anyway, thinking in terms of scripting it seems to be a nice feature. Therefore +1 That's very good to know. Thanks you for your support.
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 already handle the laborious parts for you. I invite you to think about
a big part
of the user base that would like to have a shorthand syntax and don't like
to have
namespaces folded away (hidden) by an IDE.
Anyway, the proper tooling you reffered would quickly be updated to handle
syntax additions and you won't loose anything with that. The point is that
not
all PHP user base should be obligated to use whatever ones define as
proper tooling
to have a pleasant experience with the language, this should come by design
:)
Other languages like Rust, Python, Scala, etc, have analogous features and
I'm sure
IDEs have good support for it. Same will/would happen to PHP.
The RFC says:
Group use statements makes it easier to identify that multiple imported:
entities are from the same module.
IMHO that's too subjective. What is hard with the current state of
affairs?
Readability is not that subject. Current syntax is obviously harder to read:
`use function foo\math\sin, foo\math\cos, foo\math\cosh, foo\math\tan,
foo\math\atan;`
When compared to the proposed:
`use function foo\math\{ sin, cos, cosh, tan, atan };`
Btw, here's a CON you can add to the RFC (and, btw., it doesn't contain
any):
- Prevents searching sources literally for used namespaces
What is the real benefit of using groups it and who's the group
benefiting from that change? Maybe you can expand on that in the RFC.
That's sounds reasonable to me, I'll soon update the RFC with your point
and expand the benefits part.
Thank you!
Re: [PHP-DEV] Use caller keyword, to access object caller.
2015-02-01 1:52 GMT+02:00 Stanislav Malyshev smalys...@gmail.com: 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 passed explicitly - as a parameter/method call/etc. - not hidden. Otherwise it would lead to nasty surprises when the user of the API assumes caller does not matter but the implementor assumes it does. -- Stas Malyshev smalys...@gmail.com This is a controversial statement. 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: ?php $holder-object-call($holder); ? Opportunity to shoot yourself in the foot, will always, developers node.js it know. I know that this code can be arranged differently, but then you have to make it more difficult and not nice. But if have an easy way to get a pointer to the owner, in practice, is very convenient. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 objects is measured in nanoseconds, ie, small enough that we're not worried about it. (Hats off to the PHP Internals folks for making that fast!) 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 nobody needs 5 new objects when you do it. Am I missing something here? -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 whole point of creating the object is to pass it around. Just pointlessly copying it out of fear somebody somewhere could modify it doesn't sound the best way. I'd rather just have a clear separation between mutating and non-mutating APIs, and instruct people to use the right ones in right situation - i.e. if you created the object or own it, use mutating ones, if you got object from outside and do not have full ownership of it, use non-mutating ones. Would that make sense? It’s no different than how our existing value types like scalars and arrays work. Scalars don't have this problem as, except for string offsets (IMHO not the best idea to have mutable strings too) scalars can not really be changed, just replaced with other scalars. But implementing value objects in PHP is not hard right now - if you don't provide any methods that allow changing state, you've got an immutable object. It's just not always what people using it would want, especially with something as complex as HTTP message. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] ReflectionParameter::getClassName()
On 1 Feb 2015, at 01:23, Dan Ackroyd dan...@basereality.com wrote: On 31 January 2015 at 17:31, Philip Sturgeon pjsturg...@gmail.com wrote: On Sat, Jan 31, 2015 at 3:12 AM, Matteo Beccati p...@beccati.com 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() is just getClass()-name I think Matteo's point is that if any scalar type RFC passes, a type-hint for a parameter would not always be the name of a class, so the method name 'getClassName()' would be misleading. It would be good to choose a better name to avoid that problem. We already have that problem (array, callable). I think the more important issue is the conflict with the ReflectionTypeAnnotation RFC, which proposes something similar to what was originally part of the Return Types RFC: https://wiki.php.net/rfc/reflectionparameter.typehint Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 ras...@lerdorf.com 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/php7_foreach#additional_behavoir_change Trivial implementation on top of the main patch: https://gist.github.com/dstogov/63b269207ba0aed8b776 and an additional proposed voting question. Also, the implementation now must be almost complete. I built your branch and applied Nikita's patch as well and ran it through my benchmark box here. Before - After numbers in requests/sec: Drupal8-b4182 - 184 Wordpress-4.1 661 - 675 phpbb-3.1.2 1071 - 1084 Mediawiki-1.24.1 304 - 306 Opencart-2.0.1.1 458 - 459 WardrobeCMS-1.2.0 993 - 999 Geeklog-2.1.0 823 - 825 Traq-3.5.2 1869 - 1902 So about a 1% boost across the board except for Opencart, but it spends most of its time creating sessions on disk and writing to MySQL. No obvious visible things broke in any of these. Overall, even without the performance boost, I think making the edge-case foreach behaviour consistent and predictable is a good thing on its own. -Rasmus
Re: [PHP-DEV] [RFC] Immutable variables and objects
Hey Larry,
On 1 Feb 2015, at 00:42, Larry Garfield la...@garfieldtech.com 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/standards can often suffice as
there are cases where immutability makes code uglier, not better.
For the latter, it allows the compiler/runtime to do two things: Catch code
errors early and optimize based on assumptions.
PHP doesn’t have immutable classes, though, so the PHP runtime *can’t* reason
about code using value objects and such, and they’re less performant than
mutable objects with manual copying.
I think having some means to create value type classes (i.e. PHP 4-style
classes) would be beneficial. These classes would have the same always-copy or
copy-on-write behaviour that PHP’s scalar types and arrays have. They’d be
performant compared to immutable classes like PSR-7’s, because operations
mutate the value in-place if possible, rather than creating a new class. They’d
also be nicer to use, because you can change the value imperatively rather than
having to chain together return values. But you keep the main advantages of
immutable types: no spooky action at a distance, no explicit copying needed.
What *could* be valuable, however, is flagging *parameters*. Ie:
function foo(const MyClass $c, const $s) {
$s = 'abc'; // Compiler error
$c = new MyClass(); // Compiler error.
$c-foo = 'abc'; // Some kind of error?
}
const parameters are a cool feature in C. However, the main use for them in C
doesn’t really exist in PHP. In C, most of the time you need to pass a pointer
to a value to a function, rather than a value directly. Having a pointer to a
value means you can modify that value. So, there’s a need for a “const”
modifier to mark parameters as being for values that will be taken as input and
not modified, rather than as values that will be used as output and modified.
PHP, on the other hand, doesn’t have pointers. Parameters are usually by-value
(objects are by-reference, but still). If you want to mutate some value, you
need to explicitly mark it as such… most parameters are already “constant”.
Though, I suppose there’s some usefulness in that, since all objects are
by-reference, you might want to say you won’t touch that object. Hmm. Given
that PHP is dynamic, not compiled, and function calls can have side effects,
though, this would be difficult to enforce. You’d need to check that all calls
made within the function do not have any side effects on that value…
I’m not sure how workable this is.
Thanks.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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 exactly you mean by dynamic context in JS but take into account that JS implementation of OO is quite different from PHP, so you can not directly port concepts between them. I think, that purchased experience will be the use of safety culture dynamic runtime context, many developers it would be appreciated, to implement this PHP frameworks. I'm sorry, I'm having hard time understanding what you mean here. I believe if you want to take it further, you'd need to provide some more detailed explanations, with examples, etc. of what you're trying to improve and why. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 research phase it became obvious that a majority part of the user base would like to have a shorthand syntax for use declarations. I just wonder if it could feel more PHP. We tried other syntaxes and this one seemed the most appropriate because: a) Looks a lot like the already implemented traits conflict resolution b) Doesn't require to reserve new keywords c) It requires a minimal implementation and is easy to read and parse Maybe I'm just nitpicking and it will grow on me :) FYI, suggestions for alternatives are still welcome. But I really hope you end up liking the current proposal even more. Thanks.
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 the dynamic of this in JavaScript.
Dynamic this, sometimes very convenient for the event model, so I
proposed to implement this feature in PHP.
In PHP, there traits, extends, but it's all static bind, in runtime
can not be added or redefined.
I'll show a simple JS example, in which needed behavior dynamic this.
script language=JavaScript
function A(){}
function B(){}
function getHolder()
{
console.log(this.constructor.name)
}
var oA = new A
var oB = new B
oA.getHolder = getHolder
oB.getHolder = getHolder
oA.getHolder() // return A
oB.getHolder() // return B
getHolder() // return Window
/script
Perhaps we should use the keyword this instead of caller? :)
Then the code in PHP will look like this:
?php
class A
{
public $object;
}
class B
{
public $object;
}
class C
{
public function getHolder() {
return this::class;
}
}
$a = new A;
$b = new B;
$c = new C;
$a-object = $c;
$b-object = $c;
$a-object-getHolder(); // return A
$b-object-getHolder(); // return B
$c-getHolder(); // Fatal Error - undefined context
?
What do you think?
Thank.
Hi,
I think I get what you're trying to do, but I'm not sure the PHP code
you suggest is quite equivalent to the JavaScript. In JavaScript, you
are setting a single function (getHolder) as a direct member of your
objects:
oA.getHolder = getHolder
oB.getHolder = getHolder
But in the PHP, you are attaching a whole object to a property:
$a-object = $c;
$b-object = $c;
When you call getHolder in PHP, the holder of that method is always
$c, because you could split the code up like this:
$something = $a-object;
$something-getHolder();
In general, a method can't be copied from one object to another in PHP
like it can in JS, so the concept of dynamic this doesn't normally make
any sense. However, you can do something similar by binding a closure;
you just need to invoke it a bit differently because properties and
methods are not interchangeable like they are in JS:
?php
class A {
public $getHolder;
}
class B {
public $getHolder;
}
$getHolderDefinition = function() { return get_class($this); };
$a = new A;
$b = new B;
$a-getHolder = $getHolderDefinition-bindTo($a);
$b-getHolder = $getHolderDefinition-bindTo($b);
echo $a-getHolder-__invoke(), \n;
echo $b-getHolder-__invoke(), \n;
// Or
$method = $a-getHolder;
echo $method(), \n;
$method = $b-getHolder;
echo $method(), \n;
For many callback / event scenarios, you don't actually need to treat
the closure as a property / method of the object at all, you just want
the $this reference, so the -bindTo() part is all you need, maybe more
like this:
class SomeEventTarget {
function triggerEvent($someCallback) {
$boundCallback = $someCallback-bindTo($this);
$boundCallback($some, $arguments);
}
}
(PS: The house rules for this list asks for replies to be below quoted
text, not above.)
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Magic getter bug tickled by Moodle
Hey: On Sat, Jan 31, 2015 at 3:15 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 01/30/2015 11:13 PM, Michael Wallner wrote: On 31 Jan 2015 06:04, Rasmus Lerdorf ras...@lerdorf.com mailto:ras...@lerdorf.com wrote: There is something weird going on with PHP7 and the moodle_page class and all its magic methods. It dies with a: /var/www/moodle/blocks/navigation/block_navigation.php(223) : Notice - Undefined property: moodle_page::$navigation /var/www/moodle/blocks/navigation/block_navigation.php(223) : Fatal error - __clone method called on non-object That code is: 222 $this-page-navigation-initialise(); 223 return clone($this-page-navigation); See: https://github.com/moodle/moodle/blob/master/blocks/navigation/block_navigation.php#L222-L223 $this-page_navigation is created on that initial call through the wonders of this magic: https://github.com/moodle/moodle/blob/master/lib/pagelib.php#L757-L772 Which somehow leads us to read 8 bytes in a free'ed block: https://gist.github.com/anonymous/f9d1f53b1205d29d86cc but I am not having much luck dwindling it down to a simpler reproduce case. If you know this code or have a couple of hours to spare, could you see if you could reduce it to something more manageable for us? (and yes, same code is fine in 5.6) Here's a similar bug, too: https://bugs.php.net/bug.php?id=68933edit=1 Ah, good catch. Yes, https://gist.github.com/arjenschol/3d94195ca51aa44db1c6 looks like a similar pattern to what Moodle is doing in that part of the code that seems to trigger this. must be fixed, https://github.com/php/php-src/commit/1a60175e2595a24ebc3b6d80a112d574c6c98f58 thanks -Rasmus -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why does session.gc_maxlifetime default to 1440 seconds?
On 31 January 2015 at 11:12, Bas van Beek b...@tobin.nl 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 session duration it's really easy to update :) I like the idea of this being a 15+ year old bug where minutes were used instead of seconds :) Initial commits don't really give much of a hint to the thinking behind it either it seems. http://svn.php.net/viewvc/archived/php4.fubar/trunk/ext/session/session.c?r1=9519r2=9520pathrev=9520; http://svn.php.net/viewvc/archived/php4.fubar/trunk/php.ini-dist?r1=10922r2=10923pathrev=10923; /cc sas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 standard was snake_case. That is the standard I still use, and I will object most strongly to the notion that I should change the habits of a lifetime just to suit the personal preferences of a junior programmer. By junior I mean years of experience, not job title. Tony, the question here is not the style of your personal code base, which is of course you have the full right to choose as you see fit. The question is the style of the code in PHP core codebase Thank you for clarifying what was not obvious in that post. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 tonymars...@hotmail.com wrote: Pavel Kouril wrote in message news:cab6yzuzymbaa5i3f9nsvebg2b7yjvo4ryvpy-eac78rsojx...@mail.gmail.com... On Wed, Jan 28, 2015 at 1:17 PM, Michael Wallner m...@php.net wrote: snip Hello, just one observation - would be the name of the classes and namespaces stay the same after merging? I personally find the lowercased namespace name kinda weird, given that most of code written in PHP I've seen is using CamelCase. 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 standard was snake_case. That is the standard I still use, and I will object most strongly to the notion that I should change the habits of a lifetime just to suit the personal preferences of a junior programmer. By junior I mean years of experience, not job title. We have coding standard. From the CODING_STANDARDS in source. 6. Method names follow the 'studlyCaps' (also referred to as 'bumpy case' or 'camel caps') naming convention snip 7. Classes should be given descriptive names. Avoid using abbreviations where possible. Each word in the class name should start with a capital letter, without underscore delimiters (CamelCaps starting with a capital letter). The class name should be prefixed with the name of the 'parent set' (e.g. the name of the extension):: snip If you are talking about coding standards which apply to PHP core then that is one thing, but trying to enforce those standards in userland code would be completely unacceptable. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 m...@php.net wrote: just one observation - would be the name of the classes and namespaces stay the same after merging? I personally find the lowercased namespace name kinda weird, given that most of code written in PHP I've seen is using CamelCase. 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 standard was snake_case. That is the standard I still use, and I will object most strongly to the notion that I should change the habits of a lifetime just to suit the personal preferences of a junior programmer. By junior I mean years of experience, not job title. Core uses CamelCase class names. The overwhelming majority of the PHP code I've seen in the wild uses CamelCase for both classes and namespaces. I'm afraid that code that I have seen is only a small fraction of all the code that has been written. I use snake_case simply because it was the standard in those language which I used in the 20 years before switching to PHP. PHP has never enforced any particular naming convention, nor should it. Thus I am free to whatever I please, whether it be snake_case, camelCase, StudlyCaps or whatever. Other languages certainly have other conventions, but this is PHP. It is not up to the language to dictate coding style or naming conventions, that is entirely the domain of each group of programmers. This isn't personal preference of a junior programmer (which is a rather flippant way to dismiss a fellow developer you do not know). I have been in the software industry for over 35 years, and I have encountered many different standards, some good, some bad. The standards that I still use today are based on all the better parts from those individual standards. I object most strongly to a programmer who has far less experience than me suddenly telling me that I must change the habits of a lifetime so that my coding style conforms to his personal preferences. Such arrogance! It's the convention used by most of an industry. How do you know that it most of the industry? Snake_case existed for years before camelCase was invented, and is still used by many. It is even evident in PHP itself, so your assertion is just a personal opinion and not a fact. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 never received a reply. On Sat, Jan 31, 2015 at 12:54 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Markus, On Sat, Jan 31, 2015 at 4:02 AM, Markus Amalthea Magnuson markus.magnu...@gmail.com wrote: I've been trying to figure out the design decision behind why the default value of session.gc_maxlifetime is 1440 seconds (24 minutes)? Does anyone know or have any good sources? Because the author set this value, I think. It was 1440 since session module is introduced, IIRC. I think 1440 is reasonable value for many applications. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
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, om 11:45 heeft Markus Amalthea Magnuson markus.magnu...@gmail.com het volgende geschreven: 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 never received a reply. On Sat, Jan 31, 2015 at 12:54 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Markus, On Sat, Jan 31, 2015 at 4:02 AM, Markus Amalthea Magnuson markus.magnu...@gmail.com wrote: I've been trying to figure out the design decision behind why the default value of session.gc_maxlifetime is 1440 seconds (24 minutes)? Does anyone know or have any good sources? Because the author set this value, I think. It was 1440 since session module is introduced, IIRC. I think 1440 is reasonable value for many applications. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] pecl_http
On Jan 30, 2015 6:09 PM, Tony Marston tonymars...@hotmail.com wrote: Pavel Kouril wrote in message news:cab6yzuzymbaa5i3f9nsvebg2b7yjvo4ryvpy-eac78rsojx...@mail.gmail.com... On Wed, Jan 28, 2015 at 1:17 PM, Michael Wallner m...@php.net wrote: Hi, snip Hello, just one observation - would be the name of the classes and namespaces stay the same after merging? I personally find the lowercased namespace name kinda weird, given that most of code written in PHP I've seen is using CamelCase. 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 standard was snake_case. That is the standard I still use, and I will object most strongly to the notion that I should change the habits of a lifetime just to suit the personal preferences of a junior programmer. By junior I mean years of experience, not job title. 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/CODING_STANDARDS
Re: [PHP-DEV] [RFC] [VOTE] pecl_http
On Jan 31, 2015 5:57 PM, Tony Marston tonymars...@hotmail.com wrote: Yasuo Ohgaki wrote in message news:caga2bxzgljrp6i2vdnkdga8dw7nothc9ie17tst40kpbbha...@mail.gmail.com... Hi Tony, On Fri, Jan 30, 2015 at 7:08 PM, Tony Marston tonymars...@hotmail.com wrote: Pavel Kouril wrote in message news:cab6yzuzymbaa5i3f9nsvebg2b7yjvo4ryvpy-eac78rsojx...@mail.gmail.com. .. On Wed, Jan 28, 2015 at 1:17 PM, Michael Wallner m...@php.net wrote: snip Hello, just one observation - would be the name of the classes and namespaces stay the same after merging? I personally find the lowercased namespace name kinda weird, given that most of code written in PHP I've seen is using CamelCase. 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 standard was snake_case. That is the standard I still use, and I will object most strongly to the notion that I should change the habits of a lifetime just to suit the personal preferences of a junior programmer. By junior I mean years of experience, not job title. We have coding standard. From the CODING_STANDARDS in source. 6. Method names follow the 'studlyCaps' (also referred to as 'bumpy case' or 'camel caps') naming convention snip 7. Classes should be given descriptive names. Avoid using abbreviations where possible. Each word in the class name should start with a capital letter, without underscore delimiters (CamelCaps starting with a capital letter). The class name should be prefixed with the name of the 'parent set' (e.g. the name of the extension):: snip If you are talking about coding standards which apply to PHP core then that is one thing, but trying to enforce those standards in userland code would be completely unacceptable. This is a discussion about adding features to core. They have to follow our CS. Period. There is nothing to discuss here. Sorry to sound harsh but this is going far OT. I would prefer to focus on the features and implementation details instead of that.
Re: [PHP-DEV] [RFC] [VOTE] pecl_http
On Sat, Jan 31, 2015 at 1:41 PM, Pierre Joye pierre@gmail.com 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/CODING_STANDARDS Well, the coding standard doesn't mention namespaces. So shouldn't it be updated to include namespaces? If there's an RFC for including something using namespaces, the should be rules for naming namespaces in the coding standard, IMHO. Pavel Kouril -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
