[PHP-DEV] Re: Array of current instances count
On 03/29/2013 04:50 PM, Frank Liepert wrote: Hello Internals, I'm thinking about a new function returning an array of classes and their individual number of instances. It would look pretty much like the result of get_declared_classes(). An Example: print_r (get_instantiated_classes()); // Array () $foo = new StdClass; print_r (get_instantiated_classes()); // Array ( [StdClass] = 1 ) $bar = new StdClass; print_r (get_instantiated_classes()); // Array ( [StdClass] = 2 ) ... and so on Such a function could be helpful when refactoring and/or optimizing an application. Just think of implementing the flyweight pattern in parts of an application, where it is applicable. You could check against precise numbers, for example when you're expecting the number of instances to decrease by a certain number. Besides microtime() and get_memory_usage(), it could be another useful indicator. Since I'm neither familiar with C nor the Zend Engine, I cannot implement the feature and do not know, if it is even possible. But first of all, I'm asking you for your opinions. Frank I think there is some merit to that ... https://gist.github.com/krakjoe/5275773 The question is, why no ZTS ? NJoy :) Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Array of current instances count
On 03/30/2013 07:45 AM, Joe Watkins wrote: On 03/29/2013 04:50 PM, Frank Liepert wrote: Hello Internals, I'm thinking about a new function returning an array of classes and their individual number of instances. It would look pretty much like the result of get_declared_classes(). An Example: print_r (get_instantiated_classes()); // Array () $foo = new StdClass; print_r (get_instantiated_classes()); // Array ( [StdClass] = 1 ) $bar = new StdClass; print_r (get_instantiated_classes()); // Array ( [StdClass] = 2 ) ... and so on Such a function could be helpful when refactoring and/or optimizing an application. Just think of implementing the flyweight pattern in parts of an application, where it is applicable. You could check against precise numbers, for example when you're expecting the number of instances to decrease by a certain number. Besides microtime() and get_memory_usage(), it could be another useful indicator. Since I'm neither familiar with C nor the Zend Engine, I cannot implement the feature and do not know, if it is even possible. But first of all, I'm asking you for your opinions. Frank I think there is some merit to that ... https://gist.github.com/krakjoe/5275773 The question is, why no ZTS ? NJoy :) Joe zts working ... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Simplified Array API for extensions
On 04/03/2013 06:23 PM, Sara Golemon wrote:
1a) The c modifier seems like an unnecessary microoptimization. Compilers
should be able to optimize strlen() calls on constant strings away and even
if they didn't, it wouldn't be much of a big deal. Also using the
c-variants on a non-literal would not throw an error and just use an
invalid length instead.
Yeah, killing this for sure.
1b) Imho the l_safe case does not need its own modifier. Typically
strings in PHP are always zero-terminated (in debug mode you'll actually get
warnings if they are not). The cases where they aren't zero-terminated are
rare and in these cases one can just write those two extra lines of code to
do the right thing.
Yeah, the safe version wasn't meant to capture a common case, but it
is one I've found myself running into more a little commonly. The
argument that the rest of the runtime doesn't provide this affordance
is a good one, but I'm still on the fence for this one.
c) I think it would be a lot more intuitive if we used the terminology of
the normal array APIs instead of the shorthands:
php_array_fetch = php_array_fetch_assoc
php_array_fetchl = php_array_fetch_assoc_ex
php_array_fetchn = php_array_fetch_index
php_array_fetchz = php_array_fetch_zval
+1 for consistency, combined with separating out the type conversion
bits the verbosity (which I was trying to avoid) is also not so bad.
2. The php_array_fetch*_* APIs currently combined two things: a) Fetching
from the array and b) Casting it to some type. I think both should be
separate. Not only to avoid the combinatorial explosion of different
modifier+type combinations, but also because those casting methods are also
applicable to other contexts, not just arrays casts. I asked some time ago
to add functions that can directly get a long/double from a zval (though
didn't pursue this further). Your APIs add something like that, but tightly
coupled to array fetches. There would be more use for it if it were separate
:)
It's outside the scope of what I was originally trying to accomplish,
but it's got utility in its own right. So I'll rewrite this entire
proposal as two separate tasks:
#1 - Array access APIs for fetching zval*
zend_array_(fetch|exists|unset)_(assoc|assocl|index|zval)()
#1a - (Optional) Array add APIs renamed for consistency and namespacing:
I'm not a huge fan of this as we'd need to keep
add_(assoc|(next_)?index)_{$type}(), but it's the sort of moment to
embrace consistency in the hopes of deprecating the old calls when we
hit 6.0
#1b - (Optional) Some kind of foreach structure which specializes
zend_hash_apply for the array case:
void callback(zval *key, zval *val, void *optionalArg) {
/* key as a zval owned by the iterator (is_ref=0,rc=2 - force
callee to copy if they want to keep it)
zend_hash_key might be more to the point, but zval is a much
more familiar structure */
/* user code here, none of that ZEND_HASH_APPLY_KEEP stuff though */
}
zend_array_apply(arr, callback, optionalArg);
#2 Scalar zval* accessors (with implicit type conversions):
zend_(bool|long|double|string)_value()
zend_is_true() technically covers zend_bool_value() already, but for
consistency...
And yes, I think we should move em down to Zend...
-Sara
Hi Sara,
A logical extension of this idea would be to drop _array_ and cover
objects too, one uniform everything API is very appealing, and way
easier to document properly.
Something alone the lines of:
static inline
zend_bool php_exists(zval *pzval, const char *key) {
switch (Z_TYPE(pzval)) {
case IS_ARRAY:
return zend_symtable_exists(Z_ARRVAL_P(pzval), key,
strlen(key) + 1);
default: {
if (Z_OBJ_HT_P(pzval)-has_property) {
return Z_OBJ_HT_P(pzval)-has_property(
pzval, key, strlen(key) + 1, 2 NULL TSRMLS_CC
);
} else {
return zend_symtable_exists(
Z_OBJPROP_P(pzval), key, strlen(key) + 1);
}
}
}
}
Just a thought ..
Joe
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Simplified Array API for extensions
On 04/03/2013 08:43 PM, Joe Watkins wrote:
On 04/03/2013 06:23 PM, Sara Golemon wrote:
1a) The c modifier seems like an unnecessary microoptimization.
Compilers
should be able to optimize strlen() calls on constant strings away
and even
if they didn't, it wouldn't be much of a big deal. Also using the
c-variants on a non-literal would not throw an error and just use an
invalid length instead.
Yeah, killing this for sure.
1b) Imho the l_safe case does not need its own modifier. Typically
strings in PHP are always zero-terminated (in debug mode you'll
actually get
warnings if they are not). The cases where they aren't
zero-terminated are
rare and in these cases one can just write those two extra lines of
code to
do the right thing.
Yeah, the safe version wasn't meant to capture a common case, but it
is one I've found myself running into more a little commonly. The
argument that the rest of the runtime doesn't provide this affordance
is a good one, but I'm still on the fence for this one.
c) I think it would be a lot more intuitive if we used the
terminology of
the normal array APIs instead of the shorthands:
php_array_fetch = php_array_fetch_assoc
php_array_fetchl = php_array_fetch_assoc_ex
php_array_fetchn = php_array_fetch_index
php_array_fetchz = php_array_fetch_zval
+1 for consistency, combined with separating out the type conversion
bits the verbosity (which I was trying to avoid) is also not so bad.
2. The php_array_fetch*_* APIs currently combined two things: a)
Fetching
from the array and b) Casting it to some type. I think both should be
separate. Not only to avoid the combinatorial explosion of different
modifier+type combinations, but also because those casting methods
are also
applicable to other contexts, not just arrays casts. I asked some
time ago
to add functions that can directly get a long/double from a zval (though
didn't pursue this further). Your APIs add something like that, but
tightly
coupled to array fetches. There would be more use for it if it were
separate
:)
It's outside the scope of what I was originally trying to accomplish,
but it's got utility in its own right. So I'll rewrite this entire
proposal as two separate tasks:
#1 - Array access APIs for fetching zval*
zend_array_(fetch|exists|unset)_(assoc|assocl|index|zval)()
#1a - (Optional) Array add APIs renamed for consistency and namespacing:
I'm not a huge fan of this as we'd need to keep
add_(assoc|(next_)?index)_{$type}(), but it's the sort of moment to
embrace consistency in the hopes of deprecating the old calls when we
hit 6.0
#1b - (Optional) Some kind of foreach structure which specializes
zend_hash_apply for the array case:
void callback(zval *key, zval *val, void *optionalArg) {
/* key as a zval owned by the iterator (is_ref=0,rc=2 - force
callee to copy if they want to keep it)
zend_hash_key might be more to the point, but zval is a much
more familiar structure */
/* user code here, none of that ZEND_HASH_APPLY_KEEP stuff though */
}
zend_array_apply(arr, callback, optionalArg);
#2 Scalar zval* accessors (with implicit type conversions):
zend_(bool|long|double|string)_value()
zend_is_true() technically covers zend_bool_value() already, but for
consistency...
And yes, I think we should move em down to Zend...
-Sara
Hi Sara,
A logical extension of this idea would be to drop _array_ and cover
objects too, one uniform everything API is very appealing, and way
easier to document properly.
Something alone the lines of:
static inline
zend_bool php_exists(zval *pzval, const char *key) {
switch (Z_TYPE(pzval)) {
case IS_ARRAY:
return zend_symtable_exists(Z_ARRVAL_P(pzval), key,
strlen(key) + 1);
default: {
if (Z_OBJ_HT_P(pzval)-has_property) {
return Z_OBJ_HT_P(pzval)-has_property(
pzval, key, strlen(key) + 1, 2 NULL TSRMLS_CC
);
} else {
return zend_symtable_exists(
Z_OBJPROP_P(pzval), key, strlen(key) + 1);
}
}
}
}
Just a thought ..
Joe
https://gist.github.com/krakjoe/5304945
I'd be happy to complete/test it if we think it's a worthy direction to
go in ... a unified api does look delicious, it's a bit more complex
than arrays but then in extensions you want/need to deal with objects as
much as, if note more than, you do arrays ...
Joe
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Simplified Array API for extensions
On 04/04/2013 04:09 AM, Sara Golemon wrote: A logical extension of this idea would be to drop _array_ and cover objects too, one uniform everything API is very appealing, and way easier to document properly. https://gist.github.com/krakjoe/5304945 I'd be happy to complete/test it if we think it's a worthy direction to go in ... a unified api does look delicious, it's a bit more complex than arrays but then in extensions you want/need to deal with objects as much as, if note more than, you do arrays ... While I'm in favor of an API which covers both Arrays and Object properties, I don't want to go too far in the direction of generically named APIs. php_exists() is, I think, too far. I'm not sure what's the right middle-ground of being both descriptive and concise, but I'm sure we can sort that out. Morning, Yeah maybe a bit far, php_exists doesn't really have any context ... I'm all in favour of php_object_exists php_array_exists both having the exact same prototypes and sharing documentation, it just seems a waste to write _object_/_array_ at all ... Any other ideas, or just go with _object_/_array_ ? Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Simplified Array API for extensions
The idea was to avoid treating the object as an array of properties
where there is another option. Where there isn't an option the objects
properties have to be accessed as an array dont they?
On 4/4/13, Nikita Popov nikita@gmail.com wrote:
On Wed, Apr 3, 2013 at 9:43 PM, Joe Watkins krak...@php.net wrote:
Hi Sara,
A logical extension of this idea would be to drop _array_ and cover
objects too, one uniform everything API is very appealing, and way easier
to document properly.
Something alone the lines of:
static inline
zend_bool php_exists(zval *pzval, const char *key) {
switch (Z_TYPE(pzval)) {
case IS_ARRAY:
return zend_symtable_exists(Z_ARRVAL_**P(pzval), key,
strlen(key) + 1);
default: {
if (Z_OBJ_HT_P(pzval)-has_**property) {
return Z_OBJ_HT_P(pzval)-has_**property(
pzval, key, strlen(key) + 1, 2 NULL TSRMLS_CC
);
} else {
return zend_symtable_exists(
Z_OBJPROP_P(pzval), key, strlen(key) + 1);
}
}
}
}
Just a thought ..
Strong -1 on anything that tries to treat objects as if they were arrays of
properties. I think much damage has already been done by using object
properties as an array in some places and we should not go further down
that road. I have no problem with nice APIs for object properties access,
but please, please do not mix both.
Nikita
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Adding a way to retreive compile options at runtime
On 04/04/2013 03:18 PM, Julien Pauli wrote: Hello everybody, Today we talked about a way to detect --with-curlwrappers at runtime. It is nowadays not possible easilly. Then , I remembered I once proposed to add a new function that could return every ./configure options used to compile the runtime PHP the code is beeing run on. We already have php-config --configure-options, but that needs to exist and that needs an exec() call. We also already have phpinfo() which returns that, but not in a very fancy way (we need to preg_ the output which is ugly and not very simple). Today, Seldaek proposed what I think is a cool way to solve this problem : add a new parameter to phpinfo() function, which could return in an array what it usually directly print throught the SAPI print() function (HTMLing the output when needed). The use case would be : ?php $output = phpinfo(INFO_GENERAL, true); var_dump($output); /* something like ['Debug Build' ='no', 'Thread Safety'='yes', 'Configure Command'=['--enable-foo', '--with-config-file-scan-dir'='/etc' ]] As you can see, it is rather simple but would need some work as it is better for the Configure Command to return an array with the options instead of a big string ; easier to parse. Thoughts ? Julien.Pauli Seems like a good idea to me ... So ... https://gist.github.com/krakjoe/5311608 Array ( [with-apxs2] = /opt/php-nts/bin/apxs [prefix] = /opt/php-nts [exec-prefix] = /opt/php-nts [with-config-file-path] = /opt/php-nts/ [with-config-file-scan-dir] = /opt/php-nts/modules.d/ [with-curl] = /usr [with-zlib] = 1 [with-libxml-dir] = /usr [enable-simplexml] = 1 [with-mysql] = mysqlnd [with-pdo-mysql] = mysqlnd [enable-gd-native-ttf] = 1 [with-mysqli] = 1 [enable-sockets] = 1 [with-gd] = 1 [enable-debug] = 1 ) Something that hasn't been mentioned, installation of software like wordpress or whatever, might be able to offer advice to the end user based on the configuration defaults, regardless of ini settings. Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Adding a way to retreive compile options at runtime
On 04/04/2013 05:53 PM, Johannes Schlüter wrote: Joe Watkins krak...@php.net wrote: Something that hasn't been mentioned, installation of software like wordpress or whatever, might be able to offer advice to the end user based on the configuration defaults, regardless of ini settings. Le me repeat what I said in this thread using other words: No, it can't. In a typical case (PHP from distribution with all extensions shared) this has *no* relevance regarding the running system. The extensions loaded might be built completely different from what's said there. Provide the information needed by constants or function calls from an extenson or whatever makes sense, don't advocate to do the wrong thing. johannes Many extensions do not provide constants or functions to detect the way they are configured, this may or may not expose those options, which is better than not being able to expose those options by any reasonable means. More importantly, it does not only contain information about extensions, or which extensions are loaded and how ( I am aware of the problems of using this kind of information as authoritative, I still say something is better than nothing, see every 404 page in all modern browsers, why not provide suggestions, even if they are wrong ). Path information I figure could be useful while setting up software, so could many other configure time options, for example if more than one SAPI was built at configure time, you might advise the use of the most suitable SAPI for your software, you might generate an ini file and tell the user where to put it (scandir), you might have the abnormal path to php-config or other things distributed with php and installed in a non-standard path (/opt/php-nts in example output). There's a bunch of useful stuff in the configure command ... not just extensions loaded ... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Adding a way to retreive compile options at runtime
On 04/04/2013 06:30 PM, Johannes Schlüter wrote: Joe Watkins krak...@php.net wrote: Many extensions do not provide constants or functions to detect the way they are configured, this may or may not expose those options, which is better than not being able to expose those options by any reasonable means. Then those extensions should expose the required information. These are bugs then. More importantly, it does not only contain information about extensions, or which extensions are loaded and how ( I am aware of the problems of using this kind of information as authoritative, I still say something is better than nothing, see every 404 page in all modern browsers, why not provide suggestions, even if they are wrong ). Path information I figure could be useful while setting up software, so The paths set during configure time don't have to match those where things are installed. Especially admins might prefer to use symlinked paths for configuration and users might be misled. could many other configure time options, for example if more than one SAPI was built at configure time, you might advise the use of the most suitable SAPI for your software, SAPIs might be built individually. Having them enabled during configure time doesn't mean they are enabled or accessible by the user. you might generate an ini file and tell the user where to put it (scandir), you might have the abnormal path to php-config or other things distributed with php and installed in a non-standard path (/opt/php-nts in example output). configure options often won't tell- There's a bunch of useful stuff in the configure command ... not just extensions loaded ... Yes and a lot of wrong information. johannes A combination of ENV, ini, phpversion and phpconfopt options should allow you to make much more informed decisions or do nothing at all, there is not a reasonable means to acquire this information, nor is it reasonable to suggest that we modify every single bundled extension in order to expose their configuration options, additional constants and maybe add new functions/methods. I keep using the words could, might, maybe, *on purpose*, I am aware that the configuration time options may not match runtime parameters, I don't think it falls to us to provide the business logic, so it doesn't really matter that the setup may be completely different, it may be the same, or similar. It may be vital information, it may also be completely irrelevant, exposing it provides more flexibility than doing nothing at all. Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Adding a way to retreive compile options at runtime
On 04/04/2013 07:04 PM, Kris Craig wrote: On Thu, Apr 4, 2013 at 10:40 AM, Joe Watkins krak...@php.net wrote: On 04/04/2013 06:30 PM, Johannes Schlüter wrote: Joe Watkins krak...@php.net wrote: Many extensions do not provide constants or functions to detect the way they are configured, this may or may not expose those options, which is better than not being able to expose those options by any reasonable means. Then those extensions should expose the required information. These are bugs then. More importantly, it does not only contain information about extensions, or which extensions are loaded and how ( I am aware of the problems of using this kind of information as authoritative, I still say something is better than nothing, see every 404 page in all modern browsers, why not provide suggestions, even if they are wrong ). Path information I figure could be useful while setting up software, so The paths set during configure time don't have to match those where things are installed. Especially admins might prefer to use symlinked paths for configuration and users might be misled. could many other configure time options, for example if more than one SAPI was built at configure time, you might advise the use of the most suitable SAPI for your software, SAPIs might be built individually. Having them enabled during configure time doesn't mean they are enabled or accessible by the user. you might generate an ini file and tell the user where to put it (scandir), you might have the abnormal path to php-config or other things distributed with php and installed in a non-standard path (/opt/php-nts in example output). configure options often won't tell- There's a bunch of useful stuff in the configure command ... not just extensions loaded ... Yes and a lot of wrong information. johannes A combination of ENV, ini, phpversion and phpconfopt options should allow you to make much more informed decisions or do nothing at all, there is not a reasonable means to acquire this information, nor is it reasonable to suggest that we modify every single bundled extension in order to expose their configuration options, additional constants and maybe add new functions/methods. I keep using the words could, might, maybe, *on purpose*, I am aware that the configuration time options may not match runtime parameters, I don't think it falls to us to provide the business logic, so it doesn't really matter that the setup may be completely different, it may be the same, or similar. It may be vital information, it may also be completely irrelevant, exposing it provides more flexibility than doing nothing at all. Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I don't see any useful production applications for this. However, I could say the same thing about phpinfo() itself. From a debugging and QA standpoint, on the other hand, this could be potentially useful. If, for example, I was writing some sort of server analysis or troubleshooting utility, it might be helpful for me to be able to grab the configure command (or anything else in phpinfo(), for that matter) without having to do a screen scape. So even though the use case for this is somewhat narrow, I think it's something we should have in place, anyway. You should definitely write an RFC for this. --Kris I can't think of anywhere it's definitely useful, but I can think of many places it might be, combined with the right logic, and other things from environment/runtime/info etc ... There's probably one or two server analysis tools in production out there :) Hopefully, jpauli is still okay to move forward with an RFC, if the implementation is any good ... Writing bits of code, good fun, these long drawn out conversations and those that are the result of RFC creation ... not so much ... Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] a couple of thoughts on the DateTime type debate
On 04/05/2013 09:31 AM, Madara Uchiha wrote: After discussing things over the PHP chat on Stack Overflow, I realized I misread and missed the point. Good suggestion, you have my +1. On Fri, Apr 5, 2013 at 11:01 AM, Richard Bradley richard.brad...@softwire.com wrote: On Thu, Apr 4, 2013 at 12:57 PM, Benjamin Eberlei kont...@beberlei.dewrote: structs as in c# don't have methods, however DateTime has them. so this doesn't work. What you can do is just pass all the data in the constructor and then don't change it, and you have your value type that is immutable. It just requires a bit self control. On 04 April 2013 23:59, Rasmus Schultz ras...@mindplay.dk wrote: You're right, struct isn't the right word - value is probably more accurate. Actually structs in C# can have methods. They are exactly classes with value type semantics (i.e. pass-by-value, like arrays in PHP). I think struct would be an ideal name for this feature, as this proposal matches the C# implementation very closely, and many people will be familiar with that. See the Structs Tutorial at msdn for a brief summary of structs in C# - http://msdn.microsoft.com/en-us/library/aa288471(v=vs.71).aspx Richard Bradley Tel : 020 7485 7500 ext 3230 | Fax : 020 7485 7575 softwire Sunday Times Best Small Companies 2012 - 6th in the UK Web : www.softwire.com | Addr : 325 Highgate Studios, 53-79 Highgate Road, London NW5 1TL Softwire Technology Limited. Registered in England no. 3824658. Registered Office : 13 Station Road, London N3 2SB -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php You are shooting at ants with bazookas ... I don't see a clear path from an immutable DateTime to C# structs in PHP ... This seems like a crazy conversation to me, not only is it crazy, it's a waste of time; I don't see any of the people able to implement it actually implementing it, and I don't see a vote going in favour of the idea if there were an implementation. /me attempts to push the conversation back on track ... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Inconsistency in class definition/usage order
On 04/05/2013 11:39 AM, Madara Uchiha wrote: After I saw this question on Stack Overflow: http://stackoverflow.com/questions/15688642/how-does-a-class-extension-or-interface-work, I realized that the guy was right. Is there an explanation for this, or is it just one of those things that got overlooked? Should something be done? (i.e. enforcing class usage only after definition?) Interfaces must be declared before being referenced. Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Proposal to document all of Zend and PHP API and SAPI layers
Morning All, Further to discussion in IRC this morning, I'd like to propose what amounts to, I guess, a sub-project to properly document everything, starting with everything declared ZEND_API in /Zend. We put a lot of effort into the generation and maintenance of user land documentation, but there are only scraps of information here and there, and then ... the accepted way of working with the source is lxr and lots and lots of reading, which is fine, if you require intricate knowledge of every part of the API you are interacting with, which normally you do not, usually it is enough to know of it's existence, it's usage and implementation is either obvious or irrelevant in the vast majority of cases, should the function prototype be documented. I am also aware of some documentation included in the PHP manual currently, which should also be completed, and included, with all of the API in a searchable format, just like PHP is in userland. Ideally, it would be nice to document the API inline, in source, this means disturbing lots of files, which I'm not keen on, if anyone has any ideas, speak up. The benefit of inline documentation is that if a function is changed the changer has the documentation in their peripheral vision, and the chances of documentation getting stale are less likely than if they have to document using some separate system. I'd like to gauge reaction to this idea, and with it a show of hands, who can actually help ?? Thanks for listening :) Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Inconsistency in class definition/usage order
On 04/05/2013 12:01 PM, Madara Uchiha wrote: That's not the problem, the problem is when you extend a class with a (defined) interface, you can't use the class before it is defined (the class, not the interface). See the examples on the linked question. On Fri, Apr 5, 2013 at 1:48 PM, Joe Watkins krak...@php.net wrote: On 04/05/2013 11:39 AM, Madara Uchiha wrote: After I saw this question on Stack Overflow: http://stackoverflow.com/questions/15688642/how-does-a-class-extension-or-interface-work, I realized that the guy was right. Is there an explanation for this, or is it just one of those things that got overlooked? Should something be done? (i.e. enforcing class usage only after definition?) Interfaces must be declared before being referenced. Joe It is a logical extension, you declare a class to implement an interface it is subject to the same rules as declaring an interface - ... it must be declared before it is used. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal to document all of Zend and PHP API andSAPI layers
On 04/05/2013 01:23 PM, Johannes Schlüter wrote: On Fri, 2013-04-05 at 14:09 +0200, Ferenc Kovacs wrote: I think that it everybody would support that idea, unfortunatelly not many people have the knowledge AND the time to write up that kind of documentation. That is the key part. There's no worse documentation than wrong documentation. Maybe correct documentation only mentioning useless information. I also think that documenting each and every API leads nowhere, but as Ferenc said we have to document the structure and help people tofind what they need. This all takes time, though, and many seem to prefer adding syntax sugar and such things over fixing bugs and documenting things. johannes http://php.net/manual/en/internals2.php This, would be brilliant, if it were anything like complete, and had a searchable API reference, rather than an empty section labelled API reference. What I suggest is that we make an effort to properly define a way to document the source code. Each in our own time we can document the things we interact with, or pick a file whenever we have a spare ten minutes. We might not have a complete set of documentation until version 6 or after, it might even never be complete, much like the PHP manual, but at least it will be on the way, it shouldn't take long for everyone who needs to be aware to become aware, and those that introduce new prototypes or change old ones will know what is expected of them. I shouldn't have said sub-project, what I should have said was, I propose that we define a standard way to document everything internal, if there is a standard, and the people working on the source are (made) aware of it, it is surely no effort at all to maintain it, once the initial work is done, which doesn't have to happen yesterday. Along with documenting source, we should of course complete the write up of internals2 ... Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Proposal to document all of Zend and PHP API and SAPI layers
On 04/05/2013 12:00 PM, Joe Watkins wrote: Morning All, Further to discussion in IRC this morning, I'd like to propose what amounts to, I guess, a sub-project to properly document everything, starting with everything declared ZEND_API in /Zend. We put a lot of effort into the generation and maintenance of user land documentation, but there are only scraps of information here and there, and then ... the accepted way of working with the source is lxr and lots and lots of reading, which is fine, if you require intricate knowledge of every part of the API you are interacting with, which normally you do not, usually it is enough to know of it's existence, it's usage and implementation is either obvious or irrelevant in the vast majority of cases, should the function prototype be documented. I am also aware of some documentation included in the PHP manual currently, which should also be completed, and included, with all of the API in a searchable format, just like PHP is in userland. Ideally, it would be nice to document the API inline, in source, this means disturbing lots of files, which I'm not keen on, if anyone has any ideas, speak up. The benefit of inline documentation is that if a function is changed the changer has the documentation in their peripheral vision, and the chances of documentation getting stale are less likely than if they have to document using some separate system. I'd like to gauge reaction to this idea, and with it a show of hands, who can actually help ?? Thanks for listening :) Joe There seems to be a kind of focus on the things we all know about, understandably. To clarify, I do not mean that we should document hashtable and objects and call it a day, I mean that there is more than 1000 exported ZEND_API or PHPAPI functions in the source code this evening ... here's a list: http://pastebin.com/42xFsNQ0 Drop the scrollbar anywhere random, have you written what you land on more than once ?? Think it's probably worth the time now ?? Surely writing extensions and developing patches and ideas would become much easier if this knowledge was easily accessible and documented, surely you'll get the time back you put in 10 fold ?? Food for thought Nite ... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal to document all of Zend and PHP API and SAPIlayers
On 04/07/2013 12:29 AM, Stas Malyshev wrote: Hi! I'm not really sure how documenting (inline) API functions is really going to be any different to the prototypes we all put on extension functions/methods, or any more time consuming, and I don't see how randomness comes into it. Just listing function args is not enough usually - in the manual, functions that have just protos are almost as good as undocumented. I of course have a bit of skewed point of view - for me, proto is not needed for API function because I can just look up the function definition right in the source. But maybe for somebody it would be helpful. I understand having no time but then these are files we all read and work with, I don't really understand not being able to take an extra 5 minutes here and there when we are already engaged in working with the source. It's not the question of ability, it's the question of a) if it's useful and b) having accepted format for doing it. Stas, It is useful if we define the accepted format and encourage people to include useful information, clearly you can look at a function and know it's prototype immediately, but there's no way you know of all 1000 functions, how on earth do you search for a function you do not even know exists. Assuming you find it, which 800/1000 times you will not, reading a prototype doesn't give you all the information you need, it doesn't give you anything. You always end up having to read the source code, where it could be explained in one/two English sentence(s) which your eyes can process at the same time as reading the prototype itself ... I cannot believe it's taken so much discussion just to get nowhere, all I wanted was for someone to take the lead and say use this standard/format/software, you may/may not edit headers, we will deploy the documentation at http://; ... I give up ... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Class instances counter
On 04/08/2013 09:07 PM, Madara Uchiha wrote: I'm with Morrison, I see no actual use for this. It's cool, but what would you use it for? On Mon, Apr 8, 2013 at 10:47 PM, Levi Morrison morrison.l...@gmail.com wrote: I see little value in having a function that tells me how many objects of any kind I have instantiated. Mostly, I see it as a way to help teach people about assignment of objects works in PHP: $a = new MyClass(); $b = $a; var_dump(get_object_count()); And that's about the sum of how useful I think this is. If it were to be able to narrow it to a specific class then it *might* be a little more useful. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I see some merit in the idea that during development of an application it could be useful to get a profile view of the object store, without affecting those objects or introducing new objects in order to provide that view. There are other run-time use cases, but for me, mostly development and debugging, without being intrusive or having any real impact on the application or object store. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Class instances counter
On 04/09/2013 01:53 AM, David Muir wrote: On 09/04/13 10:29, Joe Watkins wrote: On 04/08/2013 09:07 PM, Madara Uchiha wrote: I'm with Morrison, I see no actual use for this. It's cool, but what would you use it for? On Mon, Apr 8, 2013 at 10:47 PM, Levi Morrison morrison.l...@gmail.com wrote: I see little value in having a function that tells me how many objects of any kind I have instantiated. Mostly, I see it as a way to help teach people about assignment of objects works in PHP: $a = new MyClass(); $b = $a; var_dump(get_object_count()); And that's about the sum of how useful I think this is. If it were to be able to narrow it to a specific class then it *might* be a little more useful. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I see some merit in the idea that during development of an application it could be useful to get a profile view of the object store, without affecting those objects or introducing new objects in order to provide that view. There are other run-time use cases, but for me, mostly development and debugging, without being intrusive or having any real impact on the application or object store. Isn't that what a debugger is for? Cheers, David No, that's shooting at an ant with a bazooka ... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Class instances counter
On 04/09/2013 11:23 AM, Laruence wrote:
if a class need that, it can implement a interface like instance_counter,
which will simply can implement like:
class A {
public static $instance_counter = 0;
public function __construct() { self::$instance_counter++; }
public function __destruct() { self::$instance_counter--; };
public static function get_counter() { return self::$instance_counter; }
}
thanks
On Tue, Apr 9, 2013 at 6:18 PM, Frank Liepert frank.liep...@gmx.de wrote:
Hello internals,
I updated the RFC (https://wiki.php.net/rfc/instance_counter):
- added support for a class name, so the function can be narrowed down to a
specific class
- added use case
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
As mentioned in the RFC, that's an ugly and very intrusive solution,
that is not always practical (you wouldn't want to wrap every internal
class you wish to see the count of).
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PHP 5.5 and APC user cache upgrade path
On 05/09/2013 01:02 PM, Pierre Schmitz wrote: Hi, I am testing PHP 5.5 atm and how we can package it for Arch Linux and provide an upgrade path for users. The RC1 looks pretty solid so far. As the new opcache does not provide a user cache to store custom variables, I would be glad if you could clarify what the best migration from 5.4 would be. * Is APC basically dead and wont support PHP 5.5? * Should APC users switch to opcache and APCu? (with APCu replacing the APC package) For PHP application developers: * Regarding APCu: it provides the old PHP interface function as well as their own apcu_* functions. They are aliases right now. Should application developers think about switching to the apcu_-API as new features will be available only here? Bonus question: * Right now very similar functionality is provided by APCu, XCache, WinCache, YAC etc.. Are there plans to include such functionality inside PHP in future to make application developers life a little easier? At least a common API would be great. There were several bugs in applications as these modules behave a little different regarding return values etc.. Greetings, Pierre Working backwards: I personally don't see a reason for user caches to be in the core, not least of all there are multiple solutions, all suitable and some still maintained. The reason I think it's not really a core feature is that caching of user variables is something that must be explicit in an application, whereas opcode caching and the optimization that opcache performs should be a standard part of the compilation stage of execution, so fits better in the core. There's no merit to the argument that opcache and APC/YAC/whatever could share shm logic: the kind of implementation that APC(u) and opcache need are very different, right now they both have a suitable allocator. Furthermore, YAC implements (a very clever) completely different way of allocating shared memory, which should be tested on it's own merit in the real world before I consider implementing it's allocator in APCu. By default, APCu builds in an APC-compatible manner, emulating the old functions for APC, no change should be required to run legacy code relying on APC. New features, if they are written, will not be included in the APCu codebase, instead, APCu exposes all of it's API to other extensions, which allows any future features to be written and maintained completely separately, which I think to be a better solution as APC is in such heavy use. Very few people are able to helpfully maintain an opcode cache, the idea of including opcache in the core, or one of the ideas/benefits, is that everyone able can concentrate on one solution, implicitly APC will fall by the wayside where opcode caching is concerned. However, it is possible to run APC and opcache side by side by fiddling with ini settings, I can't really say if this is advisable or not, a possibility all the same. I think that's everything ... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.5 and APC user cache upgrade path
On 05/10/2013 08:54 PM, Christopher Jones wrote: On 05/09/2013 05:02 AM, Pierre Schmitz wrote: Hi, I am testing PHP 5.5 atm and how we can package it for Arch Linux and provide an upgrade path for users. The RC1 looks pretty solid so far. As the new opcache does not provide a user cache to store custom variables, I would be glad if you could clarify what the best migration from 5.4 would be. * Is APC basically dead and wont support PHP 5.5? From the lack of APC activity and from comments Rasmus has made in the bugs (e.g. [1]) this is a safe assumption. * Should APC users switch to opcache and APCu? (with APCu replacing the APC package) OPcache is definitely the opcode cache solution for PHP 5.5 For user data caches, there are a number of alternatives, as you noted. During this initial transition phase it isn't clear what the directions of each solution will be. It isn't clear that there will be one dominant solution. I'll leave it to Laruence and Joe to state their cases for world domination of YAC and APCu, respectively. Chris [1] https://bugs.php.net/bug.php?id=64625 For PHP application developers: * Regarding APCu: it provides the old PHP interface function as well as their own apcu_* functions. They are aliases right now. Should application developers think about switching to the apcu_-API as new features will be available only here? Bonus question: * Right now very similar functionality is provided by APCu, XCache, WinCache, YAC etc.. Are there plans to include such functionality inside PHP in future to make application developers life a little easier? At least a common API would be great. There were several bugs in applications as these modules behave a little different regarding return values etc.. Greetings, Pierre I am still waiting to see articles/blogs and the consensus on YAC. YAC has a much higher throughput, if you are able to write the software to manage it and have the hardware to put up with it, then you should attempt to take advantage. I'm not really sure if most have either the ability or the hardware; or if it's good thing to aspire to having either. Think about what is the advantage of using a cache, why does it create a more stable experience even when we do have the hardware to SELECT or request everything we need from wherever it comes ... it's because you are benefiting from the fact that the cache doesn't just make PHP faster because the opcodes Zend executes are less than fetching an un-cached result, but also, and mostly because it takes the pressure of MySQL, or your network connection, or your IO scheduler, or all of the above if you are clever about it. The problem with having no locking comes on a loaded server when many clients are attempting to read from an expired entry (this is the point where a cache has the effect of a stable service even under load where items have short ttls) the cache so they can avoid some significant work. In that situation, APC (and most others I assume) has a lock acquired by the first writer that cannot be obtained by a reader while it is held, the writer finishes (populating cache) the reader acquires the lock and is able to read that cached item, as are other readers. Good, only one context done what the cache is there to avoid. With YAC, or any solution that does not employ entry level locking, many contexts will end up doing the work, because a reader cannot see what isn't finished writing and will not implicitly wait for a write to complete. Something to think about ... Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.5 and APC user cache upgrade path
On 05/11/2013 11:10 AM, Joe Watkins wrote: On 05/10/2013 08:54 PM, Christopher Jones wrote: On 05/09/2013 05:02 AM, Pierre Schmitz wrote: Hi, I am testing PHP 5.5 atm and how we can package it for Arch Linux and provide an upgrade path for users. The RC1 looks pretty solid so far. As the new opcache does not provide a user cache to store custom variables, I would be glad if you could clarify what the best migration from 5.4 would be. * Is APC basically dead and wont support PHP 5.5? From the lack of APC activity and from comments Rasmus has made in the bugs (e.g. [1]) this is a safe assumption. * Should APC users switch to opcache and APCu? (with APCu replacing the APC package) OPcache is definitely the opcode cache solution for PHP 5.5 For user data caches, there are a number of alternatives, as you noted. During this initial transition phase it isn't clear what the directions of each solution will be. It isn't clear that there will be one dominant solution. I'll leave it to Laruence and Joe to state their cases for world domination of YAC and APCu, respectively. Chris [1] https://bugs.php.net/bug.php?id=64625 For PHP application developers: * Regarding APCu: it provides the old PHP interface function as well as their own apcu_* functions. They are aliases right now. Should application developers think about switching to the apcu_-API as new features will be available only here? Bonus question: * Right now very similar functionality is provided by APCu, XCache, WinCache, YAC etc.. Are there plans to include such functionality inside PHP in future to make application developers life a little easier? At least a common API would be great. There were several bugs in applications as these modules behave a little different regarding return values etc.. Greetings, Pierre I am still waiting to see articles/blogs and the consensus on YAC. YAC has a much higher throughput, if you are able to write the software to manage it and have the hardware to put up with it, then you should attempt to take advantage. I'm not really sure if most have either the ability or the hardware; or if it's good thing to aspire to having either. Think about what is the advantage of using a cache, why does it create a more stable experience even when we do have the hardware to SELECT or request everything we need from wherever it comes ... it's because you are benefiting from the fact that the cache doesn't just make PHP faster because the opcodes Zend executes are less than fetching an un-cached result, but also, and mostly because it takes the pressure of MySQL, or your network connection, or your IO scheduler, or all of the above if you are clever about it. The problem with having no locking comes on a loaded server when many clients are attempting to read from an expired entry (this is the point where a cache has the effect of a stable service even under load where items have short ttls) the cache so they can avoid some significant work. In that situation, APC (and most others I assume) has a lock acquired by the first writer that cannot be obtained by a reader while it is held, the writer finishes (populating cache) the reader acquires the lock and is able to read that cached item, as are other readers. Good, only one context done what the cache is there to avoid. With YAC, or any solution that does not employ entry level locking, many contexts will end up doing the work, because a reader cannot see what isn't finished writing and will not implicitly wait for a write to complete. Something to think about ... Joe Not entry level, cache level locking. Entry level I tested and it just makes the software more complex and work harder for no improvement evident over read/write locks, and no significant benefit over apcu's implementation of standard locking (used where rwlocks are disabled explicitly) ... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC: Anonymous Classes
Morning All, https://wiki.php.net/rfc/anonymous_classes I'd like to hear thoughts regarding the addition of anonymous classes, patch included. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: RFC: Anonymous Classes
On 09/23/2013 07:39 AM, Joe Watkins wrote:
Morning All,
https://wiki.php.net/rfc/anonymous_classes
I'd like to hear thoughts regarding the addition of anonymous
classes, patch included.
Cheers
Joe
Thanks chaps ...
I am having a hard time picturing a real-world use-case for this.
-Rasmus
I think since you wrote that quite a few decent use cases have been
suggested, testing, MVC (that wasn't on internals), throw away/private
implementation of interfaces or abstracts.
It has such a wide range of uses, I didn't think it necessary to point
them out, as others have mentioned it's an established OO pattern to use
objects of an anonymous class.
I'd rather go for a `new BaseType` syntax, though:
$subject-attach(new SplObserver() {
function update(SplSubject $s) {
printf(Got update from: %s\n $subject);
}
);
Using class_name_reference in place of T_CLASS causes a conflict with
existing syntax, which is the reason T_CLASS is accepted, additionally,
using class is nicer shorthand for new stdClass {}.
With that in mind, I haven't tried moving the arguments, this:
(new class {definition} (arguments))-method()
seems more natural/sensible than:
(new class(arguments) {definition})-method()
new class() just feels a bit wrong ...
Frankly, constructors are not part of any interface. Besides a
constructor
is totally useless in an anonymous class as it will never be called
after
the object is created.
The examples in the constructor were not meant as use cases but to show
the syntax of use.
If you are using an anonymous class to implement an interface then a
constructor may not be required, however, removing the ability to
declare a constructor is restrictive an unnecessary.
Cheers
Joe
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Anonymous Classes
On 09/23/2013 02:43 PM, Lars Strojny wrote: Hi Joe, what about serialization for those classes? cu, Lars Am 23.09.2013 um 08:39 schrieb Joe Watkins krak...@php.net: Morning All, https://wiki.php.net/rfc/anonymous_classes I'd like to hear thoughts regarding the addition of anonymous classes, patch included. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Same as any other object; what you are creating is normal classes without a (declared) name, nothing about the objects functionality has differs from an object of a named class. Cheers -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: RFC: Anonymous Classes
On 09/23/2013 07:39 AM, Joe Watkins wrote: Morning All, https://wiki.php.net/rfc/anonymous_classes I'd like to hear thoughts regarding the addition of anonymous classes, patch included. Cheers Joe Serialization: As I have said, serialization does work, and unserialization does work ... Classes do have unique names, so as long as the entry is present upon unserialize you will get the object you expect ... if the entry is not present unserialization will fail silently. The same kind of thing can happen where you have declared a class based on some predicate, whose value has changed upon unserialize and so the entry is not present ... I'm not sure it is necessary to force any particular behaviour for serialization, it depends entirely on the application whether or not the entry is present upon serialization, it should be left down to the programmer. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Anonymous Classes
On 09/24/2013 01:30 PM, Kristopher wrote: On Tue, Sep 24, 2013 at 8:25 AM, Terence Copestake terence.copest...@gmail.com wrote: Playing devil's advocate here, could this feature make the language more expressive? Take for example an API where you'd typically wrap a method call in try/catch blocks to handle the various outcomes e.g. a user login, you'd maybe have a UserDisabled exception, a UserAlreadyLoggedIn exception, a UserPasswordIncorrect exception, etc. With the addition of this syntactic sugar, the method could instead accept an anonymous class with a onDisabled, onLoggedIn, onPasswordIncorrect methods. Perhaps it would also have a performance benefit over cascading through catch blocks? Though someone else would have to confirm that. Why wouldn't you want this to a concrete, real class? I don't see the benefit, in your example, of doing an anonymous class vs defining an actual class and passing that in as the handler. People express themselves in different ways ... It is mostly just about expressing the same thing in different ways, we can find justification for it when pushed, because we are being pushed ... I'm a bit confused by this idea that every RFC has to be accompanied by a long list of use cases, expressing ideas that cannot conceivably be expressed any other way ... that doesn't make any sense, you can do almost anything a bunch of ways ... I think enough use cases have been provided, it's an established, widely used, part of OO elsewhere: The _only_ question is should we have it, which is incidentally the reason the RFC was sparse in the first place ... Cheers -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Anonymous Classes
On 09/24/2013 09:50 PM, Robert Stoll wrote: -Original Message- From: Joe Watkins [mailto:krak...@php.net] Sent: Tuesday, September 24, 2013 10:08 PM To: internals@lists.php.net; Kristopher Subject: Re: [PHP-DEV] RFC: Anonymous Classes On 09/24/2013 01:30 PM, Kristopher wrote: On Tue, Sep 24, 2013 at 8:25 AM, Terence Copestake terence.copest...@gmail.com wrote: Playing devil's advocate here, could this feature make the language more expressive? Take for example an API where you'd typically wrap a method call in try/catch blocks to handle the various outcomes e.g. a user login, you'd maybe have a UserDisabled exception, a UserAlreadyLoggedIn exception, a UserPasswordIncorrect exception, etc. With the addition of this syntactic sugar, the method could instead accept an anonymous class with a onDisabled, onLoggedIn, onPasswordIncorrect methods. Perhaps it would also have a performance benefit over cascading through catch blocks? Though someone else would have to confirm that. Why wouldn't you want this to a concrete, real class? I don't see the benefit, in your example, of doing an anonymous class vs defining an actual class and passing that in as the handler. People express themselves in different ways ... It is mostly just about expressing the same thing in different ways, we can find justification for it when pushed, because we are being pushed ... I'm a bit confused by this idea that every RFC has to be accompanied by a long list of use cases, expressing ideas that cannot conceivably be expressed any other way ... that doesn't make any sense, you can do almost anything a bunch of ways ... [Robert Stoll] Every syntactic sugar means more overhead for maintaining PHP and therefore I think it is a good idea to review the idea and ask for real use cases. However, real use cases were presented in this case which makes sense IMO and thus I think the RFC should be accepted. I am not a fan of anonymous classes with lot of logic in it, but small anonymous classes can be very useful as presented before. One additional use case I can think of is a composition where it is not exposed to the outside of the class. An anonymous class extending a small interface or extending an abstract class with only a few methods seems to be the suitable candidate here IMO. If PHP would support inner classes I would probably prefer a private inner class when the anonymous class starts to hold to much logic. Cheers, Robert I think enough use cases have been provided, it's an established, widely used, part of OO elsewhere: The _only_ question is should we have it, which is incidentally the reason the RFC was sparse in the first place ... Cheers -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I think sugar can have overhead ... but did you see the patch ?? In this case, there's not really any use cases you can give that absolutely require anonymous classes, it's personal preference. I'm glad that others found examples of use cases they can give, as that seems required ... I just don't really see the sense in saying that's why we should have it, because absolutely anything suggested can be achieved without it ... It's too simplistic, and wrong, to say that all RFC's require the exact same treatment; they clearly do not. If the idea is simple then the patch, and ideally the process that gets it merged should also be simple. Thanks for all the input, everyone, hope this isn't misunderstood ... Inner classes can be done, I mentioned this in the RFC, there's a patch to play with, I've not really given it a bunch of thought, so no draft yet even, I'm just saying, it's a possibility ... Cheers -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Anonymous Classes
On 09/25/2013 09:59 AM, Terence Copestake wrote: I'm growing to like the idea myself. It may create new opportunities for bad practices, but I don't think it's the concern of internals to police how people may or may not use a feature. There are also I think a few things that would need to be addressed before this would be ready for the real world. For example: 1) As hinted at previously, the use statement. Doing this per-method as suggested would be less ambiguous than applying to the whole class - and would also prevent pollution. 2) Transparency between an anonymous class and the class in which it is defined (if any). One thing I found very restrictive about closures back in 5.3 was the lack of $this support. I can imagine that missing functionality being similarly restrictive for these new anonymous classes. Obviously $this itself will be reserved for use by the anonymous class, which means there would need to be an alternative. Passing in a variable is one thing, but as it stands the anon class would then only have public access. Something like $class with similar behaviour to $this could be an option. In Java I believe anonymous classes have the same scope as the method in which they're defined. Would something like this or similar be feasible and permissible in PHP? 1) Anonymous classes in PHP would support a constructor, so I don't see the need for use to be utilized here, it would just clutter declarations and the patch. 2) Again, constructors can be used, and is less confusing than introducing a new variable, but I'm open to persuasion if the idea is liked in general ... Well, it's likely possible to introduce a shared kind of scope, but I don't really think it's necessary, for the same reasons as 1) and 2). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Anonymous Classes
On 09/25/2013 02:02 PM, Terence Copestake wrote:
1) Anonymous classes in PHP would support a constructor, so I don't see
the need for use to be utilized here, it would just clutter declarations
and the patch.
This works, but it's more effort for the programmer and arguably just
moving the clutter from the declaration to the constructor.
e.g.
(new class ...
protected $value;
public function __construct($value)
{
$this-value = $value;
}
public function doSomething()
{
echo $this-value;
})($val)
vs.
(new class ...
public function doSomething() use ($val)
{
echo $val;
})
It gets even uglier for passing by reference.
2) Again, constructors can be used, and is less confusing than introducing
a new variable, but I'm open to persuasion if the idea is liked in general
...
This is fine when working with only a handful of values, but what about
needing access to a large number of values? What about making (especially
protected) method calls within the anon class?
Along the same vein, why did we even bother having use and $this for
closures, if you can after all just pass everything as arguments?
If there are realistic and elegant alternative solutions to the problems
presented, that's fair enough. Rejecting something because it's not as
simple to implement and you can hack around it in user code anyway...
that's a dangerous way to go about your business.
The first example doesn't make good sense:
(new class ...
protected $value;
public function __construct($value)
{
$this-value = $value;
}
public function doSomething()
{
echo $this-value;
})($val)
If $value is protected then how are you passing it in from outside as $val ?
If your anonymous class needs access to protected methods (which in turn
might want to read private members) then there's already an established
way of declaring that:
?php
class Outer {
private $dice;
public function __construct($dice) {
$this-dice = $dice;
}
protected function protectedMethod() {
return $this-dice;
}
public function publicMethod() {
return new class extends Outer {
public function forwardToProtectedMethod() {
$this-protectedMethod();
}
}($this);
}
}
var_dump((new Outer($_SERVER))-publicMethod());
?
This works now, as you expect it too ... not elegant enough ?? you don't
think use() everywhere might be a little bit much ??
Lets try to keep it as simple as possible, I think ...
Cheers
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Anonymous Classes
On 09/26/2013 01:50 AM, Pierre Joye wrote: hi! On Sun, Sep 22, 2013 at 11:39 PM, Joe Watkins krak...@php.net wrote: Morning All, https://wiki.php.net/rfc/anonymous_classes I'd like to hear thoughts regarding the addition of anonymous classes, patch included. Thanks for your proposal and work. If you did not yet update your RFC I would suggest to do so, it is about the right time. Adding already answered questions, more use cases (read a couple of good ones in this thread). It will help to end in circular discussions or arguing. Cheers, Pierre Thanks ... I have made many changes to the RFC and patch since the beginning of this discussion ... It might be useful if you could all now go back to the RFC for another read, point out anything I've left unclear at this point. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Anonymous Classes
On 09/26/2013 10:28 AM, Nicolas Grekas wrote:
I think what Terence was talking about is more like this:
class A
{
}
class AProxifier
{
protected function protectedMethod() {...}
function getAProxy()
{
return new class extends A { /* How do you call
AProxifier-protectedMethod() here? */ };
}
}
This is possible with anonymous functions, that's a big feature of PHP5.4.
And for the same reasons might be expected here too?
I don't have the answer, just raising the point.
(new class ...
protected $value;
public function __construct($value)
{
$this-value = $value;
}
public function doSomething()
{
echo $this-value;
})($val)
Btw, I can't get used to ($val) beeing at the end of the declaration. I
feel it very confusing.
Nicolas
If you need access to the methods in AProxifier then why does the
anonymous class extend A, you should extend AProxifier as you would with
any other class.
class A {
public function __construct(/* ctor args*/) {
/* ctor statements */
}
protected function protectedMethod() {
/* protected method */
}
public function getProxy() {
return new class extends A {
/* proxy stuff */
} (/* ctor args */);
}
}
For the following reasons the syntax should remain as it is:
It keeps the number of conflicts in the parser the same (%expect 3)
It is consistent with anonymous function calls - args after definition
...
It does not make sense to pass arguments to a constructor that might
not yet be declared
It is the simplest syntax to implement .. and so less margin for error,
easier to maintain in the future ...
Cheers
Joe
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Anonymous Classes
On 09/26/2013 11:38 AM, Lazare Inepologlou wrote: 2013/9/26 Joe Watkins krak...@php.net On 09/26/2013 01:50 AM, Pierre Joye wrote: hi! On Sun, Sep 22, 2013 at 11:39 PM, Joe Watkins krak...@php.net wrote: Morning All, https://wiki.php.net/rfc/**anonymous_classeshttps://wiki.php.net/rfc/anonymous_classes I'd like to hear thoughts regarding the addition of anonymous classes, patch included. Thanks for your proposal and work. If you did not yet update your RFC I would suggest to do so, it is about the right time. Adding already answered questions, more use cases (read a couple of good ones in this thread). It will help to end in circular discussions or arguing. Cheers, Pierre Thanks ... I have made many changes to the RFC and patch since the beginning of this discussion ... It might be useful if you could all now go back to the RFC for another read, point out anything I've left unclear at this point. Thank you for the updates. There is a possible mistake in the Inheritance section. The $this-data array is passed by value to the constructor of the anonymous class. Once there is any change to the initial array, the two classes will contain different data. Which leads us to the point that this pattern is not enough to do what you wanted to without changing the original constructor. This is usually out of the question, as one such change will also change the outer class' behavior. We don't have to reinvent the wheel here. The solution is some kind of use clause that works similarly to the anonymous functions. Cheers, Lazare INEPOLOGLOU Ingénieur Logiciel We don't have to re-invent the wheel, pass by reference if that's what you want to do, the example didn't make any changes to data, tests included with the patch do, and it, of course, works ... Cheers -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Anonymous Classes
On 09/26/2013 01:00 PM, Pierre Joye wrote: On Sep 26, 2013 10:35 AM, Joe Watkins krak...@php.net wrote: Thanks ... I have made many changes to the RFC and patch since the beginning of this discussion ... It might be useful if you could all now go back to the RFC for another read, point out anything I've left unclear at this point. I saw your changes :) I would add more use cases if possible, the more the better. My feeling is that some does not see yet a good use case. It is a known pattern is sometimes not a good enough argument. Cheers, Ok, I included just about all the information on use cases that is obvious or has been discussed, so I think we got use cases covered now, right ?? See a good one yet ?? Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Anonymous Classes
On 09/27/2013 10:42 AM, Terence Copestake wrote:
Just ... Isn't that something, we can simply keep out of _this_ RFC and
create separate RFC(s) for it later? Like it was done with $this in
Closures?
Do we want another 5.3/5.4 closures situation? Why not iron it all out to
begin with?
If there's a sound, logical reason not to implement the functionality in
question, that's fine. I don't understand why we keep reiterating keeping
it simple as if that is in itself an excuse to, in effect, rush it through
half-baked.
In the RFC, there are use cases citing languages like Java to support this
- a language in which anonymous classes and the methods in which they're
defined, share scope. Can we then say, let's do it because it's useful in
other languages, but let's not offer the functionality that those languages
do? Also, my proposed use case being practical in the real world hangs on
resolving the scope issue, as I struggle to look past the difficulties I'd
have trying to use this in my code when it's unable to interact with the
object instance in which it is being used.
That's all I'll say on that now; it's becoming circular.
If you want to update my use case in the RFC, here's an expanded example of
what I imagine. I've lifted code from the documentation for Sentry* and
below it, written an alternative anonymous class API example.
* I have no affiliation with Sentry / other membership packages are
available.
try
{
// Find the user using the user id
$user = Sentry::findUserById(1);
// Log the user in
Sentry::login($user, false);
}
catch (Cartalyst\Sentry\Users\LoginRequiredException $e)
{
echo 'Login field is required.';
}
catch (Cartalyst\Sentry\Users\UserNotActivatedException $e)
{
echo 'User not activated.';
}
catch (Cartalyst\Sentry\Users\UserNotFoundException $e)
{
echo 'User not found.';
}
// Following is only needed if throttle is enabled
catch (Cartalyst\Sentry\Throttling\UserSuspendedException $e)
{
$time = $throttle-getSuspensionTime();
echo User is suspended for [$time] minutes.;
}
catch (Cartalyst\Sentry\Throttling\UserBannedException $e)
{
echo 'User is banned.';
}
becomes:
$user = Sentry::findUserById(
1,
(new class implements Cartalyst\Sentry\LoginHandlerInterface
{
public function onLoginRequired()
{
echo 'Login field is required.';
}
public function onUserNotActivated()
{
echo 'User not activated.';
}
public function onUserNotFound()
{
echo 'User not found.';
}
// Following is only needed if throttle is enabled
public function onUserSuspended()
{
$time = $throttle-getSuspensionTime();
echo User is suspended for [$time] minutes.;
}
public function onUserBanned()
{
echo 'User is banned.';
}
public function onSuccess()
{
// Log the user in
Sentry::login($user, false);
}
})
);
Because in your rush to get the ironing done, you are burning clothes,
putting big holes in them, and are going to be left with no clothes
without big holes in them ...
What we are introducing here is anonymous classes, not nested classes:
class Outer {
class Inner {
class Again {
class Inner {
}
}
}
}
This requires a way to resolve complex scope issues, these are formally
nested classes, as yet unsupported, formally nested classes might also
look like:
class Outer {
class Inner {
protected class Again {
private class Inner {
}
}
}
}
I appreciate that the only way to do this right now is with anonymous
classes, but if you are doing it with anonymous classes then you,
clearly, do not care about scope.
The solution to the resolution of nested class scope issues does not
belong as part of the RFC introducing anonymous classes but the RFC
introducing nested classes, which is as yet unwritten, but totally doable.
+1000 on keeping this for another RFC, because it's part of another
problem ...
Cheers
Joe
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC: Draft: Nested Classes
Hi All, I'd like to RFC on Nested Classes (Draft): https://wiki.php.net/rfc/nested_classes There's been a little bit of discussion already about it, in the usual places mostly, but also while considering anonymous classes on the lists ... time to make it public I guess ... Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Draft: Nested Classes
On 10/01/2013 12:16 PM, Ferenc Kovacs wrote:
On Sun, Sep 29, 2013 at 11:12 PM, Joe Watkins krak...@php.net
wrote:
Hi All,
I'd like to RFC on Nested Classes (Draft):
https://wiki.php.net/rfc/**nested_classeshttps://wiki.php.net/rfc/nested_classes
There's been a little bit of discussion already about it, in the usual
places mostly, but also while considering anonymous classes on the
lists ... time to make it public I guess ...
Cheers Joe
-- PHP Internals - PHP Runtime Development Mailing List To
unsubscribe, visit: http://www.php.net/unsub.php
Hi Joe,
I really like the idea, as it is a recurring problem that you create
a library/package, what you want others to use, but there are some
parts of it, which you want to keep as a blackbox to your users, so
you can change it in the future, without breaking their code.
Currently if you want hard guarantees your only option is to keep
that kind of code in private functions, and if you put that into
logically separated classes, your only option is to use docblock
comments like the @api to hint that which parts are intended for
consumption, but sadly nobody really follows that. So I would really
like the idea of having classes which can only be accessed from that
specific component, but sadly we don't have real packages in php
with package level visibility as that could also solve this problem.
Having nested classes could be still really useful in this
scenario, so I'm +1 on this feature, but there are a couple of
questions I would like to see answered:
1. Would there be reflection support for this feature (currently you
can access private methods/properties through Reflection, I think it
would make sense to be able to do the same with the nested classes).
2. Would it be possible to serialize/unserialize a class
referencing an instance of a nested class without losing the
information it holds? 3. What happens when a nested class with the
same name is used in two separate class?
What do you think?
HI Tyrael,
1) Reflection will have the same kind of access to nested classes as
it does to normal classes
2) Same goes for serialization, these are normal classes declared in
the pseudo namespace of the declaring class
3) Because of how classes are named, this cannot reasonably occur
My thoughts have somewhat moved on from the version I have RFC'd.
Apparently the version I have RFC'd is too basic, we want more support.
https://github.com/krakjoe/php-src/compare/anon_class_objects...nesting_complex
The branch above is the work on a more complete support of the idea.
https://github.com/krakjoe/php-src/blob/2275e89c6c21c2866dd031915c37838cb31b68c0/Zend/tests/nested/100.phpt
?php
class foo
{
:protected interface iface {
public function mthd();
}
:protected abstract class my implements foo\iface
{
public function mthd() {
return $this;
}
}
/* I'm private */
:private class baz
{
/* I'm very private */
:private class qux extends foo\my
{
public function __construct() {
$this-bar = new foo\bar();
}
}
/* I'm useful */
public function __construct() {
$this-qux = new foo\baz\qux();
}
}
/* I'm protected */
:protected class bar
{
public function __construct() {
}
}
public function __construct() {
$this-bar = new foo\bar();
$this-baz = new foo\baz();
}
}
var_dump(new foo());
?
The above code, taken from the first test, shows the kind of support
we might have as an alternative to the simple version of nesting I RFC'd.
private: you cannot use outside of the super class
protected: you must share a scope in common with the class to use it
public: you can access the class from anywhere
There are a few problems with this, it's simple enough to enforce
these rules on ZEND_NEW ZEND_ADD_INTERFACE ZEND_ADD_TRAIT, however,
where ZEND_FETCH_CLASS is used things are a little more complex, we
don't have enough information, or don't pass it anyway to detect the
scope requesting the FETCH_CLASS, I'm sure this isn't an insurmountable
problem, but I'm sure that anything we do in ZEND_FETCH_CLASS is going
to be felt, a lot, so it had better be minimal ...
Note that the syntax above with the colons in front of the class
names are just circumventing a problem I've not been able to overcome in
the parser, I'm assured it's possible to do without it.
If we want any support at all, these are the options we have; the
version I RFC'd, where the scope of the class is implicit in the
location of the declaration, or we try to propagate support for the
access modifiers throughout the VM as in the second branch.
I think the latter
Re: [PHP-DEV] RFC: Anonymous Classes
On 10/01/2013 01:19 PM, Terence Copestake wrote:
On Fri, Sep 27, 2013 at 11:26 AM, Joe Watkins krak...@php.net wrote:
On 09/27/2013 10:42 AM, Terence Copestake wrote:
Just ... Isn't that something, we can simply keep out of _this_ RFC and
create separate RFC(s) for it later? Like it was done with $this in
Closures?
Do we want another 5.3/5.4 closures situation? Why not iron it all out to
begin with?
If there's a sound, logical reason not to implement the functionality in
question, that's fine. I don't understand why we keep reiterating keeping
it simple as if that is in itself an excuse to, in effect, rush it
through
half-baked.
In the RFC, there are use cases citing languages like Java to support this
- a language in which anonymous classes and the methods in which they're
defined, share scope. Can we then say, let's do it because it's useful in
other languages, but let's not offer the functionality that those
languages
do? Also, my proposed use case being practical in the real world hangs on
resolving the scope issue, as I struggle to look past the difficulties I'd
have trying to use this in my code when it's unable to interact with the
object instance in which it is being used.
That's all I'll say on that now; it's becoming circular.
If you want to update my use case in the RFC, here's an expanded example
of
what I imagine. I've lifted code from the documentation for Sentry* and
below it, written an alternative anonymous class API example.
* I have no affiliation with Sentry / other membership packages are
available.
try
{
// Find the user using the user id
$user = Sentry::findUserById(1);
// Log the user in
Sentry::login($user, false);
}
catch (Cartalyst\Sentry\Users\**LoginRequiredException $e)
{
echo 'Login field is required.';
}
catch (Cartalyst\Sentry\Users\**UserNotActivatedException $e)
{
echo 'User not activated.';
}
catch (Cartalyst\Sentry\Users\**UserNotFoundException $e)
{
echo 'User not found.';
}
// Following is only needed if throttle is enabled
catch (Cartalyst\Sentry\Throttling\**UserSuspendedException $e)
{
$time = $throttle-getSuspensionTime()**;
echo User is suspended for [$time] minutes.;
}
catch (Cartalyst\Sentry\Throttling\**UserBannedException $e)
{
echo 'User is banned.';
}
becomes:
$user = Sentry::findUserById(
1,
(new class implements Cartalyst\Sentry\**LoginHandlerInterface
{
public function onLoginRequired()
{
echo 'Login field is required.';
}
public function onUserNotActivated()
{
echo 'User not activated.';
}
public function onUserNotFound()
{
echo 'User not found.';
}
// Following is only needed if throttle is enabled
public function onUserSuspended()
{
$time = $throttle-getSuspensionTime()**;
echo User is suspended for [$time] minutes.;
}
public function onUserBanned()
{
echo 'User is banned.';
}
public function onSuccess()
{
// Log the user in
Sentry::login($user, false);
}
})
);
Because in your rush to get the ironing done, you are burning clothes,
putting big holes in them, and are going to be left with no clothes without
big holes in them ...
What we are introducing here is anonymous classes, not nested classes:
class Outer {
class Inner {
class Again {
class Inner {
}
}
}
}
This requires a way to resolve complex scope issues, these are formally
nested classes, as yet unsupported, formally nested classes might also look
like:
class Outer {
class Inner {
protected class Again {
private class Inner {
}
}
}
}
I appreciate that the only way to do this right now is with anonymous
classes, but if you are doing it with anonymous classes then you, clearly,
do not care about scope.
The solution to the resolution of nested class scope issues does not
belong as part of the RFC introducing anonymous classes but the RFC
introducing nested classes, which is as yet unwritten, but totally doable.
+1000 on keeping this for another RFC, because it's part of another
problem ...
Cheers
Joe
I think you've become confused with my intentions here. My example is not
of the internal workings of an API and I'm certainly not talking about
nested classes. My example is of a third party using an API from the
outside. Currently, the way the package given in my example communicates is
by using exceptions to signal what happened. What I'm demonstrating is that
a more expressive way to do this would be to instead pass a callback
anonymous class to handle those outcomes, rather than having a series of
catch blocks.
I only think it would be good to actually discuss (i.e
Re: [PHP-DEV] RFC: Draft: Nested Classes
On 10/04/2013 12:11 PM, Clint Priest wrote:
On 9/29/2013 4:12 PM, Joe Watkins wrote:
https://wiki.php.net/rfc/nested_classes
One issue I see from a maintenance perspective (of the user of this
feature) is that you could end up having files with dozens of classes,
it would be nice if it dot have to be embedded within the class but
rather kept in a separate file.
Alternatives:
foo.php
namespace s;
class foo {
}
bar.php
namespace s;
private class bar {
public for s\foo;
}
/* This has the advantage of access control being kept in the
declaring class (bar) */
foo.php
namespace s;
class foo {
use s\foo as private;
}
bar.php
namespace s;
private class bar {
}
/* This has no real advantage over the prior alternative but just
another possibility */
Ultimately I like the feature, even if it could only be done in a
nested fashion. Given the original proposal, could something like
this work?
bar.php:
abstract class abs_bar {
}
foo.php:
class foo {
private bar extends abs_bar {
}
}
-Clint
Morning,
I've heard the multiple files thing several times now ... while I
like the idea, I think it might just confuse users, what would a
namespace be if classes supported this I think let's not stand on
the toes of namespaces, it also goes contrary to the best use case of
the feature, if we leave it out then it cannot be abused or cause
confusion ...
This simplifies the use of classes with a modified visibility I
think, because we can define rules that are class-centric:
private class: available to any class in the same virtual namespace
protected class: available to any class in the same global class
public class: available to any class
Note: (class includes interfaces, traits, and abstracts, they can
all be nested and declared with modified visibility too)
private static method: available to any class is the same
virtual namespace
protected static method: available to any class in the same
global class
public static method: available to any class
I don't think we should touch the functionality of normal method
calls or member access, though static member access may need adjustment ...
I've had a degree of success getting access to everything from
anywhere, so I'm open to well thought out ideas there ...
This is the clearest definition that I can think up and make work
right now, it means that from the level of the global class outward to
the namespace, all the way to the global scope, nothing is touched,
everything is still the same. The only changes, and the only place those
changes have any impact are at the level of the class, outside of a
global class it's operation and inheritance as usual. From the global or
namespace perspective a public nested class is just a namespaced class,
the rest, it is not even aware of.
Ultimately, I think your last example will be the solution to large
projects utilizing nested classes, where they feel they must cross the
file boundary: normal inheritance where the final/concrete classes are
nested, sharing among them common public abstracts/interfaces from some
other scope/namespace. This more or less keeps intact the black box,
since access to abstracts/interfaces directly is not useful, and the
final implementations are kept private by nesting.
There appears to be a feeling that things are moving a bit too fast
for 5.6, I feel obliged to delay this and anonymous classes until 5.7,
if anyone has any input, I'll be opening the vote on monday or tuesday
next week for anonymous classes, I'm considering delaying both until 5.7 ...
Cheers
Joe
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Draft: Nested Classes
On 10/04/2013 05:32 PM, Robert Stoll wrote: Heya, Just to be sure, this feature would not allow nested classes in functions, right? Cheers, Robert -Original Message- From: Joe Watkins [mailto:krak...@php.net] Sent: Sunday, September 29, 2013 11:12 PM To: internals@lists.php.net Subject: [PHP-DEV] RFC: Draft: Nested Classes Hi All, I'd like to RFC on Nested Classes (Draft): https://wiki.php.net/rfc/nested_classes There's been a little bit of discussion already about it, in the usual places mostly, but also while considering anonymous classes on the lists ... time to make it public I guess ... Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php No, nested classes implies a class within a class ... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Vote: Anonymous Classes
Morning Chaps, I have opened the vote on anonymous classes, following on from conversations had in IRC, we have the option to postpone this until 5.7 ... Cheers -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Vote: Anonymous Classes
On 10/07/2013 08:09 AM, Pierre Joye wrote: hi, On Mon, Oct 7, 2013 at 8:29 AM, Joe Watkins krak...@php.net wrote: Morning Chaps, I have opened the vote on anonymous classes, following on from conversations had in IRC, we have the option to postpone this until 5.7 ... Also I do not always follow IRC discussions. What is the reasoning behind post pone this feature to an hypothetical 5.7? Or why not 5.6? Cheers, Morning Pierre, 5.6 remains an option ... I brought it up in IRC the other day and someone, I forget who, but recognized them at the time, said they'd rather see it in 5.7, then a few people joined in the discussion and I couldn't really argue with their reasoning. The main point was that even a simple patch can have a destabilizing effect, and we've already merged several simple patches into 5.6. I think it's a bit early to call time on 5.6 features, and I think features like this require quite some time for adoption and should be out as quickly as possible ... I don't really know what is best ... Moved to voting bit .. Sorry mike, thanks for posting link :) Cheers -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Vote: Anonymous Classes
On 10/07/2013 08:48 AM, Pierre Joye wrote: On Mon, Oct 7, 2013 at 9:38 AM, Joe Watkins krak...@php.net wrote: 5.6 remains an option ... I brought it up in IRC the other day and someone, I forget who, but recognized them at the time, said they'd rather see it in 5.7, then a few people joined in the discussion and I couldn't really argue with their reasoning. The main point was that even a simple patch can have a destabilizing effect, and we've already merged several simple patches into 5.6. I think it's a bit early to call time on 5.6 features, It is not and we should begin soon to branch 5.6 and go with the milestones planing to get it out in June. and I think features like this require quite some time for adoption and should be out as quickly as possible ... I agree. Cheers, Hi Pierre, Re: It is not ... You seem to agree :) If we should do it _soon_, and not _now_, then it is a _bit_ too early isn't it ?? The end of 2015 is very far away from the perspective of the PHP user; they are not engaged in learning what will be available in two years time, look at adoption rates. The anonymous classes patch is actually simple, I can't imagine that it will have a profound effect on the things around it ... Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Vote: Anonymous Classes
On 10/07/2013 10:46 AM, Nikita Popov wrote: On Mon, Oct 7, 2013 at 8:29 AM, Joe Watkins krak...@php.net wrote: Morning Chaps, I have opened the vote on anonymous classes, following on from conversations had in IRC, we have the option to postpone this until 5.7 ... Cheers The Include in PHP 5.7 voting option, does this mean that we already now decide to include it in 5.7 or does it mean that we wish to reevaluate the feature during the 5.7 cycle? Nikita I'm not sure, whatever seems appropriate ... if we're going to say that it's too late for this to go in 5.6, then it can't be too early to decide it can go in 5.7 can it ?? Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Vote: Anonymous Classes
On 10/07/2013 10:49 AM, Joe Watkins wrote: On 10/07/2013 10:46 AM, Nikita Popov wrote: On Mon, Oct 7, 2013 at 8:29 AM, Joe Watkins krak...@php.net wrote: Morning Chaps, I have opened the vote on anonymous classes, following on from conversations had in IRC, we have the option to postpone this until 5.7 ... Cheers The Include in PHP 5.7 voting option, does this mean that we already now decide to include it in 5.7 or does it mean that we wish to reevaluate the feature during the 5.7 cycle? Nikita I'm not sure, whatever seems appropriate ... if we're going to say that it's too late for this to go in 5.6, then it can't be too early to decide it can go in 5.7 can it ?? Cheers Joe Morning Chaps, On the advice of many, I have restarted the vote, sorry for the inconvenience/confusion ... Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Vote: Anonymous Classes
On 10/07/2013 12:49 PM, Johannes Schlüter wrote: On Mon, 2013-10-07 at 08:38 +0100, Joe Watkins wrote: I brought it up in IRC the other day and someone, I forget who, but recognized them at the time, said they'd rather see it in 5.7, then a few people joined in the discussion and I couldn't really argue with their reasoning. When I brought this up I was on my current primary rant. Even small additions to the language have an impact on tools, best practices, ... which have to be explored about how to use them and how those interact with each other. To be clear: I love anonymous classes, I always wanted them when using FilterIterator etc. (while meanwhile generators+closures might be a better tool for some of those use cases) But we are moving extremely fast in reshaping the language making it hard for our users, of which many -- in my assumption -- primarily want a stable platform, to keep up. Oh and talking about stable platform. Current bug count: 3891 See also my previous message on that subject: http://news.php.net/php.internals/69093 johannes The observation that even a small patch has an impact, or can have an impact is valid. But then to talk about adoption time turns your reasoning a bit circular: adoption does take time, if we want for adoption to take place then the earlier a patch gets merged the better, regardless of the complexity of the patch. I did see your rant, though it's not really a rant; perfectly valid observations. Still, I don't know what you hope to achieve by pointing out the differences between the development of C or Java, and PHP: progress plotted on a graph nobody would expect to see any kind of relationship or commonality between these languages. So while they are valid observations they aren't really relevant. The bug count is a bit shameful, some effort should obviously be spent on bugs ... Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Expectations
On 10/20/2013 12:15 AM, Ferenc Kovacs wrote: On Sun, Oct 20, 2013 at 12:36 AM, Robert Stoll rst...@tutteli.ch wrote: Heya, I do not know how much it concerns this RFC but I came across the following page about an extension named Expect when I was searching for RFC Expect with google. http://php.net/manual/en/book.expect.php I suppose there would be a name clash between the extension and the new expect keyword. I do not know how internals usually deal with such problems, especially if it is within an extension, but I am sure someone will know it. Cheers, Robert it was discussed on irc, there is not problem here, because the ext name and the function name can't clash, and the ext doesn't have a function with the name of expect, so everything is fine afaik. Yeah, just to confirm, that's correct. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Expectations
On 10/21/2013 09:16 AM, Michael Wallner wrote: On 21 October 2013 10:13, Patrick Schaaf b...@bof.de wrote: Am 21.10.2013 03:52 schrieb Joe Watkins krak...@php.net: So looks like we need a new name ?? Ideas ?? abstract EXPRESSION wat? abstract is already a keyword, so no BC. abstract is not concrete so alludes a bit to the might-be-or-might-not-be-checked nature of the test abstract is the name for the short summary intro part of scientific papers, and these conditions are kind of a summary of what is known (preconditions) and concluded (postconditions). Ah, ok well. I'd rather go for expected() or except() then... Expected appears to be the most suitable solution suggested so far ... I was following along with the abstract suggestion, I thought that was pretty well thought out, but a bit hard to explain why we are re-using the abstract keyword for something that is completely unrelated to abstract classes all the same ... So for those that see the problem does Expected work around it ?? Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Expectations
On 10/21/2013 02:27 PM, Hochstrasser Christoph wrote: Hi Derick, This is again an RFC that does not even attempt to argue for its usefulness. This functionality was meant to replace the assert() API that currently exists in PHP, because of problems replacing it in a compatible manner. This doesn't say what is wrong with assert() or whether we *need* expect. The RFC was first proposed as a RFC to replace the assert() function with a assert keyword (which produces an opcode) in order to fix the unacceptable performance of the current assert() implementation. See also https://wiki.php.net/rfc/expectations#performance Later it was renamed to expect because the overall opinion was that changing assert() can't be done in 5.x. Yes, this RFC could state more clearly what its purpose is, but it certainly has usefulness. It's a lot faster than assert(), when turned off expect becomes a NOOP, and it doesn't rely on eval(). Morning, I'm not so good at conveying ideas; the explanation you have there is a summarized version of the java documentation of the same idea, the implementations are so similar they could be called identical. So everyone has a clear idea of how this works, here's some detail about the op array for the statement expect false;: Optimizations=On Expectations=On (DEVELOPMENT): opcodes[2] opcodes[0] - ZEND_EXPCT expression opcodes[1] - ZEND_RETURN Optimizations=Off Expectations=On: opcodes[9] opcodes[0]-opcodes[6] - ZEND_NOP opcodes[7] - ZEND_EXPCT expression opcodes[8] - ZEND_RETURN Optimizations=On Expectations=Off (PRODUCTION) opcodes[1] opcodes[0] - ZEND_RETURN Optimizations=Off Expectations=Off: opcodes[8] opcodes[0] - ZEND_JMP opcodes[7] opcodes[1]-opcodes[6] - ZEND_NOP opcodes[7] - ZEND_RETURN The same opcodes for assert(false): Optimizations=Either Assertions=Either (LEGACY): opcodes[3] opcodes[0] - ZEND_SEND_VAL string opcodes[1] - ZEND_DO_FCALL assert opcodes[2] - ZEND_RETURN When Assertions=Off opcodes[1] does not result in a call to eval, but the actual call to assert cannot be optimized, dragging down production considerably. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Expectations
On 10/21/2013 09:42 PM, Andrea Faulds wrote: On 21/10/2013 21:36, rpar...@yamiko.org wrote: This proposal sounds a lot like exceptions to me or am I missing something :/ Could we do something like throw new expectation($expects, $message); Er, T_EXPECT will be essentially a clone of Java and Python's assert statement, but not called assert because of the existing assert() function (and backwards-compatibility is PHP's middle name). Unless you mean the similar name. Well, I don't think exception and expect can be confused (though as someone who used to use Python, I keep reading this as except, Python's equivalent to catch), though ExpectationException might be confusing. I think we should name it AssertionException. I think it would be more confusing for expect to throw an AssertionException. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Expectations
On 10/22/2013 07:32 PM, Patrick Schaaf wrote: Am 22.10.2013 20:07 schrieb Joe Watkins krak...@php.net: You can catch exceptions, and log them. You can do that without impacting everything around you, you can do that, or whatever else you like. You can do that handling when you have only a few toplevel scripts, like when you have a setup with a small number of toplevel controllers and almost no CLI stuff around. But due to the scoped nature of try/catch you cannot reasonably / painlessly do that when you have 270 toplevel web and CLI entry points that then each need such a try/catch block. Also, there is the problem with catch (Exception) blocks, which you might easily dismiss as bad form, but which I'm sure are widespread in the field - I certainly know they are in our codebase... On the other hand, setup of an assertion-failed callback can easily go into an auto_prepend file, or into any other standard include (autoloader or something) you might have - exactly because it is something done on the global level instead of the scoped try/catch requirement. And IF you like the exception thing you can make that callback throw whatever you like - but you do not force that model on everybody. Furthermore such an assertion-failed callback has exactly the same change of looking at backtraces, so touting that as a singular feature of the exception approach is not valid. Finally, with the exception approach it is simply not true that it will completely go away in production - because these try/catch blocks will be present for any code that wants to handle the issue, and you cannot make those go away. I'm all for an assert alternative that works with expressions instead of eval, and that completely goes away in the opcode (cache) when disabled in production. best regards Patrick I was pretty explicit: used properly. We are going round in circles, discussing what assertion should be used for, again. Production code should _NOT_ have catch blocks everywhere to manage exceptions that will NEVER be thrown, obviously. assertion is a debug and development feature, if you take code to production that catches exceptions that your configuration does not allow to be thrown then that's pretty silly. assertion should be used during development, in development environments where it is enabled, by the time your code goes to production it should not suffer ExpectationExceptions and cannot anyway. I think this thread and the RFC now contains enough information regarding exceptions, it is now covered ground. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Expectations
On 10/22/2013 06:20 PM, Adam Harvey wrote: On 22 October 2013 02:08, Derick Rethans der...@php.net wrote: I'm pretty convinced that expectations *without* exceptions are a good idea, as using assert (which is really eval) is a nasty thing that should be replaced, but IMO exception throwing should not be part of this feature. I agree that something to replace the eval-based assert() would be good. What if the new syntax simply respected assert_options(), and assert_options() was extended to support an explicit ASSERT_EXCEPTION control option (that presumably took an exception class name as its option value)? That seems like it would provide the exception based possibilities that some posters want while maintaining the same assertion behaviour that users are already used to by default. Adam, who apologises if this has been suggested before — this was a long set of threads and I've been busy. I'm a bit perplexed at the need to retain any compatibility with what is a poor implementation ? I've mentioned that retaining compatibility is a restriction on this implementation, I guess assuming the reasons were obvious. I've brushed over them, but to be explicit, backwards compatible means multiple ini settings, at least one userland function, module globals, and confusion. It means being able to disable and enable assertions at _runtime_, impacting the implementation and every op array that uses it in _production environments_. All these things make the implementation less suitable as an implementation of assertion and I do not see a need to restrict it in this way. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] Exceptions in the engine
Okay that's reasonable enough ... Baby steps :) Cheers Joe On 24 Oct 2013 20:40, Nikita Popov nikita@gmail.com wrote: On Thu, Oct 24, 2013 at 9:27 PM, Joe Watkins krak...@php.net wrote: I have to ask the question; why stop at half way ?? A warning does absolutely nothing for the programmer, or their code, all it does is warn the client, who isn't very likely to even be in contact with the programmer, even less likely has access to their code. [...] This solution has existed for years, why do we shy away from it so much ?? I've never heard a really good argument for the existence of warnings or notices at all. This is all said with the knowledge that some errors are truly fatal, there is no point to, or chance of, throwing an exception. +1 on the whole idea, however far we are able to take it ... the further the better in my opinion ... Changing existing warnings to exceptions would be a (massive) compatibility break. Changing fatal errors isn't (in first order approximation) because - well, they are fatal, you can't really depend on their behavior unless you are using them as a die-substitute or something ^^ As this RFC is aimed at the 5.x branch it needs to maintain BC to a reasonable level, so changing warnings is really out of its scope. If you want to change warnings to exceptions that should be a separate proposal targeted at PHP 6. I'd prefer to keep it out of this thread. Thanks, Nikita
[PHP-DEV] Re: [RFC] Exceptions in the engine
On 10/24/2013 06:41 PM, Nikita Popov wrote:
Hi internals!
I'd like to propose an RFC, which allows the use of exceptions within the
engine and also allows changing existing fatal errors to exceptions:
https://wiki.php.net/rfc/engine_exceptions
This topic has been cropping up in the discussions for several of the
recent RFCs and I think the time has come to consider moving away from
fatal errors.
Thoughts?
Thanks,
Nikita
Delicious, obviously ...
I will add that; if we are going to push forward with using exceptions
properly, then there's internal code throwing base Exceptions objects
and that needs to be fixed, catch(Exception $ex) will have _even less
meaning_ than it does today if we are to throw exceptions in place of
fatal errors.
I have to ask the question; why stop at half way ??
A warning does absolutely nothing for the programmer, or their code, all
it does is warn the client, who isn't very likely to even be in contact
with the programmer, even less likely has access to their code.
Take the following code:
$handle = fopen(/path/to/file, w+);
if ($handle) {
}
If there is no $handle, I have no idea why, god only knows what the
logic looks like to detect why the failure occurred, and it doesn't have
to be fopen, can be almost anything that doesn't throw exceptions.
So, even though, some previously called function or method almost
certainly has some information that is useful, I have to make more sys
or library calls to determine the nature of the error and the code path
to take.
try {
$handle = fopen (/path/to/file, w+);
} catch (FileNotFoundException $fnf) {
} catch (PermissionException $pex) {
} catch (DiskFullException $dfe) {
}
[Note: the names of the exceptions and functions used _do not matter_,
consider the pattern only]
This solution has existed for years, why do we shy away from it so much
?? I've never heard a really good argument for the existence of warnings
or notices at all.
This is all said with the knowledge that some errors are truly fatal,
there is no point to, or chance of, throwing an exception.
+1 on the whole idea, however far we are able to take it ... the further
the better in my opinion ...
Cheers
Joe
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Use default_charset As Default Character Encoding
On 10/31/2013 09:21 AM, Yasuo Ohgaki wrote:
Hi Joe,
On Thu, Oct 31, 2013 at 6:07 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
On Thu, Oct 31, 2013 at 5:31 PM, Joe Watkins krak...@php.net wrote:
How could you override them ??
It's in PoC patch.
I made it while 5.5 was in beta, but it would work.
If they are removed then they cannot be referenced.
If they are not being removed then nothing is being simplified ...
The most important objective is when you are using 'UTF-8' (I guess it's
standard today)
All you should do is
default_charset='UTF-8'
then PHP uses the setting anywhere it can apply. (e.g. htmlspecialchars,
mbstring functions, etc)
I have to work on functions, but php.ini related staff is in PoC patch.
I forgot to mention that it helps i18n applications also.
For example, preg and sqlite only accepts UTF-8 as MBCS char. Users may
write
if (ini_get('default_charset') !== 'UTF-8') {
$str = mb_convert_encoding($str, 'UTF-8');
}
preg, sqlite function calls here.
It simplifies things for sure.
I'll add these in RFC later.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Sorry, I'm a shit. I should have looked at the patch first before
opening my big gob.
I will look at the patch, and join in when I have a clue :)
Cheers
Joe
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: RFC: Expectations
On 10/18/2013 10:46 PM, Joe Watkins wrote: Evening Chaps, Following on from discussion regarding assertion API in PHP, the following RFC is now up for discussion: https://wiki.php.net/rfc/expectations Please do point out any missing sections or information, so that it can be clarified as quickly as possible. I hope this conveys the idea a bit clearer to everyone ? Cheers Joe Evening, Wanted to bring this up for vote, any objections ? Cheers -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Use default_charset As Default Character Encoding
On 10/31/2013 08:28 AM, Martin Keckeis wrote: I don't see that it is possible to merge the settings from different libraries, what if an application is relying on mbstring and iconv having different settings ?? I think this use case is descibed in the RFC. The default_charset can be overwritten: default_charset php.* mbstring.*/iconv.* encoding specified by functions It's possible that applications are relying on the separation of their settings in order to function properly, is what I am trying to say. The same like above. The only way you could possibly merge those configuration settings is by also merging the functionality, there's no backward compatible way to do that, but I can imagine at some time in the future those libraries being used to support all of the required input/output/script encoding features at the level of Zend. I don't see how this can move forward and not break stuff ... I think it's the same like above...You can override the default setting, so everything should be fine. I'm +1 for this, as there are really to much unnecessary settings around! How could you override them ?? If they are removed then they cannot be referenced. If they are not being removed then nothing is being simplified ... Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Better type names for int64 RFC
On Fri, 2014-08-22 at 13:16 +0200, Nikita Popov wrote: Hi internals! Today the int64 RFC has been merged, despite objections regarding the naming changes it introduces. As we were not given a chance to resolve this issue before the merge, a short proposal has been created, which aims to revert all unnecessary naming changes and instead use type names that are consistent with the existing code base and expectations: https://wiki.php.net/rfc/better_type_names_for_int64 Due to the unexpected merge on short notice, with no chance for discussion, this issue is blocking a number of other patches. As such I ask if we can move through this RFC with a shortened cycle. I would not appreciate having to wait three weeks to have a workable codebase again. Nikita Morning internals, I'd very much like the same as Nikita; that's expected names, and quickly. Already it is going to be extremely difficult to maintain extensions for PHP7 and PHP7, we don't need it to get harder, it is not enough to say that we have to work something out. Fix it, fix it, fix it !! Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Move pecl_sync to core
On Wed, 2014-10-01 at 14:26 +0200, Ferenc Kovacs wrote: On Tue, Sep 30, 2014 at 10:18 PM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: What does that even mean? It means that any new functionality that gets into core could be considered young. Like when PHAR got introduced, it was a young extension. Same for PDO, same for FileInfo... What I'm trying to highlight is that being a recently coded extension or not, it's not a good argument to say join/no join. phar is a really bad example, the maintainers left right after it was accepted into the core making it a really bad technical burden, as it tightly integrated into the streams handling and stuff, making it a liability. from the average user POV I think it would be a bit weird why do we add a relatively new package which is at the bottom of the download stats ( http://pecl.php.net/package-stats.php) while not bundling stuff like memcache or mongo which are both mature and used/required by much more people/project. personally I think that a pecl extension needs to have stronger arguments to be bundled with php-src than the fact that it would probably create a bit more exposure for the ext. Afternoon, I think you got your answer anyway, so this message might fall on deaf ears. The assertion that there is no way to use mutex in a cross platform way in PHP is actually wrong: http://php.net/mutex The number of people that should be using mutex directly in PHP is about 4. PHP programmers are ill prepared for using such things, making some code exist, doesn't prepare anyone. With a quick glance, there is a number of mistakes in the code. There is an incorrect assumption that what this is doing is safe, it is not. You cannot share a mutex across process boundaries without setting attributes on creation, this includes forked child processes; given PHP's normal mode of execution does involve forking and multi-processing, the ideas in this extension are very close to useless. If this extension were well written and had all bases covered it still wouldn't make sense to include it, handing over synchronization to userland simply will not work. So, as you might have guessed, a -1, and your barking mad from me. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] UString
Morning internalz, https://wiki.php.net/rfc/ustring This is the result of work done by a few of us, we won't be opening any vote in a fortnight. We have a long time before 7, there is no rush whatever. Now seems like a good time to start the conversation so we can hash out the details, or get on with other things ;) Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] UString
On Tue, 2014-10-21 at 08:40 +0100, Leigh wrote: On 21 October 2014 08:06, Joe Watkins pthre...@pthreads.org wrote: Morning internalz, https://wiki.php.net/rfc/ustring This is the result of work done by a few of us, we won't be opening any vote in a fortnight. We have a long time before 7, there is no rush whatever. Now seems like a good time to start the conversation so we can hash out the details, or get on with other things ;) Breaks nothing, faster than mbstring, seems like win/win to me. On the flip side, implementing UString as a scalar object would be inconsistent. At time of writing, array, int, float, bool, etc have no implementation available for this. I agree it shouldn't be a scalar object, but how about some operator overloading like the GMP object has, so that you don't have to cast to string for expected behaviour with type coercion etc. Right now there are user-space libraries out there that cover a lot more functionality than UString. Do you need help implementing these? Do you think it would be beneficial to briefly list which areas need attention on the RFC, so they can be checked off over time? Overall +1 on the concept. Morning Leigh, ZEND_CONCAT is overloaded, as well as read_dimension and cast (to string) handlers. This seems to cover everything, unless I missed something ? Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] UString
On Tue, 2014-10-21 at 09:02 +0100, Lester Caine wrote: On 21/10/14 08:06, Joe Watkins wrote: Now seems like a good time to start the conversation so we can hash out the details, or get on with other things ;) Does this address the problem of sorting array keys using a particular language or collation? -- 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 No. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] UString
On Tue, 2014-10-21 at 13:01 +0400, Dmitry Stogov wrote: Hi Joe, As an extension it looks fine. I assume, you don't propose to use UString objects in engine and other extensions. I'm not proposing it now, no. Unfortunately, it's yet another incomplete solution. It won't allow Unicode strings as array keys; The engine doesn't allow that, couldn't we find a way of using objects as array keys ?? It doesn't seem like a limitation of the extension, to me ;) concatenation using . (probably may be done), That's already done. no auto-conversion from/to script/output encoding, That could be arranged. no auto-conversion of strings coming from database extensions, etc I'm not sure how important that is, it's not a big deal to create a new object, nor would it be a big deal for those extensions that need to always return unicode strings to do so. The right approach, would be extending zend_string with encoding and then adopting near all functions working with zend_string to take encoding into account. But, of course, this is going to lead to much more complicated solution (with some slowdown). That seems a lot like bashing our head against a wall. We tried to introduce support everywhere and it fails. Do we really want to step on the performance gains introduced by recent changes by making all strings unicode ? That doesn't seem like a sensible thing to want, at least right now. Having UString doesn't stop us approaching the problem differently in the future, but it would have to be a very different future to even make sense to me. If we don't care about complete solution, UString proposal may make sense at lest as a faster replacement of ext/mbstring. As the RFC states, we are only approaching one problem, the problem that ext/mbstring is not a good API. Thanks. Dmitry. On Tue, Oct 21, 2014 at 11:06 AM, Joe Watkins pthre...@pthreads.org wrote: Morning internalz, https://wiki.php.net/rfc/ustring This is the result of work done by a few of us, we won't be opening any vote in a fortnight. We have a long time before 7, there is no rush whatever. Now seems like a good time to start the conversation so we can hash out the details, or get on with other things ;) Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: AW: [PHP-DEV] [RFC] UString
On Tue, 2014-10-21 at 11:48 +0200, Robert Stoll wrote: Hi Joe, I have not devoted myself to unicode and thus cannot give you a feedback on your implementation. Nevertheless, I was wondering whether string interpolation is still supported by your solution (couldn't find anything in the RFC about it but maybe you thought that is implicit given). Cheers, Robert -Ursprüngliche Nachricht- Von: Joe Watkins [mailto:pthre...@pthreads.org] Gesendet: Dienstag, 21. Oktober 2014 09:07 An: internals@lists.php.net Betreff: [PHP-DEV] [RFC] UString Morning internalz, https://wiki.php.net/rfc/ustring This is the result of work done by a few of us, we won't be opening any vote in a fortnight. We have a long time before 7, there is no rush whatever. Now seems like a good time to start the conversation so we can hash out the details, or get on with other things ;) Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I did think implied, the extension readme mentions casting, I'll mention in the RFC ... Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] UString
On Tue, 2014-10-21 at 13:52 +0400, Dmitry Stogov wrote: On Tue, Oct 21, 2014 at 1:25 PM, Joe Watkins pthre...@pthreads.org wrote: On Tue, 2014-10-21 at 13:01 +0400, Dmitry Stogov wrote: Hi Joe, As an extension it looks fine. I assume, you don't propose to use UString objects in engine and other extensions. I'm not proposing it now, no. Unfortunately, it's yet another incomplete solution. It won't allow Unicode strings as array keys; The engine doesn't allow that, couldn't we find a way of using objects as array keys ?? It doesn't seem like a limitation of the extension, to me ;) concatenation using . (probably may be done), That's already done. no auto-conversion from/to script/output encoding, That could be arranged. no auto-conversion of strings coming from database extensions, etc I'm not sure how important that is, it's not a big deal to create a new object, nor would it be a big deal for those extensions that need to always return unicode strings to do so. The right approach, would be extending zend_string with encoding and then adopting near all functions working with zend_string to take encoding into account. But, of course, this is going to lead to much more complicated solution (with some slowdown). That seems a lot like bashing our head against a wall. We tried to introduce support everywhere and it fails. Do we really want to step on the performance gains introduced by recent changes by making all strings unicode ? Yeah :) You must like punishment :D I'm not sure, if it should be done, and I don't like to work on it in the nearest future, but zend_string approach should be easier to implement than separate IS_UNICODE + IS_STRING + IS_BINARY types in PHP6. The implementation might be simpler, but the effect the same I think. I can be wrong, but nothing has so drastically changed that will allow us to absorb the kind of impact I think you are talking about. That doesn't seem like a sensible thing to want, at least right now. Having UString doesn't stop us approaching the problem differently in the future, but it would have to be a very different future to even make sense to me. Agree. If we don't care about complete solution, UString proposal may make sense at lest as a faster replacement of ext/mbstring. As the RFC states, we are only approaching one problem, the problem that ext/mbstring is not a good API. Then, it's fine. One note regarding implementation: why do you use C++ for ustring.cpp? I understand it's necessary for ICU backend, but if in the future you might switch to another backend (and it may not require C++) why to use C++ for PHP extension part? Totally possible that we'll have to change, or that we should change. A few people have said they would like to write a backend so we'll see what comes in and where that leads us. Thanks. Dmitry. Thanks. Dmitry. On Tue, Oct 21, 2014 at 11:06 AM, Joe Watkins pthre...@pthreads.org wrote: Morning internalz, https://wiki.php.net/rfc/ustring This is the result of work done by a few of us, we won't be opening any vote in a fortnight. We have a long time before 7, there is no rush whatever. Now seems like a good time to start the conversation so we can hash out the details, or get on with other things ;) Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Cheers Joe Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] UString
On Tue, 2014-10-21 at 10:30 -0700, Stas Malyshev wrote: Hi! I wish there was a way for specific objects to opt into this. There will be, if __hashKey() or whatever would be the properly bikeshedded name, becomes reality as discussed elsewhere. It shouldn't be hard to do and it's exactly what many other languages do when trying to use objects as keys for maps. Not ready for discussion yet ... https://wiki.php.net/rfc/hashkey But it exists, I think it solves a problem for ustring in particular but it solves the problem in general too. No time to write about it or discuss it at this moment, but in pipeline, hopefully ... Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] UString
On Tue, 2014-10-21 at 21:42 +0100, Rowan Collins wrote:
On 21/10/2014 08:06, Joe Watkins wrote:
Morning internalz,
https://wiki.php.net/rfc/ustring
This is the result of work done by a few of us, we won't be opening any
vote in a fortnight. We have a long time before 7, there is no rush
whatever.
Now seems like a good time to start the conversation so we can hash out
the details, or get on with other things ;)
Cheers
Joe
I think this looks like a really great start at creating something
actually useful, rather than getting stuck at the drawing board. I like
that the scope is quite small initially - where does the single
responsibility of a class that represents a string end, anyway? :)
A few opinions:
1) Global / static defaults are bad.
The existence of the setDefaultCodepage method feels like an
anti-pattern to me. It means libraries can't rely on this class working
the same way in two different host environments, or even at two
re-entries in the same program. Effectively, if you don't know what the
second argument to the constructor will default to, you can't actually
treat it as optional unless you're writing monolithic code. This is a
common pattern in PHP, but http_build_query() would be so much more
pleasant if I could safely call it with 1 argument instead of 3.
I think the default should be hard-coded to UTF-8, which according to
previous discussion is always the default *output* encoding, so would
mean this would always work: $aUString = new UString( (string)$aUString
); Any other encoding will be dependent on, and known from, the context
where the object is created - if grabbing data from an HTTP request, a
header should tell them; if from a database, a connection parameter; and
so on.
Could be true, it feels quite horrible to me today too, I think someone
else suggested it, but it might have been me.
I'll look at doing something about that ...
The only case I can see where a default encoding would be sensible would
be where source code itself is in a different encoding, so that
u('literal string') works as expected. I guess if we ever went down the
route of special literal syntax like u'literal string', the declared
source encoding could be used.
Actually, the u() shortcut function appears to be missing the encoding
parameter completely; is this deliberate?
Fixed that.
2) Clarify relationship to a byte string
Most of the API acts like this is an abstract object representing a
bunch of Unicode code points. As such, I'm not sure what getCodepage()
does - a code page (or more properly encoding) is a property of a stream
of bytes, so has no meaning in this context, surely? The internal
implementation could use UTF-8, UTF-16, or some made-up encoding (like
Perl6's NFG system) and the user should never need to know (other than
to understand performance implications).
On the other hand, when you *do* want a stream of bytes, the class
doesn't seem to have an explicit way to get one. The (currently
undocumented) behaviour is apparently to spit out UTF-8 if cast to a
string, but it would be nice to have an explicit function which could be
passed a parameter in order to serialise to, say, UTF-16, instead.
I reused the terminology used by ICU, it made sense in their
documentation.
So we want a ::getBytes or something like that ... I'll do that ...
3) The Grapheme Question
This has been raised a few times, so I won't labour the point, just
mention my current thinking.
Unicode is complicated. Partly, that's because of a series of
compromises in its design; but partly, it's because writing systems are
complicated, and Unicode tries harder than most previous systems to
acknowledge that. So, there's a tradeoff to be made between giving users
what they think they need, thus hiding the messy details, and giving
users the power to do things right, in a more complex way.
There is also a namespace mess if you insist on every function and
property having to declare what level of abstraction it's talking about
- e.g. $codePointLength instead of $length.
An idea I've been toying with is rather than having one class
representing the slippery notion of a Unicode string, having (at
least) two, closely tied, classes: CodePointString (roughly = UString
right now) and GraphemeString (a higher level abstraction tied to the
same internal representation).
I intend to mock this up as a set of interfaces at some point, but the
basic idea is that you could write this:
// Get an abstract object from a byte string, probably a GraphemeString,
parsing the input as UTF-8
$str = u('some text');
// Perform an operation that explicitly deals in Code Points
$str = $str-asCodePoints()-normalise('NFC');
// Get information using a higher level of abstraction
$length = $str-asGraphemes()-length;
// Perform a high-level mutation, then convert right
Re: [PHP-DEV] [RFC] UString
On Tue, 2014-10-21 at 10:28 -0700, Stas Malyshev wrote: Hi! https://wiki.php.net/rfc/ustring This is the result of work done by a few of us, we won't be opening any vote in a fortnight. We have a long time before 7, there is no rush whatever. Couple of thoughts: - I like the idea of having a unicode string class. May be a way to figure out the right way to do it without messing up the whole core. - I wish there were more description of which API this class provides. If it's planned to be direct copy of UnicodeString, some of the operations there are not how PHP strings usually work (i.e. in-place modification) and it's not really enough to make it useful - e.g. what if I need to do regexps on it, for example? Or does it cover whole mbstring API too? What about something mbstring doesn't cover, like ucfirst or strrev? API on github in readme. Regexp not covered yet, ICU has a nicer Matcher/Pattern API like Java's, I'm not sure what to do there, an ICU based API could certainly be introduced. - Do we really need different encodings, different backends and so on, internally? Note that each backend has its own quirks, limitations and bugs, and there's nothing worse than dealing with unpredictable set of dependencies. The user cares what they send into the class and what comes out, but very rarely they care what happens inside - why not just do it one way everywhere? No, actually, I don't think we do. It was over complicating something simple, so I removed the backend abstraction and will work towards solving the rest too. We'll use ICU, because battle tested like nothing else, and keeps everything simple ... it doesn't make sense to introduce a possibly unstable and as you rightly say different API with it's own quirks. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] UString
On Tue, 2014-10-21 at 07:49 -0700, Sara Golemon wrote: On Oct 21, 2014, at 0:06, Joe Watkins pthre...@pthreads.org wrote: Morning internalz, https://wiki.php.net/rfc/ustring This is the result of work done by a few of us, we won't be opening any vote in a fortnight. We have a long time before 7, there is no rush whatever. The backend abstraction seems overengineered to me. It could also lead to inconsistencies in behavior if ICU and Windows implement something in subtly different ways. Since we're linking ICU for the rest of the intl extension anyway, it seems to me like we should just focus on it as an ICU wrapper. Also, I'd peopose a minor ammendment to this RFC that other intl classes be extended to support taking UString instances as arguments (avoiding the implicit conversion to UTF8). That work doesn't have to gate adoption of the base implementation, it'd just be useful to decide at the same time if we want to do so. -Sara Actually I agree, I just needed a few people to say WTF. Backend gone, we are gonna use ICU, rfc/ext updated. INTL is still an open question yeah, preference noted. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] UString
On Thu, 2014-10-23 at 12:44 +0400, Dmitry Stogov wrote: this won't completely solve the problem, because array keys won't be UString anymore. http://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#hashCode() Others solve this problem in exactly this way, the Java implementation requires that you return an int. The one in that draft will allow you to return any scalar. This is much more suitable for PHP. It doesn't solve the problem directly but allows the programmer to solve it for themselves, just like Object.hashCode in Java. Thanks. Dmtiry. On Thu, Oct 23, 2014 at 12:11 PM, Joe Watkins pthre...@pthreads.org wrote: On Tue, 2014-10-21 at 10:30 -0700, Stas Malyshev wrote: Hi! I wish there was a way for specific objects to opt into this. There will be, if __hashKey() or whatever would be the properly bikeshedded name, becomes reality as discussed elsewhere. It shouldn't be hard to do and it's exactly what many other languages do when trying to use objects as keys for maps. Not ready for discussion yet ... https://wiki.php.net/rfc/hashkey But it exists, I think it solves a problem for ustring in particular but it solves the problem in general too. No time to write about it or discuss it at this moment, but in pipeline, hopefully ... Cheers Joe Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] UString
On Thu, 2014-10-23 at 12:47 -0700, Stas Malyshev wrote: Hi! Not ready for discussion yet ... https://wiki.php.net/rfc/hashkey Hey, I've just started my own... https://wiki.php.net/rfc/objkey I guess we should combine them :) Happy to port patch already written to conform to your specification, (more or less complies, other than name) you are welcome to go ahead and do the RFC bit ? Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] UString
On Thu, 2014-10-23 at 12:47 -0700, Stas Malyshev wrote: Hi! Not ready for discussion yet ... https://wiki.php.net/rfc/hashkey Hey, I've just started my own... https://wiki.php.net/rfc/objkey I guess we should combine them :) Done, branch @ http://github.com/krakjoe/php-src/compare/hashkey Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] UString
On Thu, 2014-10-23 at 12:54 -0700, Stas Malyshev wrote: Hi! P.S. u() is a bad name, will break lots of code, i.e. Maybe __u()? It's a bit ugly but you're not allowed to use __ so it's safe. /me cringes ... I wonder how much of a problem it really is, usually when we say some function name is a problem is because of hundreds and hundreds of results on github. If it's a huge problem then we should rename it, if we have to dig around for a single project that's incompatible, or even a handful, then it's not really a problem. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
On Fri, 2014-10-24 at 23:06 -0400, Derick Rethans wrote: On Fri, 24 Oct 2014, Bob Weinand wrote: Commit:2bcac53bca8ea82d661f057b6d9ff3c7c84f05a7 Author:Bob Weinand bobw...@hotmail.com Fri, 24 Oct 2014 19:29:50 +0200 Parents: 53560ca06b333b71883269091f7d74c0a25e087b c03ac47bafd0ea55055a2f3d4de0bc6bb4d98d8d Branches: master Link: http://git.php.net/?p=php-src.git;a=commitdiff;h=2bcac53bca8ea82d661f057b6d9ff3c7c84f05a7 Log: Made phpdbg compatible with new engine snip AM sapi/phpdbg/xml.md Although this patch does make it work with PHP 7, it also does do something absolutely different: it reinvents a wheel by coming up with a new XML protocol for debugging. So far I've been silent on PHPDBG, but seriously, is it really not possible to cooperate instead of reimplementating something that already exists? PHPDBG is difficult to use with its odd command line commands. And then I haven't even spoken about the pretentious awesomesauce on http://phpdbg.com/ — a domain that's not even under the PHP group's control. cheers, Derick Derick, A few weeks ago, I was at a conference where you told a room filled with hundreds of developers that phpdbg was no good, because you don't know how to use it. This is a strange sort of silence, and does not invite us to co-operate. When you invented dbgp there were other protocols in existence, not sure why we are expected to reuse a protocol. It so happens that the phpstorm guys working on integration seemed keen on something new. I don't see the problem in that. If the only reason it exists is for projects like phpstorm and they are actually going to put time into trying something new, then why the hell not. I'm not sure why it matters what kind of language we use on phpdbg.com, not sure why you think it should be under the control of the php group either. If you had wanted to co-operate, you could have spoken to me at that conference in person, or to any of us in IRC, on any day. You chose to do what pleased you. We should be allowed to do the same. Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
On Sat, 2014-10-25 at 16:19 +0700, Pierre Joye wrote: hi, On Sat, Oct 25, 2014 at 1:13 PM, Joe Watkins pthre...@pthreads.org wrote: Although this patch does make it work with PHP 7, it also does do something absolutely different: it reinvents a wheel by coming up with a new XML protocol for debugging. So far I've been silent on PHPDBG, but seriously, is it really not possible to cooperate instead of reimplementating something that already exists? PHPDBG is difficult to use with its odd command line commands. And then I haven't even spoken about the pretentious awesomesauce on http://phpdbg.com/ — a domain that's not even under the PHP group's control. cheers, Derick Derick, A few weeks ago, I was at a conference where you told a room filled with hundreds of developers that phpdbg was no good, because you don't know how to use it. This is a strange sort of silence, and does not invite us to co-operate. Well, not well played but I do not think arguing back and forth about that will bring us anywhere. I will just skip any part of this discussion about this kind of things. When you invented dbgp there were other protocols in existence, not sure why we are expected to reuse a protocol. It so happens that the phpstorm guys working on integration seemed keen on something new. I don't see the problem in that. If the only reason it exists is for projects like phpstorm and they are actually going to put time into trying something new, then why the hell not. While you are right from a principle point of view, I do think it makes sense to implement something which is already a de facto standard in the PHP world, well supported by various tools, etc. If phpdbg would not be in core, I would not care much, as you said, it would then be an independent project and you can do whatever you wish. However it is not the case, phpdbg is in the core. Being in core means it does affect how our users will work, use it, etc. Design decisions like protocol used to work with external tools should be taken very carefully. Adding yet another one does not sound very good at a first glance. Do you mind to enlighten us about the advantages of this new protocol over the existing one? Or what are the limitations of the existing one which lead you to the creation of a phpdbg protocol? I'm not sure why it matters what kind of language we use on phpdbg.com, not sure why you think it should be under the control of the php group either. Well, phpdbg is part of the core. As such it reflects what PHP is, does or says. I do not have a problem with anything I have seen on the project site but this is something to keep in mind. If you had wanted to co-operate, you could have spoken to me at that conference in person, or to any of us in IRC, on any day. You chose to do what pleased you. We should be allowed to do the same. Yes and no, as I wrote earlier in this reply. Thanks for the great work and let try to sort that out :) Cheers, Pierre Pierre, I wasn't involved in the conversations during it's development very much. You will have to wait for bob or someone from the phpstorm team to fill in the blanks. Suffice to say that they found a reason to work on a new protocol, details I don't know. It had it's own remote protocol when it was merged, but it turned out to be pretty useless for those people interested in using it remotely. This is only a development of that original feature. I of course recognize that we are in some sense representative of the PHP project, however, we are talking about words like awesomesauce, not profanity, or anything offensive whatever. Bob done all the work on this, in record time. It's totally crappy that he'll wake up today to this nonsense, he should be feeling pleased with himself. He worked very hard on it. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
On Sat, 2014-10-25 at 11:20 -0700, Stas Malyshev wrote: Hi! Just a minor question, Derick. If you care about phpdbg, why are you only dropping any comment about it by the time it got into php-src repo? It’s known that all the development currently (except for master, but that just was a merge and then a pure rewrite on top of that merge, nothing related to the protocol) is going on in krakjoe/phpdbg github repo. There was now an xml-protocol branch for three weeks before it got merged into krakjoe/phpdbg#master. You had vast time to notice it and complain before, if you’d really have cared. I would like to weigh in here. If we're talking about things in PHP core repo, we did it somewhere in public repo and nobody complained is not a good stance. People do literally hundreds of things around PHP in public places, but not everything is part of PHP core. phpdbg now is. That involves not only good parts (by-default acceptance by millions of PHP users) but some obligations - like proper discussion and notification. Of course, since master is not stable yet, we have somewhat relaxed rules there, but even then introducing new debugging protocol into PHP core seems to be something that warrants some notification. As a person who spent significant time on implementing and maintaining one of PHP debugging solutions in the past, I, for example, would be interested to take a look into what is being checked into core repo in this regard. However, the first note I see about this happening is the commit messages. And that takes us back to old and not-so-good check in first, discuss later times. With project of the size of PHP, it having good process matters no less than having good code. I'd like to everyone to stay grounded in reality and say that we have been checking code into php-src for months, very very few people have expressed an interest in what we were actually doing, you aren't one of them Stas. There was a remote protocol at the start, it still exists, it was changed slightly. XML was added as an option. None of the decisions taken were questionable, in the slightest. While we should have given internals a heads up, it would have not have changed the outcome. We will notify internals of our intentions to make such changes in future, if we thought there was any chance of any feedback before today, we would already be doing so. So saying we had this branch for whole three weeks before merging it into PHP repo is not really saying much. That said, we are where we are, and I think it would be great if this would somehow server as a starting point for developing a unified protocol for debugging PHP. There are a number of good tools for debugging PHP, and it would be a pity if everybody invented their own protocols and required to install half-dozen of extensions to be compatible with all tools doing the same in slightly different way. We have so many unification efforts with PSR and the spec and so on, I'm pretty sure we can make a protocol that would be workable for all, debugging PHP is not exactly rocket surgery and there are not that many things there that we couldn't find a common ground. I quite like that idea, however, I'm stretched too thin to say that I can do anything about it. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Using objects as keys
On Sun, 2014-10-26 at 18:37 -0700, Stas Malyshev wrote: Hi! I would like to present to your attention an RFC about using object as keys: https://wiki.php.net/rfc/objkey It was discussed in the past on the list: http://marc.info/?t=14114596961r=1w=2 and I think it makes sense to propose a formal RFC for it. Both the text and the code in the patch includes bits done by myself and Joe Watkins. The patch does not cover 100% of cases but should work for most reasonable scenarios, if something is wrong or you have ideas how to make it better please tell. The name __hash is not final, I am open to using __toKey instead or any reasonable alternative, we may also include a couple of options in the vote if that will be a point of disagreement. Thanks, Stas Morning Stas, Nicely done. Whether SPL classes, or any other classes, should use the functionality should be left to another discussion. I wonder if it might be feasible to try and define what the contract of this method is, in the same kind of way as the Java docs do for Object.hashCode ? We can't have the exact same contract perhaps, but it might be useful to try to define it at this stage. It seems __toScalar might be a good name, this is what the method actually does, the engine then coerces to a type suitable for use as a key, but you can return a double. It might be more forward thinking therefore to use the name __toScalar, while today we'd only be using it for this, if we come up against the requirement to treat an object as a scalar for anything else, we have the machinery already and we don't have to add another magic method at that time. Not sure what others think about that ... I liked the name __hash better than __toKey, I like __toScalar better than those because it describes what the method is meant to do the best. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Using objects as keys
On Sun, 2014-10-26 at 23:36 -0700, Stas Malyshev wrote: Hi! It seems __toScalar might be a good name, this is what the method actually does, the engine then coerces to a type suitable for use as a key, but you can return a double. It might be more forward thinking therefore to use the name __toScalar, while today we'd only be using it for this, __toScalar does not express the fact why we are calling it - to use it as a key. It's not just a scalar conversion, it's conversion for the purpose of hashing. Morning Stas, True, I was just thinking that the next time we need to represent an object as a scalar for whatever reason we might end up having to add another magic method. It's easy enough to document that __toWhatever is used in the context we intend to use it in. Not super bothered about it ... it's obviously a +1 from me whatever the name. About restricting to signed/unsigned ints ... this doesn't seem sensible, the PHP programmer doesn't care about signs, or types. It makes sense to allow the programmer to return anything we would currently coerce to a valid key, don't think that needs to change. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Using objects as keys
On Mon, 2014-10-27 at 00:41 -0700, Stas Malyshev wrote: Hi! Once your proposal is in the language, you will never, in the future, be able to add real support for objects as keys, because the semantics is blocked. This implies this support is not real and we want some other support. I don't think I agree with either. I do understand where your proposal is coming from and what it is trying to accomplish. But I think, at least, that it should clearly spell out that any ambition to really support objects as array keys in the base language, will then be given up. Was there ever such an ambition? Does somebody have any idea how to properly do it and a reason why? I hardly see how that would make sense. SplObjectStorate operates with object identity as determined by spl_object_hash, right? Changing that Now, it does, since there's no other option. However, in the future there may be other options - i.e. objects whose identity is not the same as their memory address. For example, for an object representing number (GMP) or string (UString) their identity is their content, not their memory address. Thus, if you want to use UString as an index, or have an unique set of strings, spl_object_hash would not be your friend. Of course, there's always an option of just telling it - e.g. by providing an option to the ctor. Right. Somehow python manages to live quite fine with that fact. For some definitions of quite fine, I presume - I can't see how a hashtable that repeatedly calls user code can be efficient. It probably isn't. Right. You don't do that when your object implements __hash__ and __eq__. Or, more precisely, you're asked nicely not to do it - because there's no way to actually ensure it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ Morning, As already pointed out by Stas, using objects as array keys would require a rewrite of the HashTable API, something integral to PHP. I'm not sure that is realistic, or possible. I think probably, the best way we can support objects as collection keys is with the introduction of generics, something totally disconnected from this RFC, that nobody has a working patch for. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
On Wed, 2014-10-29 at 17:08 -0700, Derick Rethans wrote: On Sun, 26 Oct 2014, Bob Weinand wrote: Am 26.10.2014 um 16:09 schrieb Derick Rethans der...@php.net: On Sat, 25 Oct 2014, Joe Watkins wrote: On Fri, 2014-10-24 at 23:06 -0400, Derick Rethans wrote: On Fri, 24 Oct 2014, Bob Weinand wrote: Log: Made phpdbg compatible with new engine snip AM sapi/phpdbg/xml.md Although this patch does make it work with PHP 7, it also does do something absolutely different: it reinvents a wheel by coming up with a new XML protocol for debugging. So far I've been silent on PHPDBG, but seriously, is it really not possible to cooperate instead of reimplementating something that already exists? PHPDBG is difficult to use with its odd command line commands. And then I haven't even spoken about the pretentious awesomesauce on http://phpdbg.com/ — a domain that's not even under the PHP group's control. A few weeks ago, I was at a conference where you told a room filled with hundreds of developers that phpdbg was no good, because you don't know how to use it. I was being polite. I should have told them it is useles for any of our users, instead of blaming it (wrongly) on my own ineptitude. No, xDebug has its use cases, phpdbg other use cases. They overlap many times. And it’s definitely not useless. I’ve already been able to debug real things with phpdbg and it works nicely for me. I think this hits something on the spot: we don't define scope in an RFC. And scope creep is never a good thing. I would suggest that you come up with what scope phpdbg should solve, and don't get out of it. This is a strange sort of silence, and does not invite us to co-operate. Neither does calling internals people dicks or knobs“. That’s definitely a bad thing… could we please leave this genre of discussion out of internals? Sorry, I think that it should be called out *just* because it's not appropriate in any case. When you invented dbgp there were other protocols in existence, There indeed where, but none of them were either open, or supporting more than one language. As that was the goal, the people from ActiveState—which *still, ten years later* have the best debugger frontend—and I sat around a table and implemented a language-agnostic debugging protocol. Used by Xdebug, and their debuggers for perl, python, tcl, ruby, and XSLT. Hmm? I hardly could find anything about that with a few google searches... http://code.activestate.com/komodo/remotedebugging/ http://en.wikipedia.org/wiki/Project_Zero#PHP_support http://hhvm.com/blog/6239/hhvm-3-3-0 not sure why we are expected to reuse a protocol. Because DBGp is virtually a standard in the PHP world. Because something is used by the only open-source thing in a field, it doesn’t make it a standard. That you definitely have gotten wrongly. I used virtually as adjective. I perhaps should have used de facto[1]. [1] http://dictionary.reference.com/browse/de%20facto It so happens that the phpstorm guys working on integration seemed keen on something new. I don't see the problem in that. If the only reason it exists is for projects like phpstorm and they are actually going to put time into trying something new, then why the hell not. Well, if you'd have used DBGp, they wouldn't have to do any work. Ask them at PhpStorm. They were pleased to not have to use DBGp for it. They just initially requested it because they didn’t knew any better protocol. That’s all. So I actually did talk to them (in person, at ZendCon), and their account of events is pretty much the exact opposite. But in any case, that doesn't mean that reinventing the wheel again makes sense. It's certainly not helpful to for users, for which you are now fragmenting support. If you had wanted to co-operate, you could have spoken to me at that conference in person, I tried. You disappeared after the first afternoon. Maybe, but if you wouldn’t have given such a negatively talk on the phpdbg part, he maybe wouldn’t have disappeared. Where you there? I don't think so. So please don't judge people on here-say information. cheers, Derick Morning, This is new information to me, I was lead to believe that phpstorm were happy to invest time in it. I asked bob for the xml stuff to be reverted from 5.6 and master yesterday and be developed elsewhere. This now *must* happen, it doesn't belong in php-src at this point. If development of a remote protocol is to be carried out, it *must* be carried out in an experimental branch of php-src, or on krakjoe/phpdbg. About scope, we never intended to write a remote debugger suitable for everything, we were pushed down that road by what people seem
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
On Thu, 2014-10-30 at 14:56 +0700, Pierre Joye wrote: This is new information to me, I was lead to believe that phpstorm were happy to invest time in it. I asked bob for the xml stuff to be reverted from 5.6 and master yesterday and be developed elsewhere. This now *must* happen, it doesn't belong in php-src at this point. If development of a remote protocol is to be carried out, it *must* be carried out in an experimental branch of php-src, or on krakjoe/phpdbg. About scope, we never intended to write a remote debugger suitable for everything, we were pushed down that road by what people seem to want. phpdbg is fundamentally different to xdebug, it cannot be loaded in any SAPI, it doesn't even make sense to talk about using it in the same way as xdebug, it does not and can not do all the things. I'm quite happy for phpdbg to have better remote abilities, I even said that we should use dbgp https://github.com/krakjoe/phpdbg/issues/105 I'd be even happier if we left that to xdebug, we never wanted to focus on that in the beginning. The remote ability that phpdbg had at the beginning was for no more than giving people uncomfortable with using a shell, or not able to use a shell, an option. It worked, but was arguably terrible, and an afterthought. I think it would be better for everyone if we dropped the idea of support for remote debugging, I won't stop it going ahead if bob still wants to work on it, but I do regard it as feature creep. I see a clear usecase for remote debugging and shell. Same shell usage as now but with remote host support. I do that a lot for many other languages, testing stuff in various VMs. It is amazingly handy to be able to do that. As of 5.6, I am not sure either with other big changes as 5.6 is stable now, huge changes (and not well tested, builds were broken f.e.) should be done after (public) discussions, if necessary. Cheers, Morning, Some remote ability is helpful, I agree. The kind of remote ability we had at the start is, in my opinion, as far as it ever really needs to go. The use case for remote debugging, using any sapi, will always be best satisfied by xdebug. If we are to develop the remote debugging features with an extended or new version of dbgp, then 7 is the only sensible target for that I think, if there is a sensible target. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: phpdbg situation in PHP-5.6
On Thu, 2014-10-30 at 13:06 +0100, Ferenc Kovacs wrote: On Thu, Oct 30, 2014 at 11:59 AM, Bob Weinand bobw...@hotmail.com wrote: Hey, I can accept that. But it’d be great if you could only revert now in the 5.6.3 release branch, not in the 5.6 development branch, so that this gives us now still some time to see what exactly we want to revert or not and for some eventual RFC? we could do that, but that will make the RMs job much harder, because that means that any upcoming 5.6 rc/stable release has to be always cherry picking everything but the phpng stuff. I think having it in the krakjoe/phpdbg repo, or in php-src but under a feature branch would be better. To add for 3.: Issues where with what I really couldn’t think of (separate build dir on Linux…) or the issues with a JSON dep or Windows which I couldn’t test. yeah, sorry if it sounded as I'm blaming you guys, I was trying to make a point about that big changes like that need some time to stabilize and I also think that some of the issues would have been pointed out if there would be some discussion prior merging a bunch of changes to php-src. Also, just to point it out: Windows allows extensions to be in a random directory, *nix does not. I’d rather change the /acinclude.m4 to not be bound to the /ext directory, so that it just works like on Windows. (That ugly hack really annoys me too…) I could live with that, but we have to be careful when changing the build infrastructure, because people build php on more platform than we test on. It wasn’t also a single feature, but more features (though XML protocol could be well be the cause of 1/3 of the lines changed in phpdbg)... fair enough. is there any change which is not related to the remote debugging/new xml protocol and you would want to have it in 5.6.3? We are getting late with the tag, so my quick solution would be reverting everything phpdbg related from PHP-5.6 in the last 5 days or so. -- Ferenc Kovács @Tyr43l - http://tyrael.hu Morning, These should be saved: https://github.com/krakjoe/phpdbg/commit/fa3a01374d30a9efb6d455ba952aea2187254420 https://github.com/krakjoe/phpdbg/commit/de656f8a49ee0e8cd67812bac579747df9de98fa +1 on reverting all changes, please do save those two though ... I'll take a look at what that results in and have master mirror that, Bob is busy with uni for the next few days, so guess he won't have time. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG scope
On Mon, 2014-11-03 at 21:03 +, Derick Rethans wrote: Hi, This is based on an email conversation between Joe Watkins and me. I asked him what the original scope of phpdbg was, and I've summarized his reply here: - PHPDBG was originally envisioned as a gdb for the Zend VM, with gdb like commands to debug, and step through code. - Support for breaking on an opline, something that no userland PHP users would need. - Support for breaking on lines, was an additional step later. - For PHP programmers, which spend most of their time at the console. - Not intended to cover PHP's primary domain of HTTP requests. Then later, they documented a way that you could use it to emulate an HTTP request, by setting those superglobals and executing your index.php - your code doesn't know the difference between a real request, and a cli-like script with the same super globals set. And Joe indicates, that with that addition, the flood gates opened. He also said that he would still like to remain in that narrow scope, phpdbg is still useful in it's current (pre xml stuff) form. and that it was never meant to usurp xdebug, as that is not where we were aiming, and it's an extremely unrealistic thing to even want. And I very much agree that the above bullet points, is what phpdbg's scope should be. Joe, if I got this wrong, then please say so :-) cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Morning Internals, Thank you Derick. Why should phpdbg scope be limited, and not extended? It's not about limiting the scope of phpdbg, it's about defining it properly. The right tool for the job is what we are talking about. phpdbg will *never* be able to do all the things xdebug can do, and it would ruin it to try. In the same way, there are things phpdbg can do that would further complicate xdebug (or even be impossible), and we shouldn't try that either, obviously. The original scope of a project and what it should be in the future are not always related True, but in this case it does actually matter. You will never be able to load phpdbg in any SAPI and debug any web request in a robust way. It was never intended for that, it is limited, in that sense, because it's a SAPI. Being a SAPI allows us to do things you cannot do in an extension, such as overriding Zend's memory management routines. We have features based on these abilities. I very much agree that we should keep phpdbg within the scope it was designed for. I'm not saying we should not extend the features of phpdbg, but, we should do it knowing what it actually is, knowing that it is fundamentally different to xdebug. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG scope
On Tue, 2014-11-04 at 09:19 +, Lester Caine wrote: On 04/11/14 06:00, Joe Watkins wrote: I'm not saying we should not extend the features of phpdbg, but, we should do it knowing what it actually is, knowing that it is fundamentally different to xdebug. Having just hit another 'white screen' problem on a site I'm trying to update, I do wonder if there is an alternative debug approach that would help speed the process. I have used xdebug in the past, but on the whole the debug tools built into the framework allow fairly quick tracking of a problem and isolating it. If you were to enable xdebug, I am sure it could give you some insight. As could switching all errors to exceptions temporarily, maybe. A white screen often has the root cause suppressed by error_level, executing in the appropriate way in phpdbg would break on errors, telling you where the problem originates, possibly. So the question is ... just where are the strengths of each and is either useful for day to day debugging, or more appropriate for debugging the internal operation of PHP? A considerable strength of a standalone debugger, is that it is standalone :) You don't need an IDE or any other client, a server, or any other software to debug some code, you just need a debugger. We don't deploy code like this however, so while phpdbg might be able to provide some insight in some cases, xdebug is how we debug code that is deployed in a normal server environment. It depends what you do day-to-day, as mentioned, if you are someone comfortable with, or who spends a considerable amount of time in a console, for whatever reason, then phpdbg can certainly be a useful tool. When it comes to debugging our deployments however, nothing has changed. -- 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 Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SAPI refactoring
On Sat, 2014-11-15 at 11:16 +0100, Florian Margaine wrote: Hi list, As of today, most of the SAPIs have a lot of code duplication with regards to HTTP headers parsing/handling. I'm about to completely duplicate a function from one SAPI to the other to add a feature to fpm (`getallheaders()`, see https://github.com/php/php-src/pull/523), and I'd like to avoid that. Should I create a `sapi/main/` folder for common functions across the SAPIs? Or should each SAPI remain completely independent from each other, even if it means duplicating code? Regards, Morning Florian, There is already a place to put shared SAPI code. main/SAPI.h main/SAPI.c There is also a SAPI_API decl that you will need to use. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] [RFC] PHP 7.0 timeline
On Fri, 2014-11-21 at 10:07 +0200, Zeev Suraski wrote: After some Twitter hints that I should get my act together and finally move this to a vote, it’s finally happening: https://wiki.php.net/rfc/php7timeline#vote Cast your vote! Zeev Morning Zeev, Proposed milestones column needs to change from mid October to November. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Native TLS
On Thu, 2014-11-27 at 16:54 +0100, Anatol Belski wrote: Hi, this is a long spoken topic which is now embodied in https://wiki.php.net/rfc/native-tls . A preliminary implementation is there as well, thus we can discuss it. Regards Anatol Afternoon Anatol, w00t That is all :) Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Native TLS
On Thu, 2014-11-27 at 16:44 +, Andrea Faulds wrote: On 27 Nov 2014, at 16:44, Andrea Faulds a...@ajf.me wrote: On 27 Nov 2014, at 15:54, Anatol Belski anatol@belski.net wrote: this is a long spoken topic which is now embodied in https://wiki.php.net/rfc/native-tls . A preliminary implementation is there as well, thus we can discuss it. Hey! Would this mean we could eventually get rid of the treaded TSRMLS_CC/DC altogether? :) Treaded? Dreaded. Sorry. -- Andrea Faulds http://ajf.me/ Afternoon Andrea, Yes, they can be removed, as it mentions in RFC. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New function: spl_object_id() or spl_object_handle()
On Fri, 2014-11-28 at 02:13 +0100, Bostjan Skufca wrote:
Hello everyone,
this is a proposal to add new function to PHP core: spl_object_id()
The story:
Recently I was debugging some larger libraries and sorely missed a function
that would return an object ID. A function called spl_object_hash() exists,
but it returns identical hashes for equal objects. You need object ID to be
really sure if two references are indeed the same object or two identical
objects.
Most of the meat is described in this StackOverflow thread:
http://stackoverflow.com/questions/2872366/get-instance-id-of-an-object-in-php
The OP proposes OB+var_dump() magic, which works if objects are small.
Unfortunatelly I was hitting Allowed memory exceeded.
The second answer, given by Gustavo Lopes, describes how to create an
extension for this, which provides new function, named spl_object_id(). I
believe this function should be included in PHP core.
Sample implementation (not tested):
=
/* {{{ proto string spl_object_id(object obj)
Return id for given object */
PHP_FUNCTION(spl_object_id)
{
zval *obj;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, o, obj) == FAILURE)
{
return;
}
RETURN_LONG(Z_OBJ_HANDLE_P(obj));
}
/* }}} */
Two questions:
1. Do you think this function should be included in PHP core?
2. If so, what should this function be called? I am undecided between
spl_object_id() and spl_object_handle() and corresponding get_...()
variants.
Ad 2. I lean towards ..._id() as ..._handle() suggests that you can do
something with that handle (think open file handle, etc).
What is your opinion about this?
Tnx,
b.
Morning,
I don't think so, there is talk of removing object handles in 7.
Even if we intended to keep object handles, this leaks implementation
details that we don't really want leaked.
Cheers
Joe
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Only variables can be passed by reference
On Sat, 2014-12-06 at 12:03 +0900, Yasuo Ohgaki wrote: Hi Rowan, On Fri, Dec 5, 2014 at 6:12 PM, Rowan Collins rowan.coll...@gmail.com wrote: The author of function f1() presumably designed it to apply some change to $v, rather than executing only for its side effects and return value. If the caller wants to ignore this design, they can, but they are not using the function as it was designed. If they pass a function return straight into it, they have no way of capturing the change to $v which the author intended them to see. The value supplied to f1() is return value. In languages, there are literal, constant and variable. Return value is variable. It's better to keep basic rule. IMHO. $top = array_pop(f2()); is better than $v = f2(); $top = array_pop($v); Is there anyone who likes latter? Are there any other languages behave like PHP? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net A return value that has no references is a temporary variable, you forgot about temporary variables. There is a basic, simple rule; temporary variables cannot be used by reference, which is perfectly logical since there are no references to temporary variables, that's what makes them temporary. I don't see the need to change it. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE][RFC] ZPP Failure on Overflow
On Sun, 2014-12-07 at 22:03 +, Andrea Faulds wrote: Hi! We’re now half-way through voting on this RFC, and only three people, two if I’m excluded, have voted. I realise it’s a rather technical and obscure matter, but I am a little worried by how few people have voted so far. Three votes is hardly enough to justify a change. If you missed the original announcement, hopefully this reminder will reach you. Here it is, repeated: On 2 Dec 2014, at 21:44, Andrea Faulds a...@ajf.me wrote: I’m putting the ZPP Failure on Overflow RFC to a vote. This RFC is an important prerequisite to the Big Integer Support RFC, as it ensures safety in implicit integer parameter conversions. The RFC requires a 2/3 majority, and voting starts today (2014-12-02) and ends in 10 days’ time next Friday (2014-12-12). Please read the RFC carefully. If you have any doubts or queries about the RFC, please don’t hesitate to ask me. The RFC and voting widget can be found here: https://wiki.php.net/rfc/zpp_fail_on_overflow Thanks! -- Andrea Faulds http://ajf.me/ Morning Andrea, I think it's okay to assume that people are winding down for the holiday, possibly some people are already on holiday. Because of the time of year, you might want to leave the vote open another week, or until the number of votes justifies the change. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libsodium for PHP 7?
Evening Scott, We should only consider moving an extension from PECL to core if that extension is in wide use. In addition to having a properly established user base, it's a good idea to have a stable API since the development workflow (or pace) for core extensions is restricted by the release cycle of PHP. Even when an extension has a good userbase and a stable API, it doesn't always make sense to bundle as a core extension, if you look at the top of the list at the extensions with millions of downloads; there's nothing to actually gain from bundling these extensions in the core distribution. So I would say that there needs to be some benefit in terms of integration, maintainability, or something of that sort. libsodium is too young to seriously consider bundling right now I think. Cheers Joe On Fri, Jan 2, 2015 at 5:05 PM, Scott Arciszewski kobrasre...@gmail.com wrote: Hi PHP Internals, Right now, the libsodium PECL package is in the beta channel. Would it be possible to include libsodium as a core extension in PHP 7? If so, what hurdles would need to be cleared before that happens? http://doc.libsodium.org/ http://pecl.php.net/package/libsodium https://github.com/jedisct1/libsodium-php Thanks, Scott P.S. I'm cc'ing Frank Denis on this initial email.
Re: [PHP-DEV] Design by Contract
Morning internals,
I really liked the original idea Dmitry had, with the D-ish syntax.
We could use require and return like:
function foo()
require(input-expr)
return(output-expr) {
/* ... */
}
to avoid adding more keywords.
I'd really appreciate seeing this as an option in the RFC.
Cheers
Joe
On Mon, Feb 9, 2015 at 8:44 AM, Dmitry Stogov dmi...@zend.com wrote:
It's nothing wrong here. It's just a concept that cares about constraints
definition more.
So, DbC with asserts spread among the code is like OOP without classes.
Thanks. Dmitry.
On Mon, Feb 9, 2015 at 2:11 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
Following our conversation, I tried to imagine how DbC should look like
in
PHP from user perspective. Finally, I was influenced by the semantic
proposed in D, and syntax proposed for Java. So, these are my initial
thoughts:
For php it may look like the following:
function foo()
requre(input-assert-expression)
ensure(output-assert-expression)
{
...
}
Why not do it simpler?
function foo() {
// require
assert(input-assert-expression);
...
// ensure
assert(output-assert-expression);
}
I'm oversimplifying a bit, but in general, why we need more places to
have code in the function than the actual code of the function? It would
be harder to parse, to read, to maintain, to debug, to profile, etc. and
I'm not sure what exactly it provides that can't be done by plain
regular code inside the function.
If we're concerned about the costs of assert, we could make special
provision in the compiler for zero-cost asserts. It doesn't require
moving code out of the function.
--
Stas Malyshev
smalys...@gmail.com
Re: [PHP-DEV] RFC: Expectations
Will update RFC today, thanks for working on it Dmitry :) Cheers Joe On Tue, Feb 17, 2015 at 9:50 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Joe The patch is ready https://github.com/php/php-src/pull/1088/files 1) I implemented AST pretty-printer to reconstruct the source. It may be reused in Reflection and other places through ZEND_API zend_string *zend_ast_export(const char *prefix, zend_ast *ast, const char *suffix); 2) zend.assertions=-1 - makes zero-cost asserts 3) assert() in a namespace leads to call a function defined in this namespace (if it's defined), but zend.assertions is still may disable this call or even prevent code generation for it. it's possible to use \assert() to call the system function. Please, make update RFC, add notes about (2) and (3). Then, it should be ready for voting. Nikita, please take a quick look over the patch. I hope, you don't have objections. Thanks. Dmitry. On Tue, Feb 17, 2015 at 6:51 PM, Dmitry Stogov dmi...@zend.com wrote: On Tue, Feb 17, 2015 at 5:11 PM, Nikita Popov nikita@gmail.com wrote: On Mon, Feb 16, 2015 at 4:47 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Nikita, it looks like a part of old implementation is not trivial with new AST compiler. previously we translated assert(condition) into assert(condition, assert(condition)). actually we just captured a part of input buffer and added missing string argument. Is there a simple way to do the same now? Not very simple, but we could store pointers/offsets to the start and end of the fcall in the ast node, similar to what is done with lex_pos for declarations: http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_ast.h#177 It would be nice if we could have precise offset information for all nodes (this is particularly valuable if the ast is exposed to userland), but that would increase memory usage during compilation, not sure if it's worthwhile. It's possible to convert AST into string using recursive pretty-printer. It's not a simple task itself, but it may be reused for other things. I went by this way... :) It must be ready soo. Joe, the rest (including zero-cost assert) is implemented at https://github.com/php/php-src/pull/1088/files 9 related tests are failed for now. As this is implemented right now, it would require writing \assert() in order to be zero-cost. Maybe we should disallow redefinition of assert as a namespaced function, so we can always optimize this? good catch. Thanks. Nikita
Re: [PHP-DEV] RFC: Expectations
Updated RFC as requested. I'm just going to wait to hear what Nikita says, especially about optimizing away unqualified calls to assert. I guess this could be viewed as a BC break, it seems like quite a nice break but not sure. Will open voting when we hear from Nikita. Cheers Joe On Wed, Feb 18, 2015 at 6:23 AM, Joe Watkins pthre...@pthreads.org wrote: Will update RFC today, thanks for working on it Dmitry :) Cheers Joe On Tue, Feb 17, 2015 at 9:50 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Joe The patch is ready https://github.com/php/php-src/pull/1088/files 1) I implemented AST pretty-printer to reconstruct the source. It may be reused in Reflection and other places through ZEND_API zend_string *zend_ast_export(const char *prefix, zend_ast *ast, const char *suffix); 2) zend.assertions=-1 - makes zero-cost asserts 3) assert() in a namespace leads to call a function defined in this namespace (if it's defined), but zend.assertions is still may disable this call or even prevent code generation for it. it's possible to use \assert() to call the system function. Please, make update RFC, add notes about (2) and (3). Then, it should be ready for voting. Nikita, please take a quick look over the patch. I hope, you don't have objections. Thanks. Dmitry. On Tue, Feb 17, 2015 at 6:51 PM, Dmitry Stogov dmi...@zend.com wrote: On Tue, Feb 17, 2015 at 5:11 PM, Nikita Popov nikita@gmail.com wrote: On Mon, Feb 16, 2015 at 4:47 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Nikita, it looks like a part of old implementation is not trivial with new AST compiler. previously we translated assert(condition) into assert(condition, assert(condition)). actually we just captured a part of input buffer and added missing string argument. Is there a simple way to do the same now? Not very simple, but we could store pointers/offsets to the start and end of the fcall in the ast node, similar to what is done with lex_pos for declarations: http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_ast.h#177 It would be nice if we could have precise offset information for all nodes (this is particularly valuable if the ast is exposed to userland), but that would increase memory usage during compilation, not sure if it's worthwhile. It's possible to convert AST into string using recursive pretty-printer. It's not a simple task itself, but it may be reused for other things. I went by this way... :) It must be ready soo. Joe, the rest (including zero-cost assert) is implemented at https://github.com/php/php-src/pull/1088/files 9 related tests are failed for now. As this is implemented right now, it would require writing \assert() in order to be zero-cost. Maybe we should disallow redefinition of assert as a namespaced function, so we can always optimize this? good catch. Thanks. Nikita
Re: [PHP-DEV] RFC: Expectations
Morning, I hear the concern regarding custom exceptions. Things will be used badly whatever. It's easy to imagine that in a simple application you just don't need to specify custom exceptions. But in a large codebase, being able to structure exceptions is invaluable, it gives documentation reference points and makes stack traces easier to read at a glance, because they are more meaningful. So I think we should keep the ability to throw custom exceptions. I agree about making the exception part of a new tree, so that they are not caught, so I'll just wait for that from dmitry and open the vote. Cheers Joe On Wed, Feb 18, 2015 at 5:01 PM, Dmitry Stogov dmi...@zend.com wrote: On Wed, Feb 18, 2015 at 5:44 PM, Nikita Popov nikita@gmail.com wrote: On Tue, Feb 17, 2015 at 10:50 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Joe The patch is ready https://github.com/php/php-src/pull/1088/files 1) I implemented AST pretty-printer to reconstruct the source. It may be reused in Reflection and other places through ZEND_API zend_string *zend_ast_export(const char *prefix, zend_ast *ast, const char *suffix); 2) zend.assertions=-1 - makes zero-cost asserts 3) assert() in a namespace leads to call a function defined in this namespace (if it's defined), but zend.assertions is still may disable this call or even prevent code generation for it. it's possible to use \assert() to call the system function. Please, make update RFC, add notes about (2) and (3). Then, it should be ready for voting. Nikita, please take a quick look over the patch. I hope, you don't have objections. I've added a few comments on the PR. Thank you very much. You found about 25 bugs :) All of them except for elseif should be fixed now. I also think printing else if instead of elseif is not a big problem. Pretty-printer may also add or remove brackets in some situations. Two general notes on the RFC: 1. I don't like the ability to specify a different exception as the second param. Assertions are supposed to be used as sanity checks during development, not to throw meaningful and specialized exception types. Having this possibility will probably only encourage bad usage of assert(). It's not a big problem to me, but I'd rather not have this feature. Joe, this is part of your old patch. I really don't care about it. 2. Similar to the EngineExceptions RFC I'm wondering if AssertionException should extend Exception or be in a separate hierarchy. The same argument as with engine exceptions applies: It's pretty unlikely that you want to catch an AssertionException anywhere apart from top-level error handling code and that people using catch(Exception) blocks would accidentally catch assertions. I'm not sure I agree with this, but I wanted to mentioned the concern. This may be changed together with EngineException patch. I started working on it, and I hope I'll show you results tomorrow. Thanks. Dmitry. Nikita
[PHP-DEV] [VOTE] Expectations
Morning internals, The expectations RFC is now in voting phase: https://wiki.php.net/rfc/expectations#vote Cheers Joe
Re: [PHP-DEV] [VOTE] Expectations
There isn't legitimate technical justification for or against using custom exceptions. Since it's entirely based on preference, and the kind of utilitarian argument you can make for their use, it's acceptable that this is resolved as part of the vote. It's not a huge deal. Cheers Joe On Thu, Feb 19, 2015 at 5:34 PM, Pierre Joye pierre@gmail.com wrote: On Thu, Feb 19, 2015 at 9:13 AM, Leigh lei...@gmail.com wrote: On 19 February 2015 at 15:45, Pierre Joye pierre@gmail.com wrote: Still, no announce for a discussion about this specific RFC. And really, the content of the RFC is almost empty, pointing to the ML archive is really not the right way :) There was an RFC announce thread 3 days ago. I agree 3 days is a short period of time, but the announce thread existed. Maybe it was a reply to DbC with a changed subject and your mail client didn't show it as new? I don't know, there was definitely a thread though. I mentioned that thread in my comment. It is still way behind what should be done when creating a new RFC, let alone pushing it to the vote phase. On 19 February 2015 at 16:06, Pierre Joye pierre@gmail.com wrote: I like the concept and idea but still not sure about the custom exception vs AssertException. Looking at the implementation, it seems that the custom exception still has to descend from AssertException https://github.com/php/php-src/pull/1088/files#diff-232f2dffbb06c0b6004724d8a498e7e7R248 That seems like a good restriction to me. You can still catch everything with AssertException but you can make it more specific if you want. I did not comment on what should be done, while I do consider this open question as a blocker to actually take a good decision for this RFC. I do think it should be discussed, answered and voted either at the same time or before this RFC. -- Pierre @pierrejoye | http://www.libgd.org
Re: [PHP-DEV] Switch jumptable optimization
Very clever ... thanks bob :) Cheers Joe On Tue, Feb 17, 2015 at 6:46 AM, Dmitry Stogov dmi...@zend.com wrote: On Tue, Feb 17, 2015 at 2:04 AM, Bob Weinand bobw...@hotmail.com wrote: I'd like to show you my recent work on a jumptable optimization for switches. https://github.com/php/php-src/pull/1048 https://github.com/php/php-src/pull/1048 It is a fully transparent optimization of switches, by putting a new ZEND_SWITCH opcode at the top of the switch in case we can build a jumptable, which is the case if the cases are only scalars (no doubles) or evaluate to them at compile-time. Switches tend to be big sometimes with a lot of static (literals or constants usually) cases, which was a comparison for each case, and now just a simple hashtable lookup is needed, which greatly improves performance. In case where the result of the switch can be determined at compile-time, it even replaces the comparisons with a simple ZEND_JMP opcode. In synthetic benchmarks the results are mind blowing, but in practice, benefits mostly are stateful userland parsers (often called with sometimes big switches), where it makes it a few percent faster. (For more concrete numbers see https://github.com/php/php-src/pull/1048#issuecomment-73032647 ) As the optimization is only done if there are 3 or more cases, the lookup is always faster than the single comparisons. So there's no negative performance impact. It already works, except with opcache where the CFG optimization pass still lacks support. Dmitry or Laruence volunteered to add support for opcache. I'd like to know if there are any technical objections to the PR. If not, they will add opcache support and merge it in. Thanks, Bob The patch looks interesting. We will implement support for opcache and then analyze its impact on performance. I see it as a self-containing feature that won't affect anyone (except opcache and may be debuggers). I'm not going to work on it in nearest days or weeks, because of more critical tasks. Thanks. Dmitry.
