Re: [PHP-DEV] Bug 55544
Hi, comments inline. Am 17.07.2012 18:57, schrieb Stas Malyshev: There's no version 5.4.4-1. The patch was 85a62e9086db7a8ddfcda4ab1279a2439935f8d5 merged but since then there were other changes to the code. Mike, could you please check if we have a regression there? OK, someone in the bug report refers to this version. Christian, if you are seeing the error again, please reopen the bug and add information about what you are seeing, with which code and on which OS, environment, etc. I'm not the original author of the bug report, so I can't reopen it. But there exists an open bug report for the same issue. So I will comment on this report. https://bugs.php.net/bug.php?id=62335 Thank you for your effort. Cheers, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
hi! On Tue, Jul 17, 2012 at 10:30 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Having pure object would be not efficient enough and brings its lot of caveats. Also it is important to keep in mind that this idea does not apply only to array but to other types as well. Same for other types. Just adding - doesn't make the code object-oriented. Not the point. And just bolting - on top of regular function calls because it looks prettier seems meaningless to me. OK, we could make $foo-bar() mean bar($foo) - python already has pretty much the same idea, after all - but what's the point in it? I don't see any that would be worth the effort. See the other answers, clear APIs, no more argument mess, cleanness. Those are pretty good selling points and without any kind of BC. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
Hi! See the other answers, clear APIs, no more argument mess, cleanness. Cleanness has nothing to do with pseudo-objects. You don't have to use - to have clean APIs, and using - doesn't automatically make your APIs clean. Using - has absolutely nothing to do with API cleanness and arguments, so I don't understand how it's an argument for pseudo-objects. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
hi, On Wed, Jul 18, 2012 at 9:35 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! See the other answers, clear APIs, no more argument mess, cleanness. Cleanness has nothing to do with pseudo-objects.You don't have to use - to have clean APIs, and using - doesn't automatically make your APIs clean. I really do not want to have a semantic discussion here. This syntax is sexy, allows us to clean our APIs, and is amazingly handy. The reasons why it is not yet implemented have been listed here, only a matter of time :) Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
Hi! I really do not want to have a semantic discussion here. This syntax is sexy, allows us to clean our APIs, and is amazingly handy. I'm sorry, but I can't understand how we can seriously consider making object call syntax mean two entirely different things, create pseudo-objects that look like objects in some situations, but not other situation and generally make a huge mess out of whole object model - because - is sexy. Is this really a level we want to have in the discussion? And no, it does not allow us to clean our APIs - I again point out using - has nothing to do with cleaning APIs. Repeating clean APIs as if it is some magic spell will not make false statement true, and the statement that using - somehow cleans up APIs is false. Cleaning APIs and pseudo-objects are two completely different things, and nobody yet shown any relationship between the two. The reasons why it is not yet implemented have been listed here, only a matter of time :) IMHO the reason it's not implemented is because it makes very little sense, and only reason I've seen so far to do it is because it's sexy. Come on. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
hi, On Wed, Jul 18, 2012 at 10:13 AM, Stas Malyshev smalys...@sugarcrm.com wrote: And no, it does not allow us to clean our APIs - I again point out using - has nothing to do with cleaning APIs. Repeating clean APIs as if it is some magic spell will not make false statement true, and the statement that using - somehow cleans up APIs is false. Cleaning APIs and pseudo-objects are two completely different things, and nobody yet shown any relationship between the two. You do not see it, your call. But it indeed does and anyone I was talking to about this topic agrees with this view but two persons (you incl.). Anyway, it is somehow pointless to argue to death about that as it is technically not possible yet. I'm 200% sure it will happen. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
Stas Malyshev wrote: I really do not want to have a semantic discussion here. This syntax is sexy, allows us to clean our APIs, and is amazingly handy. I'm sorry, but I can't understand how we can seriously consider making object call syntax mean two entirely different things, create pseudo-objects that look like objects in some situations, but not other situation and generally make a huge mess out of whole object model - because - is sexy. Is this really a level we want to have in the discussion? And no, it does not allow us to clean our APIs - I again point out using - has nothing to do with cleaning APIs. Repeating clean APIs as if it is some magic spell will not make false statement true, and the statement that using - somehow cleans up APIs is false. Cleaning APIs and pseudo-objects are two completely different things, and nobody yet shown any relationship between the two. The reasons why it is not yet implemented have been listed here, only a matter of time:) IMHO the reason it's not implemented is because it makes very little sense, and only reason I've seen so far to do it is because it's sexy. Come on. Seconded ... ArrayObject class is available if you want the 'sexy' way of doing things but that adds nothing of use to the debate? My suggestion that the same is done for mbstring seems to have fallen on deaf ears, but both of these would answer some of the requests without affecting the core? The current debate seems to be one of 'php is crap lets rewrite all of it', but how much of the worlds online infrastructure is currently running using PHP and in a lot of cases PHP4? We have compiled forks with different syntaxes if people want to go that way, and yes we can stay with old versions, but we need reliable security maintenance on some legacy base. Please can we keep a 'legacy' version of PHP stable at some point in time ... And let SonofPHP be forked off if that is what people want. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
hi, On Wed, Jul 18, 2012 at 11:24 AM, Lester Caine les...@lsces.co.uk wrote: Please can we keep a 'legacy' version of PHP stable at some point in time ... And let SonofPHP be forked off if that is what people want. Totally off topic, and as stated earlier, this solution does not break any existing functions or features. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 6.0 And Moving Forward
For a new version to be successful from a marketing perspective, there has to be such a thing as good old code. Just as there are PHP 4 apps that are basically sound and maintainable code and require only a few reasonable changes to run well in PHP 5, that needs to be true for the transition to 5 to 6. Otherwise it just won't be accepted as PHP by most people. If I have to start from scratch, I guess I'll just use Ruby would be a very reasonable response (: I do like the idea of pseudo-objects with methods as a way to create much cleaner APIs for strings and arrays, but the legacy APIs need to stick around. On Tue, Jul 17, 2012 at 7:16 PM, David Muir davidkm...@gmail.com wrote: Took the words from my mouth. Removing legacy support is a terrible idea for PHP6. It makes it impossible to write forwards compatible code that currently runs in PHP5. Even having it optional is a bad idea IMO since it will fragment PHP hosting. Some will be able to run PHP6 only (no legacy), some will be able to run PHP5+ but will still be marketed as PHP6. Makes it that much harder to know if your code will run on a client's server. David On 18/07/12 00:04, Anthony Ferrara wrote: I dislike this idea from the ground up. While I think having a legacy implementation is definitely worth while, it needs to be in core. So PHP6 would introduce the new syntax, and include the legacy functionality in as close to 100% backwards compatible way as possible. From there, we'd only remove the legacy functionality from core in 7 (which could be 4 or 5 years out). We don't want to be in the same situation with 6 that python was in with 3, and perl was in 5. We want to encourage adoption. Having a PECL extension needed for adoption is not going to fly too well. But if we can add the new functionality and give people an easy migration path, adoption will be easier. It still may take years, but it will at least be fairly smooth as the majority of existing code will still work. Of course some BC breaks may be necessary (a-la what happened with PHP5), but they should be fairly localized and pretty easy to handle... And they should be justified (breaking BC for the sake of it, as with these legacy functions, would be a mistake)... My $0.02 at least. Anthony On Tue, Jul 17, 2012 at 9:41 AM, Andrew Faulds ajf...@googlemail.comwrote: This is an excellent idea. Full BC yet without legacy cruft. Old code runs on legacy support extensions, new code doesn't need it. On Jul 17, 2012 1:51 PM, Leigh lei...@gmail.com wrote: Basically, the current function library is moved to the legacy namespace. The default setting is import the functions of the legacy namespace into the root namespace for BC. But with that setting turned off all the existing functions go away to be replaced with a designed API, instead of a grown one, correcting the mistakes that have accumulated over the years. Is there any reason why this cannot / should not be implemented as a PHP 5 compatibility extension? I think those who never want to use it (PHP 6 purists) shouldn't have to have their binaries bloated by legacy code. It would also mean that the legacy implementation can be developed away from the new core, and not have any (negative) influence on it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Implicit isset in ternary operator
Hey Everyone, With the syntax improvements for 5.4 and some of the de-referencing work, code looks so much sleeker then before, but there is still one use case that really bugs me. Given this code: $width = (isset($config['width']))? $config['width'] : 300; The code is pretty straight forward, if width is set in the array, use it otherwise use 300. This code would look much better if it could make use of the ternary operator $width = $config['width'] ?: 300; The only reason for this to not work is: it throws a notice if the array key is not there (which is the case we are covering anyway) This is basically because the ternary operator does not do a internal implicit isset, only an empty. Does this seem like a possible improvement we can work on? Anyone interested in championing the change? -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br
Re: [PHP-DEV] Implicit isset in ternary operator
Rafael, One point of clarity: On Wed, Jul 18, 2012 at 10:15 AM, Rafael Dohms lis...@rafaeldohms.com.brwrote: Hey Everyone, With the syntax improvements for 5.4 and some of the de-referencing work, code looks so much sleeker then before, but there is still one use case that really bugs me. Given this code: $width = (isset($config['width']))? $config['width'] : 300; The code is pretty straight forward, if width is set in the array, use it otherwise use 300. This code would look much better if it could make use of the ternary operator $width = $config['width'] ?: 300; The only reason for this to not work is: it throws a notice if the array key is not there (which is the case we are covering anyway) This is basically because the ternary operator does not do a internal implicit isset, only an empty. It does not do an empty. Empty would avoid notices as well. All it does is an implicit bool cast... Does this seem like a possible improvement we can work on? Anyone interested in championing the change? I like it in principle. My only concern is *why* wasn't it done this way in the first place... Is there a reason? Anthony
Re: [PHP-DEV] Implicit isset in ternary operator
On Wed, Jul 18, 2012 at 4:20 PM, Anthony Ferrara ircmax...@gmail.comwrote: Does this seem like a possible improvement we can work on? Anyone interested in championing the change? I like it in principle. My only concern is *why* wasn't it done this way in the first place... Is there a reason? I don't recall correctly, there was a thread on this by David Coalier some time ago, but it went completely off course and i remember BC breaks were part of the reason. I think we have a good plan for BC breaks now, so why not rethink this. Anthony -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br
Re: [PHP-DEV] 6.0 And Moving Forward
To avoid BC breaks we should try to avoid major syntax changes. We could make new applications hide legacy though, something like use new; which would remove deprecated and legacy functions from the global namespace. On Jul 18, 2012 12:16 AM, David Muir davidkm...@gmail.com wrote: Took the words from my mouth. Removing legacy support is a terrible idea for PHP6. It makes it impossible to write forwards compatible code that currently runs in PHP5. Even having it optional is a bad idea IMO since it will fragment PHP hosting. Some will be able to run PHP6 only (no legacy), some will be able to run PHP5+ but will still be marketed as PHP6. Makes it that much harder to know if your code will run on a client's server. David On 18/07/12 00:04, Anthony Ferrara wrote: I dislike this idea from the ground up. While I think having a legacy implementation is definitely worth while, it needs to be in core. So PHP6 would introduce the new syntax, and include the legacy functionality in as close to 100% backwards compatible way as possible. From there, we'd only remove the legacy functionality from core in 7 (which could be 4 or 5 years out). We don't want to be in the same situation with 6 that python was in with 3, and perl was in 5. We want to encourage adoption. Having a PECL extension needed for adoption is not going to fly too well. But if we can add the new functionality and give people an easy migration path, adoption will be easier. It still may take years, but it will at least be fairly smooth as the majority of existing code will still work. Of course some BC breaks may be necessary (a-la what happened with PHP5), but they should be fairly localized and pretty easy to handle... And they should be justified (breaking BC for the sake of it, as with these legacy functions, would be a mistake)... My $0.02 at least. Anthony On Tue, Jul 17, 2012 at 9:41 AM, Andrew Faulds ajf...@googlemail.com wrote: This is an excellent idea. Full BC yet without legacy cruft. Old code runs on legacy support extensions, new code doesn't need it. On Jul 17, 2012 1:51 PM, Leigh lei...@gmail.com wrote: Basically, the current function library is moved to the legacy namespace. The default setting is import the functions of the legacy namespace into the root namespace for BC. But with that setting turned off all the existing functions go away to be replaced with a designed API, instead of a grown one, correcting the mistakes that have accumulated over the years. Is there any reason why this cannot / should not be implemented as a PHP 5 compatibility extension? I think those who never want to use it (PHP 6 purists) shouldn't have to have their binaries bloated by legacy code. It would also mean that the legacy implementation can be developed away from the new core, and not have any (negative) influence on it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Docs: php.ini vs. parse_ini_file()
Sounds good, search engines aren't always super smart. On Jul 18, 2012 1:20 AM, Kris Craig kris.cr...@gmail.com wrote: I just noticed something that I hadn't really thought about before. I couldn't remember the name of the function for parsing INI files so I did a quick search. It took me straight to the page for php.ini directives. I had to select online documentation from the dropdown and try again, this time navigating down to the third result. Not overly cumbersome, of course, but I started thinking that maybe this could be more difficult for someone who might be newer to PHP. I also tried a Google search for 'php ini' (no quotes) to see what I'd get, and the first 15 results (all of the first page and the top half of the second) were for php.ini stuff. The 16th result was finally the parse_ini_file() function. A lot of newbies in particular use Google as their first stop when trying to find PHP functions for doing stuff, so this could give some people the impression that PHP doesn't even have an INI parsing function. Of course, most of this we really have no control over, but I would like to propose adding a link to parse_ini_file() on the php.ini man pages (perhaps something along the lines of, Are you looking for?). I can make the edits myself but I'd like to see what y'all think first. --Kris
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
OK, ok. Let me clear some things up here. We don't want it to make things more object-oriented or whatever. The real motivation is to give us a chance to make a much cleaner, much nicer array API without breaking BC. We can keep the legacy array_* and unprefixed functions, but we can also create pseudo-object methods (not objects, but methods and possibly properties hooked into the method call processing, checking for non-object types - it's very easy to check (I've done it) for non-objects, and implementing this seems simple enough but I don't know the Zend engine well enough). This way we can have array-key, array-sort(TYPE), etc. for new code to use, instead of the legacy array and string method mess (the latter needs a cleanup more in particular). OK? On Jul 18, 2012 10:14 AM, Pierre Joye pierre@gmail.com wrote: hi, On Wed, Jul 18, 2012 at 10:13 AM, Stas Malyshev smalys...@sugarcrm.com wrote: And no, it does not allow us to clean our APIs - I again point out using - has nothing to do with cleaning APIs. Repeating clean APIs as if it is some magic spell will not make false statement true, and the statement that using - somehow cleans up APIs is false. Cleaning APIs and pseudo-objects are two completely different things, and nobody yet shown any relationship between the two. You do not see it, your call. But it indeed does and anyone I was talking to about this topic agrees with this view but two persons (you incl.). Anyway, it is somehow pointless to argue to death about that as it is technically not possible yet. I'm 200% sure it will happen. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implicit isset in ternary operator
On Wed, 18 Jul 2012 16:15:44 +0200, Rafael Dohms wrote: With the syntax improvements for 5.4 and some of the de-referencing work, code looks so much sleeker then before, but there is still one use case that really bugs me. Given this code: $width = (isset($config['width']))? $config['width'] : 300; Do we have to do this again?... We had this discussion an year ago. See http://grokbase.com/t/php/php-internals/113zbx5y77/implicit-isset-isempty-check-on-short-ternary-operator http://grokbase.com/t/php/php-internals/114br1w6gs/proposed-access-modifier-silent-was-re-php-dev-implicit-isset-isempty-check-on-short-ternary-operator -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implicit isset in ternary operator
Sounds good. CoffeeScript (a lightweight language with JS semantics that compiles to JS) has a existential operator, ?, and this looks similar and would be very nice. It's not the same thing, of course. It also reminds me of JavaScript's || behaviour. On Jul 18, 2012 3:24 PM, Rafael Dohms lis...@rafaeldohms.com.br wrote: On Wed, Jul 18, 2012 at 4:20 PM, Anthony Ferrara ircmax...@gmail.com wrote: Does this seem like a possible improvement we can work on? Anyone interested in championing the change? I like it in principle. My only concern is *why* wasn't it done this way in the first place... Is there a reason? I don't recall correctly, there was a thread on this by David Coalier some time ago, but it went completely off course and i remember BC breaks were part of the reason. I think we have a good plan for BC breaks now, so why not rethink this. Anthony -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br
[PHP-DEV] [RFC] foreach_variable supporting T_LIST
Hi:
this is not a new RFC, I proposed it before, but due to my poor
english and improper examples, it didn't get passed.
This feature introduces list() support in foreach constructs(more
info can be found here: https://wiki.php.net/rfc/foreachlist):
?php
$users = array(
array('Foo', 'Bar'),
array('Baz', 'Qux');
);
// Before
foreach ($users as $user) {
list($firstName, $lastName) = $user;
echo First name: $firstName, last name: $lastName. ;
}
// After
foreach ($users as list($firstName, $lastName)) {
echo First name: $firstName, last name: $lastName. ;
}
?
what do you think? personally, I really think it's a good feature.
what about commit this into trunk(php 5.5) ?
thanks
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] foreach_variable supporting T_LIST
Sounds great. Python has something similar for tuples, would be good if PHP
had this.
Are there any BC concerns? Don't see why this could break something.
On Jul 18, 2012 3:50 PM, Laruence larue...@php.net wrote:
Hi:
this is not a new RFC, I proposed it before, but due to my poor
english and improper examples, it didn't get passed.
This feature introduces list() support in foreach constructs(more
info can be found here: https://wiki.php.net/rfc/foreachlist):
?php
$users = array(
array('Foo', 'Bar'),
array('Baz', 'Qux');
);
// Before
foreach ($users as $user) {
list($firstName, $lastName) = $user;
echo First name: $firstName, last name: $lastName. ;
}
// After
foreach ($users as list($firstName, $lastName)) {
echo First name: $firstName, last name: $lastName. ;
}
?
what do you think? personally, I really think it's a good feature.
what about commit this into trunk(php 5.5) ?
thanks
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Call for voting: [RFC] Allow use T_AS in closure use statement
Hi: Call for voting for Allow use T_AS in closure use statement, https://wiki.php.net/rfc/useas#voting any comment will be appreciated. thanks -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] foreach_variable supporting T_LIST
On Wed, Jul 18, 2012 at 10:49 PM, Laruence larue...@php.net wrote:
Hi:
this is not a new RFC, I proposed it before, but due to my poor
english and improper examples, it didn't get passed.
thanks phidev's good english, he re-wrote the descriptions.
thanks
This feature introduces list() support in foreach constructs(more
info can be found here: https://wiki.php.net/rfc/foreachlist):
?php
$users = array(
array('Foo', 'Bar'),
array('Baz', 'Qux');
);
// Before
foreach ($users as $user) {
list($firstName, $lastName) = $user;
echo First name: $firstName, last name: $lastName. ;
}
// After
foreach ($users as list($firstName, $lastName)) {
echo First name: $firstName, last name: $lastName. ;
}
?
what do you think? personally, I really think it's a good feature.
what about commit this into trunk(php 5.5) ?
thanks
--
Laruence Xinchen Hui
http://www.laruence.com/
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call for voting: [RFC] Allow use T_AS in closure use statement
I missed the discussion on this one, the RFC examples are very simple. Does it support aliasing array indices? For example: (use $matches[0] as $name) On Jul 18, 2012 3:55 PM, Laruence larue...@php.net wrote: Hi: Call for voting for Allow use T_AS in closure use statement, https://wiki.php.net/rfc/useas#voting any comment will be appreciated. thanks -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call for voting: [RFC] Allow use T_AS in closure use statement
On Wed, Jul 18, 2012 at 11:19 PM, Leigh lei...@gmail.com wrote: I missed the discussion on this one, the RFC examples are very simple. Does it support aliasing array indices? For example: (use $matches[0] as $name) sorry, no, it's only support literal variable for now. thanks On Jul 18, 2012 3:55 PM, Laruence larue...@php.net wrote: Hi: Call for voting for Allow use T_AS in closure use statement, https://wiki.php.net/rfc/useas#voting any comment will be appreciated. thanks -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
Seems a lot like another syntactic sugar. Like in Lua, where you can write obj:method(12) instead of obj.method(obj, 12) But OOP-like syntax on non-object data is still weird. The question about data manipulation behavior (is it a pointer like other objects or is it a scalar like existing array?) is a tough one. 2012/7/18 Andrew Faulds ajf...@googlemail.com OK, ok. Let me clear some things up here. We don't want it to make things more object-oriented or whatever. The real motivation is to give us a chance to make a much cleaner, much nicer array API without breaking BC. We can keep the legacy array_* and unprefixed functions, but we can also create pseudo-object methods (not objects, but methods and possibly properties hooked into the method call processing, checking for non-object types - it's very easy to check (I've done it) for non-objects, and implementing this seems simple enough but I don't know the Zend engine well enough). This way we can have array-key, array-sort(TYPE), etc. for new code to use, instead of the legacy array and string method mess (the latter needs a cleanup more in particular). OK? On Jul 18, 2012 10:14 AM, Pierre Joye pierre@gmail.com wrote: hi, On Wed, Jul 18, 2012 at 10:13 AM, Stas Malyshev smalys...@sugarcrm.com wrote: And no, it does not allow us to clean our APIs - I again point out using - has nothing to do with cleaning APIs. Repeating clean APIs as if it is some magic spell will not make false statement true, and the statement that using - somehow cleans up APIs is false. Cleaning APIs and pseudo-objects are two completely different things, and nobody yet shown any relationship between the two. You do not see it, your call. But it indeed does and anyone I was talking to about this topic agrees with this view but two persons (you incl.). Anyway, it is somehow pointless to argue to death about that as it is technically not possible yet. I'm 200% sure it will happen. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
It would probably be passed as first param to functions, or passed as $this, like other methods. On Jul 18, 2012 4:27 PM, Amaury Bouchard ama...@amaury.net wrote: Seems a lot like another syntactic sugar. Like in Lua, where you can write obj:method(12) instead of obj.method(obj, 12) But OOP-like syntax on non-object data is still weird. The question about data manipulation behavior (is it a pointer like other objects or is it a scalar like existing array?) is a tough one. 2012/7/18 Andrew Faulds ajf...@googlemail.com OK, ok. Let me clear some things up here. We don't want it to make things more object-oriented or whatever. The real motivation is to give us a chance to make a much cleaner, much nicer array API without breaking BC. We can keep the legacy array_* and unprefixed functions, but we can also create pseudo-object methods (not objects, but methods and possibly properties hooked into the method call processing, checking for non-object types - it's very easy to check (I've done it) for non-objects, and implementing this seems simple enough but I don't know the Zend engine well enough). This way we can have array-key, array-sort(TYPE), etc. for new code to use, instead of the legacy array and string method mess (the latter needs a cleanup more in particular). OK? On Jul 18, 2012 10:14 AM, Pierre Joye pierre@gmail.com wrote: hi, On Wed, Jul 18, 2012 at 10:13 AM, Stas Malyshev smalys...@sugarcrm.com wrote: And no, it does not allow us to clean our APIs - I again point out using - has nothing to do with cleaning APIs. Repeating clean APIs as if it is some magic spell will not make false statement true, and the statement that using - somehow cleans up APIs is false. Cleaning APIs and pseudo-objects are two completely different things, and nobody yet shown any relationship between the two. You do not see it, your call. But it indeed does and anyone I was talking to about this topic agrees with this view but two persons (you incl.). Anyway, it is somehow pointless to argue to death about that as it is technically not possible yet. I'm 200% sure it will happen. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] pdo_odbc: fix pdo_odbc_error's use of SQLGetDiagRec()
The state parameter passed to SQLGetDiagRec() needs to be six bytes
not 5; the attached patch fixes this, from Martin Osvald.
diff --git a/ext/pdo_odbc/odbc_driver.c b/ext/pdo_odbc/odbc_driver.c
index 84a147b..ca2808c 100755
--- a/ext/pdo_odbc/odbc_driver.c
+++ b/ext/pdo_odbc/odbc_driver.c
@@ -114,7 +114,7 @@ void pdo_odbc_error(pdo_dbh_t *dbh, pdo_stmt_t *stmt,
PDO_ODBC_HSTMT statement,
* diagnostic records (which can be generated by PRINT statements
* in the query, for instance). */
while (rc == SQL_SUCCESS || rc == SQL_SUCCESS_WITH_INFO) {
- char discard_state[5];
+ char discard_state[6];
char discard_buf[1024];
SQLINTEGER code;
rc = SQLGetDiagRec(htype, eh, recno++, discard_state, code,
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
Hi! enough but I don't know the Zend engine well enough). This way we can have array-key, array-sort(TYPE), etc. for new code to use, instead of the legacy array and string method mess (the latter needs a cleanup more in particular). The mess does not exist because we have array_key() instead of array-key(). There's nothing wrong with having array_key(). The mess exists because functions do not form single API with single principle behind it, but were added in ad-hoc manner, sometimes without correlating them with others. So, if you want to clean it up, you'd want to write a plan how new API would look like and how it will be better than old one. If the solution is let's use - then it's not worth it. The solution that's worth it is let's have this better API and that's where we should start, not with changing array_key() to array-key() and saying now we have clean sexy API. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Docs: php.ini vs. parse_ini_file()
On Wed, Jul 18, 2012 at 1:19 AM, Kris Craig kris.cr...@gmail.com wrote: I just noticed something that I hadn't really thought about before. I couldn't remember the name of the function for parsing INI files so I did a quick search. It took me straight to the page for php.ini directives. I had to select online documentation from the dropdown and try again, this time navigating down to the third result. Not overly cumbersome, of course, but I started thinking that maybe this could be more difficult for someone who might be newer to PHP. I also tried a Google search for 'php ini' (no quotes) to see what I'd get, and the first 15 results (all of the first page and the top half of the second) were for php.ini stuff. The 16th result was finally the parse_ini_file() function. A lot of newbies in particular use Google as their first stop when trying to find PHP functions for doing stuff, so this could give some people the impression that PHP doesn't even have an INI parsing function. Of course, most of this we really have no control over, but I would like to propose adding a link to parse_ini_file() on the php.ini man pages (perhaps something along the lines of, Are you looking for?). I can make the edits myself but I'd like to see what y'all think first. I don't understand why on earth your are mailing the PHP *internal developer mailinglist* with this matter? If you have any improvement suggestions for the documentations: https://edit.php.net -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Docs: php.ini vs. parse_ini_file()
On Wed, Jul 18, 2012 at 1:19 AM, Kris Craig kris.cr...@gmail.com wrote: I just noticed something that I hadn't really thought about before. I couldn't remember the name of the function for parsing INI files so I did a quick search. It took me straight to the page for php.ini directives. I had to select online documentation from the dropdown and try again, this time navigating down to the third result. Not overly cumbersome, of course, but I started thinking that maybe this could be more difficult for someone who might be newer to PHP. I also tried a Google search for 'php ini' (no quotes) to see what I'd get, and the first 15 results (all of the first page and the top half of the second) were for php.ini stuff. The 16th result was finally the parse_ini_file() function. A lot of newbies in particular use Google as their first stop when trying to find PHP functions for doing stuff, so this could give some people the impression that PHP doesn't even have an INI parsing function. Of course, most of this we really have no control over, but I would like to propose adding a link to parse_ini_file() on the php.ini man pages (perhaps something along the lines of, Are you looking for?). I can make the edits myself but I'd like to see what y'all think first. I don't understand why on earth your are mailing the PHP *internal developer mailinglist* with this matter? If you have any improvement suggestions for the documentations: https://edit.php.net -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
hi Stas, On Wed, Jul 18, 2012 at 6:35 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! enough but I don't know the Zend engine well enough). This way we can have array-key, array-sort(TYPE), etc. for new code to use, instead of the legacy array and string method mess (the latter needs a cleanup more in particular). The mess does not exist because we have array_key() instead of array-key(). There's nothing wrong with having array_key(). The mess exists because functions do not form single API with single principle behind it, but were added in ad-hoc manner, sometimes without correlating them with others. So, if you want to clean it up, you'd want to write a plan how new API would look like and how it will be better than old one. If the solution is let's use - then it's not worth it. The solution that's worth it is let's have this better API and that's where we should start, not with changing array_key() to array-key() and saying now we have clean sexy API. Please let me refresh the psat years history of PHP releases. Any attempt to change any kind of function signatures in the core has been rejected for obvious reasons (BC breaks, useless code changes, etc. etc.). So I won't spend a single second to try to propose to rewamp or duplicate functions for the sake of making the signature more consistent with each other, or cleaner. On the hand, this solution allows that, right away, without BC breaks and brings us to the (very) long term goal (actual object for standard types, like in other languages). Now you can totally disregard the benefit of this (purely vaporware right now) solution, but to keep saying that this argument is pointless is not going to bring us any step further, really not. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
WHAT? Er, sorry, accidental capslock. This IS a new API. That was an example. I'm not saying just put - everywhere, I'm saying we can keep array_* and add a new set of - functions which are well-designed, consistent, etc. On Jul 18, 2012 5:35 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! enough but I don't know the Zend engine well enough). This way we can have array-key, array-sort(TYPE), etc. for new code to use, instead of the legacy array and string method mess (the latter needs a cleanup more in particular). The mess does not exist because we have array_key() instead of array-key(). There's nothing wrong with having array_key(). The mess exists because functions do not form single API with single principle behind it, but were added in ad-hoc manner, sometimes without correlating them with others. So, if you want to clean it up, you'd want to write a plan how new API would look like and how it will be better than old one. If the solution is let's use - then it's not worth it. The solution that's worth it is let's have this better API and that's where we should start, not with changing array_key() to array-key() and saying now we have clean sexy API. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
Hi! Er, sorry, accidental capslock. This IS a new API. That was an example. I'm not saying just put - everywhere, I'm saying we can keep array_* and add a new set of - functions which are well-designed, consistent, etc. What this? So far I didn't see any single message discussing anything about any API. All I see is discussing how we should have - syntax working on arrays and strings. IMO this is exactly the wrong place to start, if your goal is to improve the API (if your goal is to have sexy syntax, it's fine but then I do not see this goal as worthy). The right place to start would be the API. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 6.0 And Moving Forward
I'm wondering if we could include method overloading. Will be pretty nice mixing it with scalar type hinting or scalar values as objects On Wed, Jul 18, 2012 at 11:27 AM, Andrew Faulds ajf...@googlemail.comwrote: To avoid BC breaks we should try to avoid major syntax changes. We could make new applications hide legacy though, something like use new; which would remove deprecated and legacy functions from the global namespace. On Jul 18, 2012 12:16 AM, David Muir davidkm...@gmail.com wrote: Took the words from my mouth. Removing legacy support is a terrible idea for PHP6. It makes it impossible to write forwards compatible code that currently runs in PHP5. Even having it optional is a bad idea IMO since it will fragment PHP hosting. Some will be able to run PHP6 only (no legacy), some will be able to run PHP5+ but will still be marketed as PHP6. Makes it that much harder to know if your code will run on a client's server. David On 18/07/12 00:04, Anthony Ferrara wrote: I dislike this idea from the ground up. While I think having a legacy implementation is definitely worth while, it needs to be in core. So PHP6 would introduce the new syntax, and include the legacy functionality in as close to 100% backwards compatible way as possible. From there, we'd only remove the legacy functionality from core in 7 (which could be 4 or 5 years out). We don't want to be in the same situation with 6 that python was in with 3, and perl was in 5. We want to encourage adoption. Having a PECL extension needed for adoption is not going to fly too well. But if we can add the new functionality and give people an easy migration path, adoption will be easier. It still may take years, but it will at least be fairly smooth as the majority of existing code will still work. Of course some BC breaks may be necessary (a-la what happened with PHP5), but they should be fairly localized and pretty easy to handle... And they should be justified (breaking BC for the sake of it, as with these legacy functions, would be a mistake)... My $0.02 at least. Anthony On Tue, Jul 17, 2012 at 9:41 AM, Andrew Faulds ajf...@googlemail.com wrote: This is an excellent idea. Full BC yet without legacy cruft. Old code runs on legacy support extensions, new code doesn't need it. On Jul 17, 2012 1:51 PM, Leigh lei...@gmail.com wrote: Basically, the current function library is moved to the legacy namespace. The default setting is import the functions of the legacy namespace into the root namespace for BC. But with that setting turned off all the existing functions go away to be replaced with a designed API, instead of a grown one, correcting the mistakes that have accumulated over the years. Is there any reason why this cannot / should not be implemented as a PHP 5 compatibility extension? I think those who never want to use it (PHP 6 purists) shouldn't have to have their binaries bloated by legacy code. It would also mean that the legacy implementation can be developed away from the new core, and not have any (negative) influence on it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Atenciosamente, Rafael Kassner
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
Obviously. This is simply the means to provide the new API without breaking BC. If people think this is acceptable then sure, let's plan an API. On Jul 18, 2012 5:54 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Er, sorry, accidental capslock. This IS a new API. That was an example. I'm not saying just put - everywhere, I'm saying we can keep array_* and add a new set of - functions which are well-designed, consistent, etc. What this? So far I didn't see any single message discussing anything about any API. All I see is discussing how we should have - syntax working on arrays and strings. IMO this is exactly the wrong place to start, if your goal is to improve the API (if your goal is to have sexy syntax, it's fine but then I do not see this goal as worthy). The right place to start would be the API. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227
Re: [PHP-DEV] 6.0 And Moving Forward
That would be cool, but couldn't you just detect argument types? On Jul 18, 2012 5:55 PM, Rafael Kassner kass...@gmail.com wrote: I'm wondering if we could include method overloading. Will be pretty nice mixing it with scalar type hinting or scalar values as objects On Wed, Jul 18, 2012 at 11:27 AM, Andrew Faulds ajf...@googlemail.comwrote: To avoid BC breaks we should try to avoid major syntax changes. We could make new applications hide legacy though, something like use new; which would remove deprecated and legacy functions from the global namespace. On Jul 18, 2012 12:16 AM, David Muir davidkm...@gmail.com wrote: Took the words from my mouth. Removing legacy support is a terrible idea for PHP6. It makes it impossible to write forwards compatible code that currently runs in PHP5. Even having it optional is a bad idea IMO since it will fragment PHP hosting. Some will be able to run PHP6 only (no legacy), some will be able to run PHP5+ but will still be marketed as PHP6. Makes it that much harder to know if your code will run on a client's server. David On 18/07/12 00:04, Anthony Ferrara wrote: I dislike this idea from the ground up. While I think having a legacy implementation is definitely worth while, it needs to be in core. So PHP6 would introduce the new syntax, and include the legacy functionality in as close to 100% backwards compatible way as possible. From there, we'd only remove the legacy functionality from core in 7 (which could be 4 or 5 years out). We don't want to be in the same situation with 6 that python was in with 3, and perl was in 5. We want to encourage adoption. Having a PECL extension needed for adoption is not going to fly too well. But if we can add the new functionality and give people an easy migration path, adoption will be easier. It still may take years, but it will at least be fairly smooth as the majority of existing code will still work. Of course some BC breaks may be necessary (a-la what happened with PHP5), but they should be fairly localized and pretty easy to handle... And they should be justified (breaking BC for the sake of it, as with these legacy functions, would be a mistake)... My $0.02 at least. Anthony On Tue, Jul 17, 2012 at 9:41 AM, Andrew Faulds ajf...@googlemail.com wrote: This is an excellent idea. Full BC yet without legacy cruft. Old code runs on legacy support extensions, new code doesn't need it. On Jul 17, 2012 1:51 PM, Leigh lei...@gmail.com wrote: Basically, the current function library is moved to the legacy namespace. The default setting is import the functions of the legacy namespace into the root namespace for BC. But with that setting turned off all the existing functions go away to be replaced with a designed API, instead of a grown one, correcting the mistakes that have accumulated over the years. Is there any reason why this cannot / should not be implemented as a PHP 5 compatibility extension? I think those who never want to use it (PHP 6 purists) shouldn't have to have their binaries bloated by legacy code. It would also mean that the legacy implementation can be developed away from the new core, and not have any (negative) influence on it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Atenciosamente, Rafael Kassner
Re: [PHP-DEV] 6.0 And Moving Forward
It's possible, but we have to write too much code just to identify all possible overloads. If methods are overloaded by their signature, surely the PHP code will be more clean. Well, I'm just wondering if it is possible without start a war, I'm not sure how expensive it could be. On Wed, Jul 18, 2012 at 1:58 PM, Andrew Faulds ajf...@googlemail.comwrote: That would be cool, but couldn't you just detect argument types? On Jul 18, 2012 5:55 PM, Rafael Kassner kass...@gmail.com wrote: I'm wondering if we could include method overloading. Will be pretty nice mixing it with scalar type hinting or scalar values as objects On Wed, Jul 18, 2012 at 11:27 AM, Andrew Faulds ajf...@googlemail.comwrote: To avoid BC breaks we should try to avoid major syntax changes. We could make new applications hide legacy though, something like use new; which would remove deprecated and legacy functions from the global namespace. On Jul 18, 2012 12:16 AM, David Muir davidkm...@gmail.com wrote: Took the words from my mouth. Removing legacy support is a terrible idea for PHP6. It makes it impossible to write forwards compatible code that currently runs in PHP5. Even having it optional is a bad idea IMO since it will fragment PHP hosting. Some will be able to run PHP6 only (no legacy), some will be able to run PHP5+ but will still be marketed as PHP6. Makes it that much harder to know if your code will run on a client's server. David On 18/07/12 00:04, Anthony Ferrara wrote: I dislike this idea from the ground up. While I think having a legacy implementation is definitely worth while, it needs to be in core. So PHP6 would introduce the new syntax, and include the legacy functionality in as close to 100% backwards compatible way as possible. From there, we'd only remove the legacy functionality from core in 7 (which could be 4 or 5 years out). We don't want to be in the same situation with 6 that python was in with 3, and perl was in 5. We want to encourage adoption. Having a PECL extension needed for adoption is not going to fly too well. But if we can add the new functionality and give people an easy migration path, adoption will be easier. It still may take years, but it will at least be fairly smooth as the majority of existing code will still work. Of course some BC breaks may be necessary (a-la what happened with PHP5), but they should be fairly localized and pretty easy to handle... And they should be justified (breaking BC for the sake of it, as with these legacy functions, would be a mistake)... My $0.02 at least. Anthony On Tue, Jul 17, 2012 at 9:41 AM, Andrew Faulds ajf...@googlemail.com wrote: This is an excellent idea. Full BC yet without legacy cruft. Old code runs on legacy support extensions, new code doesn't need it. On Jul 17, 2012 1:51 PM, Leigh lei...@gmail.com wrote: Basically, the current function library is moved to the legacy namespace. The default setting is import the functions of the legacy namespace into the root namespace for BC. But with that setting turned off all the existing functions go away to be replaced with a designed API, instead of a grown one, correcting the mistakes that have accumulated over the years. Is there any reason why this cannot / should not be implemented as a PHP 5 compatibility extension? I think those who never want to use it (PHP 6 purists) shouldn't have to have their binaries bloated by legacy code. It would also mean that the legacy implementation can be developed away from the new core, and not have any (negative) influence on it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Atenciosamente, Rafael Kassner -- Atenciosamente, Rafael Kassner
Re: [PHP-DEV] [PATCH] pdo_odbc: fix pdo_odbc_error's use of SQLGetDiagRec()
On 07/18/2012 08:48 AM, Joe Orton wrote: The state parameter passed to SQLGetDiagRec() needs to be six bytes not 5; the attached patch fixes this, from Martin Osvald. Hi Joe, Is there any chance you can log this in https://bugs.php.net/ and/or submit a pull request at https://github.com/php/php-src ? Chris -- christopher.jo...@oracle.com http://twitter.com/#!/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
2012.07.18. 18:55, Stas Malyshev smalys...@sugarcrm.com ezt írta: Hi! Er, sorry, accidental capslock. This IS a new API. That was an example. I'm not saying just put - everywhere, I'm saying we can keep array_* and add a new set of - functions which are well-designed, consistent, etc. What this? So far I didn't see any single message discussing anything about any API. All I see is discussing how we should have - syntax working on arrays and strings. IMO this is exactly the wrong place to start, if your goal is to improve the API (if your goal is to have sexy syntax, it's fine but then I do not see this goal as worthy). The right place to start would be the API. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Maybe we could introduce a new namespace for the new api instead of turning the new api oop only (or using objects for groupping static stateless functions into objects only to hint that they are working with the same variable types). Combining this with the previously mentioned lets turn namespaces to first class citizens and allowing exporting whole namespaces to the current scope would make it possible to make the new api available in the global scope if needed. Ofc this still would be a huge task to rethink/reshape our current api.
Re: [PHP-DEV] 6.0 And Moving Forward
On Wed, Jul 18, 2012 at 7:27 AM, Andrew Faulds ajf...@googlemail.comwrote: To avoid BC breaks we should try to avoid major syntax changes. Again, why should we be worrying so much about BC breaks on a major version increment? BC breakage is just a fact of life whenever a major version of anything comes out. Because you can't have major improvements without it, I would classify it as a necessary evil. Don't we have a deprecation policy already worked out for this sort of thing? If we can throw an E_DEPRECATED, then do that; otherwise, I'd say just make the change and document it very clearly. People are going to be reluctant to switch to a new major version anyway; there are still a lo t of people who use PHP 4. There's already an expectation that there will be significant BC breaks. I think we're just shooting ourselves in the foot if we keep trying to run away from that. It's either that or we let the language stagnate indefinitely. If it's better, people will adopt. It'll just take time and convincing, but that's also just something that comes with the territory I think. --Kris
Re: [PHP-DEV] Docs: php.ini vs. parse_ini_file()
I don't understand why on earth your are mailing the PHP *internal developer mailinglist* with this matter? If you have any improvement suggestions for the documentations: https://edit.php.net -Hannes I've seen the docs discussed on this list plenty of times. We do maintain those as well as the code, after all. Unless you're proposing changing the name of this list to *internal *code* developer mailinglist*, then I really don't think there's reason to get butthurt over it. --Kris
Re: [PHP-DEV] Docs: php.ini vs. parse_ini_file()
On Wed, Jul 18, 2012 at 7:26 PM, Kris Craig kris.cr...@gmail.com wrote: I don't understand why on earth your are mailing the PHP *internal developer mailinglist* with this matter? If you have any improvement suggestions for the documentations: https://edit.php.net -Hannes I've seen the docs discussed on this list plenty of times. We do maintain those as well as the code, after all. Unless you're proposing changing the name of this list to *internal code developer mailinglist*, then I really don't think there's reason to get butthurt over it. I cannot say I have seen a single patch from you to the documentations. And every subproject of PHP.net has its own list, in this case php...@lists.php.net And yes. That is _exactly_ what this list is for; the internal code. This list gets crapload of weird spam, and there are very few people from phpdoc@ that have the time to read all threads here to spot doc discussions. Use the correct list. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
hi, On Wed, Jul 18, 2012 at 7:50 PM, Ferenc Kovacs tyr...@gmail.com wrote: Maybe we could introduce a new namespace for the new api instead of turning the new api oop only (or using objects for groupping static stateless functions into objects only to hint that they are working with the same variable types). Combining this with the previously mentioned lets turn namespaces to first class citizens and allowing exporting whole namespaces to the current scope would make it possible to make the new api available in the global scope if needed. Ofc this still would be a huge task to rethink/reshape our current api. This falls almost exactly to what I would avoid to do, having same set of functions but with new names or signatures, under a separate namespace. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
On 07/18/2012 01:02 AM, Pierre Joye wrote: hi, On Wed, Jul 18, 2012 at 9:35 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! See the other answers, clear APIs, no more argument mess, cleanness. Cleanness has nothing to do with pseudo-objects.You don't have to use - to have clean APIs, and using - doesn't automatically make your APIs clean. I really do not want to have a semantic discussion here. This syntax is sexy, allows us to clean our APIs, and is amazingly handy. This makes no sense to me either. How does it let us clean the APIs? Can you give an example? I have one: $a = -5; $b = -5; echo $a-abs(); // Outputs 5 echo $b-abs(); // should still output 5 What has been cleaned here over: echo abs($a); echo abs($b); other than being 2 characters longer to type? It's not like you can remove abs() from the string pseudo-object, so you are essentially just taking all the functions in the global namespace and attaching them as a method to every pseudo-object. Is that clean? I think there is something we can do around this, but an argument of it is sexy and clean needs to be backed up with some actual implementation details that make sense. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 6.0 And Moving Forward
Kris, I'd love to break BC a lot and fix things, but it would seriously slow adoption. Fixing *bugs* has stopped people upgrading, imagine how they would react to non-bugs being changed. On Jul 18, 2012 7:21 PM, Kris Craig kris.cr...@gmail.com wrote: On Wed, Jul 18, 2012 at 7:27 AM, Andrew Faulds ajf...@googlemail.comwrote: To avoid BC breaks we should try to avoid major syntax changes. Again, why should we be worrying so much about BC breaks on a major version increment? BC breakage is just a fact of life whenever a major version of anything comes out. Because you can't have major improvements without it, I would classify it as a necessary evil. Don't we have a deprecation policy already worked out for this sort of thing? If we can throw an E_DEPRECATED, then do that; otherwise, I'd say just make the change and document it very clearly. People are going to be reluctant to switch to a new major version anyway; there are still a lo t of people who use PHP 4. There's already an expectation that there will be significant BC breaks. I think we're just shooting ourselves in the foot if we keep trying to run away from that. It's either that or we let the language stagnate indefinitely. If it's better, people will adopt. It'll just take time and convincing, but that's also just something that comes with the territory I think. --Kris
Re: [PHP-DEV] Docs: php.ini vs. parse_ini_file()
On Wed, Jul 18, 2012 at 11:32 AM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Wed, Jul 18, 2012 at 7:26 PM, Kris Craig kris.cr...@gmail.com wrote: I don't understand why on earth your are mailing the PHP *internal developer mailinglist* with this matter? If you have any improvement suggestions for the documentations: https://edit.php.net -Hannes I've seen the docs discussed on this list plenty of times. We do maintain those as well as the code, after all. Unless you're proposing changing the name of this list to *internal code developer mailinglist*, then I really don't think there's reason to get butthurt over it. I cannot say I have seen a single patch from you to the documentations. And every subproject of PHP.net has its own list, in this case php...@lists.php.net And yes. That is _exactly_ what this list is for; the internal code. This list gets crapload of weird spam, and there are very few people from phpdoc@ that have the time to read all threads here to spot doc discussions. Use the correct list. -Hannes And how much spam was added by your whining about my spam, hmm? If you were so concerned about keeping traffic down, one would think you'd have sent a private email instead of complaining to the entire list. And yes, I have contributed to the man pages in the past. Not as frequently as I'd like, but this is part of my effort to improve on that record. Your hostility is hardly constructive in that regard. There are topics that can be appropriate for multiple lists. This is one of them. As I said, there is precedent for people discussing the website on this list and, unless I'm mistaken, there's no documented policy actually excluding internal development of the website from this list. But anyway, I've been criticized for letting myself get dragged into public pissing matches on this list before, so I'll bite my tongue and terminate the conversation here if there's nothing new to add. You've expressed your opinion and I've expressed mine; if you'd like to bicker with me some more, please send me a private email so everybody else doesn't have to read it. --Kris
Re: [PHP-DEV] Implicit isset in ternary operator
On Wed, Jul 18, 2012 at 7:20 AM, Anthony Ferrara ircmax...@gmail.comwrote: On Wed, Jul 18, 2012 at 10:15 AM, Rafael Dohms lis...@rafaeldohms.com.br wrote: [...] This is basically because the ternary operator does not do a internal implicit isset, only an empty. It does not do an empty. Empty would avoid notices as well. All it does is an implicit bool cast... Does this seem like a possible improvement we can work on? Anyone interested in championing the change? I like it in principle. My only concern is *why* wasn't it done this way in the first place... Is there a reason? It changes the semantics. If the variable is set to a falsey value and ?: uses an implicit isset, the value of the expression will be the falsey value. $config['width'] = '' $width = $config['width'] ?: 300 # $width == '' If !empty were used instead of isset, you could preserve semantics ($a ?: dflt = !empty($a) ? $a : dflt).
Re: [PHP-DEV] 6.0 And Moving Forward
On Wed, Jul 18, 2012 at 12:09 PM, Andrew Faulds ajf...@googlemail.comwrote: Kris, I'd love to break BC a lot and fix things, but it would seriously slow adoption. Fixing *bugs* has stopped people upgrading, imagine how they would react to non-bugs being changed. I agree with your point. I guess my thinking is that this is an unavoidable cost of progress, at least on a major version change. Given that the alternative is an increasingly stagnated codebase, IMHO the cost of slower adoption would be the lesser of two evils. --Kris
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
I think there is something we can do around this... Reviewing the php array functions it seems to me that a new API would benefit from some sort of more intuitive organization, possibly around meta concepts specific to use. For example, I want to re-order an array (order is a meta-concept in this description) how I specifically want to re-order the array is a sub-concept or sub-property of this general thought process. If you're following me then an intuitive API would look something like array functions condensed into a small handful of more generalized functions that take an argument to specify their exact behavior. I.e. array_order($my_array, 'sort', 'alpha', 'asc'); as a rough idea or breaking away from the traditional API a bit further array_order-sort($my_array, 'alpha', 'asc'); I'm offering this as a general representation of the idea to organize and condense the API not as a fully flushed out representation of the end result so useful feedback would be around the concept and not the semantics hastily hatched code examples. - Bill
Re: [PHP-DEV] 6.0 And Moving Forward
If there's this big conflict between BC breaks being bad because they discourage adoption and make old code unusable on the one hand, and good because they allow many things to be cleaned up and progress to be made, then why not pursue a three-pronged approach: 1. BC breaks are made wherever it makes sense to make the best PHP 6.0 possible 2. Near-full backwards compatibility is kept as an extension included with the core (a long way down the road, it can be deprecated, moved to PECL, dropped altogether, etc., once the migration is complete and old code has mostly been ported) 3. Build a high-quality tool to convert code automatically to the greatest extent possible One last suggestion is that in order to keep legacy 5.x code (using the compatibility extension) and 6.0 code interoperable, 6.0 should use a slightly modified version of the open tag, for example ?php6 or *php, etc. This satisfies several desires: we don't want an extra line of boilerplate code like 'use PHP 6' to be required in every source file, we want a PHP 5 file to run without modification, and we want a PHP 6 file to be able to include a PHP 5 file without modification, but we don't want PHP 6 to have to be a superset of PHP 5. On Wed, Jul 18, 2012 at 3:27 PM, Kris Craig kris.cr...@gmail.com wrote: On Wed, Jul 18, 2012 at 12:09 PM, Andrew Faulds ajf...@googlemail.comwrote: Kris, I'd love to break BC a lot and fix things, but it would seriously slow adoption. Fixing *bugs* has stopped people upgrading, imagine how they would react to non-bugs being changed. I agree with your point. I guess my thinking is that this is an unavoidable cost of progress, at least on a major version change. Given that the alternative is an increasingly stagnated codebase, IMHO the cost of slower adoption would be the lesser of two evils. --Kris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 6.0 And Moving Forward
use a slightly modified version of the open tag, for example ?php6 or *php, etc. This satisfies several desires: we don't want an extra line of boilerplate code like 'use PHP 6' to be required in every source file, we want a PHP 5 file to run without modification, and we want a PHP 6 file to be able to include a PHP 5 file without modification, but we don't want PHP 6 to have to be a superset of PHP I don't like this idea, and in fact if it's ever implemented I think it should go the other way around. (i.e. use a ?php5 for a 5.x compatibility mode) Mostly because people who want to properly maintain a project will go through the source thoroughly to properly update legacy code, however old legacy code that isn't going to be maintained usually warrants the find and replace method where something like this could make sense... But my point is I'd rather have this option: 3. Build a high-quality tool to convert code automatically to the greatest extent possible Telling the what's incompatible/broken and how to fix it, or do it automagically if possible. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 6.0 And Moving Forward
Chaos will surely be, if we break PHP5 code. It should work without modification. ?php6 is fine, ?php isn't. On Jul 18, 2012 9:34 PM, Daniel Macedo admac...@gmail.com wrote: use a slightly modified version of the open tag, for example ?php6 or *php, etc. This satisfies several desires: we don't want an extra line of boilerplate code like 'use PHP 6' to be required in every source file, we want a PHP 5 file to run without modification, and we want a PHP 6 file to be able to include a PHP 5 file without modification, but we don't want PHP 6 to have to be a superset of PHP I don't like this idea, and in fact if it's ever implemented I think it should go the other way around. (i.e. use a ?php5 for a 5.x compatibility mode) Mostly because people who want to properly maintain a project will go through the source thoroughly to properly update legacy code, however old legacy code that isn't going to be maintained usually warrants the find and replace method where something like this could make sense... But my point is I'd rather have this option: 3. Build a high-quality tool to convert code automatically to the greatest extent possible Telling the what's incompatible/broken and how to fix it, or do it automagically if possible. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 6.0 And Moving Forward
I do like the idea of pseudo-objects with methods as a way to create much cleaner APIs for strings and arrays, but the legacy APIs need to stick around. You don't need to break BC to remove legacy APIs in PHP6. #1. Introduce the new APIs in 5.x and gradually mark the old ones as deprecated, but keep them available. People will write forward-compatible code using the new APIs. #2. 2 years pass before 6.0 is out. #3. Remove the old, already deprecated APIs from 6.0. Simple. Stan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 6.0 And Moving Forward
Chaos will surely be, if we break PHP5 code. It should work without modification. ?php6 is fine, ?php isn't. On Jul 18, 2012 9:34 PM, Daniel Macedo admac...@gmail.com wrote: People are forgetting why we have version numbers. Yes, it's very spectacular to have all the new stuff in a major release, but that's not what major versions are for. Major versions are for BC breaks. And point releases are for BC-compatible new features. Therefore in 5.x releases old and new features should co-exist, and in 6.x the old ones should just go. Otherwise there's no point of using versions *at all*, and PHP can just publish build numbers or dates. Here's a refresher of the rules of versioning: http://semver.org/ Stan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 6.0 And Moving Forward
...er, php5 isn't fine. On Jul 18, 2012 9:34 PM, Daniel Macedo admac...@gmail.com wrote: use a slightly modified version of the open tag, for example ?php6 or *php, etc. This satisfies several desires: we don't want an extra line of boilerplate code like 'use PHP 6' to be required in every source file, we want a PHP 5 file to run without modification, and we want a PHP 6 file to be able to include a PHP 5 file without modification, but we don't want PHP 6 to have to be a superset of PHP I don't like this idea, and in fact if it's ever implemented I think it should go the other way around. (i.e. use a ?php5 for a 5.x compatibility mode) Mostly because people who want to properly maintain a project will go through the source thoroughly to properly update legacy code, however old legacy code that isn't going to be maintained usually warrants the find and replace method where something like this could make sense... But my point is I'd rather have this option: 3. Build a high-quality tool to convert code automatically to the greatest extent possible Telling the what's incompatible/broken and how to fix it, or do it automagically if possible. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 6.0 And Moving Forward
Sure, BC breaks for 6.0, but it worries me. I don't want a Python 3 for PHP 6. Or heck, PHP5 for that matter. On Jul 18, 2012 9:50 PM, Stan Vass sv_for...@fmethod.com wrote: Chaos will surely be, if we break PHP5 code. It should work without modification. ?php6 is fine, ?php isn't. On Jul 18, 2012 9:34 PM, Daniel Macedo admac...@gmail.com wrote: People are forgetting why we have version numbers. Yes, it's very spectacular to have all the new stuff in a major release, but that's not what major versions are for. Major versions are for BC breaks. And point releases are for BC-compatible new features. Therefore in 5.x releases old and new features should co-exist, and in 6.x the old ones should just go. Otherwise there's no point of using versions *at all*, and PHP can just publish build numbers or dates. Here's a refresher of the rules of versioning: http://semver.org/ Stan
[PHP-DEV] zend_parse_parameters() improvements
Some deficiencies in zpp have been constrai
ning the implementation of common scenarios such as 'allow integer or
NULL'* or the more general 'allow different types for an argument'**.
So I propose the changes in this branch:
https://github.com/cataphract/php-src/compare/zpp_improv
Please see the commit messages for the rationale.
*Example:
https://github.com/php/php-src/pull/13
(again more recently on
https://github.com/php/php-src/pull/133 )
**
Example:
http://lxr.php.net/xref/PHP_TRUNK/ext/intl/timezone/timezone_methods.cpp#143
In this case, NULL, int and string are allowed. This would become much
simpler:
if (arg == NULL || Z_TYPE_PP(arg) == IS_NULL) {
se = TimeZone::createEnumeration();
} else {
long l;
char *s;
int s_len;
if (zend_parse_parameter(ZEND_PARSE_PARAMS_QUIET,
1 TSRMLS_DC, arg, l, l) == SUCCESS) {
TimeZone::createEnumeration((int32_t) l);
} else if (zend_parse_parameter(ZEND_PARSE_PARAMS_QUIET,
1 TSRMLS_DC, arg, s, s, s_len) == SUCCESS) {
TimeZone::createEnumeration(s);
} else {
//raise errror
}
}
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
But OOP-like syntax on non-object data is still weird. The question about data manipulation behavior (is it a pointer like other objects or is it a scalar like existing array?) is a tough one. For the user's point of view there is no difference between the passing semantics of numbers/string primitives and objects. Only arrays differ. However we already have ArrayAccess and so on for objects, which creates array-like objects with object passing semantics. So the idea that something that looks like array will have passing semantics like an array is already wrong in PHP. The clarity of passing semantics is not a valid argument against pseudo methods for string/int/float/array primitives. Stan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implicit isset in ternary operator
It changes the semantics. If the variable is set to a falsey value and ?: uses an implicit isset, the value of the expression will be the falsey value. $config['width'] = '' $width = $config['width'] ?: 300 # $width == '' If !empty were used instead of isset, you could preserve semantics ($a ?: dflt = !empty($a) ? $a : dflt). Since this has been discussed before, here's a previous solution with zero of those problems: // A new operator. $width = $config['width'] ?? 300; // Actual behavior of the operator in pseudo code: $width = isset($config['width']) ? $config['width'] : 300; Why wasn't it implemented? No reason, it just wasn't. But people keep asking about it, so it's only a matter of time. Stan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implicit isset in ternary operator
On Wed, Jul 18, 2012 at 12:21 PM, Galen Wright-Watson ww.ga...@gmail.comwrote:
On Wed, Jul 18, 2012 at 7:20 AM, Anthony Ferrara ircmax...@gmail.comwrote:
On Wed, Jul 18, 2012 at 10:15 AM, Rafael Dohms lis...@rafaeldohms.com.br
wrote:
[...]
This is basically because the ternary operator does not do a internal
implicit isset, only an empty.
It does not do an empty. Empty would avoid notices as well. All it does is
an implicit bool cast...
Does this seem like a possible improvement we can work on? Anyone
interested in championing the change?
I like it in principle. My only concern is *why* wasn't it done this way
in
the first place... Is there a reason?
It changes the semantics. If the variable is set to a falsey value and ?:
uses an implicit isset, the value of the expression will be the falsey
value.
$config['width'] = ''
$width = $config['width'] ?: 300
# $width == ''
If !empty were used instead of isset, you could preserve semantics ($a ?:
dflt = !empty($a) ? $a : dflt).
However, this would break if someone were to use an explicit isset, so ?:
could only use an implicit !empty if the expression isn't an isset
expression (which starts to get messy, grammar-wise).
Looking over the previous discussion, people objected to altering the
behavior of ?: precisely because it currently generates notices, which they
desire.
The following use-cases were put forward as commonly occurring and verbose
enough to desire syntactic sugar:
1. isset($arr['key']) ? $arr['key'] : dflt
2. ! empty($arr['key']) ? $arr['key'] : dflt
3. ! is_null($arr['key']) ? $arr['key'] : dflt (used instead of isset
version; both wouldn't appear in same code base)
4. $arr['key'] = isset($arr['key']) ? $arr['key'] : dflt
5. isset($arr['key']) ? strtoupper($arr['key']) : dflt
The following new operators were suggested:
1. new ternary based on isset (e.g. $a ?? strtoupper($a) : 'DFLT' with
implicit isset)
2. new shortcut ternary based on isset
3. new shortcut ternary based on !empty (objection: not as useful as
isset, since !empty is equivalent to !! but with notice suppression)
4. new shortcut ternary based on !== null or ! is_null
5. new shortcut ternary that only works on arrays and is based
on array_key_exists
6. indexing operator that suppress undefined index notices
7. variable access that suppresses undefined variable notices
8. assign-if-not-set operator (like ||= in Javascript)
Some objections to the above:
1. (new ternary) ?
2. (isset) Some developers always set variables and never want undefined
notice suppression (the never-unset style), which isset will do. However,
this isn't as common a style.
3. (!empty) Not as useful as isset, since !empty is equivalent to !! but
with notice suppression. Also, !empty($a)?$a:dflt isn't used as much as
isset($a)?$a:dflt.
4. (!== null / ! is_null) Not as useful as isset, since it doesn't
suppress notices, so isn't a replacement for the isset($a)?$a:dflt pattern.
However, it can be used in combination with 6 for the isset-based ternary
for arrays (e.g. $arr?['key'] ?: 'dflt').
5. (array_key_exists) Conceptually, anything unset has a null value, and
should thus be equivalent in value to something set to NULL.
array_key_exists distinguishes between unset and set to NULL, which
won't always match how some want to use the shortcut ternary. Thus, not as
useful as is_null.
6. (indexing w/o notices) ?
7. (variable access) Probably do more harm than good. It's easy to
ensure a variable is set.
8. (assign-if-not-set) For arrays, there's the alternative:
$arr += Array('key' = 'value');
This can also be used for a never-unset style to set defaults for an
array, which goes with the ! is_null($a) ? $a : dflt pattern.
Various syntax proposals:
1. $a ?? $b : dflt as a ternary, with shortcutting behavior.
2. $a ?? dflt as a shortcut ternary
3. $a ?! dflt as a shortcut ternary based on !empty (could be added
along with ??; objection is that it could ambiguate PHP's syntax,
conflicting with the not operator)
4. $a $: dflt as a shortcut ternary
5. $arr?['key'] to suppress undefined index notices
6. $arr@['key'] to suppress undefined index notices
7. $?var to suppress undefined variable notices
8. $a ??= dflt as an assign-if-not-set operator (goes along with ??)
9. $a !?= dflt as an assign-if-not-set operator (! suggests not-set)
10. $a $:= dflt as an assign-if-not-set operator (goes along with $:)
?? / isset vs ?? / is_null
Of the various proposals, ?? (with semantics of isset($a) ? $a : dflt)
already has a precedence: in C# as the null-coalescing operator. While PHP
doesn't have non-nullable types (hence ?? isn't a necessity), using ?? is
perhaps the least surprising option, and (including ??=) would cover
use-cases 1 and 4. On the other hand, PHP's ?? wouldn't be the same as
C#,
Re: [PHP-DEV] zend_parse_parameters() improvements
On Wed, Jul 18, 2012 at 11:05 PM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote:
Some deficiencies in zpp have been constrai
ning the implementation of common scenarios such as 'allow integer or NULL'*
or the more general 'allow different types for an argument'**.
So I propose the changes in this branch:
https://github.com/cataphract/php-src/compare/zpp_improv
Please see the commit messages for the rationale.
*Example:
https://github.com/php/php-src/pull/13
(again more recently on
https://github.com/php/php-src/pull/133 )
**
Example:
http://lxr.php.net/xref/PHP_TRUNK/ext/intl/timezone/timezone_methods.cpp#143
In this case, NULL, int and string are allowed. This would become much
simpler:
if (arg == NULL || Z_TYPE_PP(arg) == IS_NULL) {
se = TimeZone::createEnumeration();
} else {
long l;
char *s;
int s_len;
if (zend_parse_parameter(ZEND_PARSE_PARAMS_QUIET,
1 TSRMLS_DC, arg, l, l) == SUCCESS) {
TimeZone::createEnumeration((int32_t) l);
} else if (zend_parse_parameter(ZEND_PARSE_PARAMS_QUIET,
1 TSRMLS_DC, arg, s, s, s_len) == SUCCESS) {
TimeZone::createEnumeration(s);
} else {
//raise errror
}
}
+1 The long/null issue comes up every once in a while. This is really useful.
Nikita
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Integer overflows on float to int casts
Hi internals! When a large floating point number is cast to an integer we currently have very low-level C behavior (integer overflow and wraparound): $ /c/php-5.4.1/php -r 'var_dump((int) 40);' int(-294967296) $ /c/php-5.4.1/php -r 'var_dump((int) 60);' int(1705032704) As a fun fact, if you do the same thing with a string float the number if clipped instead of wrapped: $ /c/php-5.4.1/php -r 'var_dump((int) 40);' int(2147483647) This also applies to zend_parse_parameters. l arguments are wrapped, L arguments are clipped. In my eyes this kind of behavior has nothing to do in PHP. PHP is a high-level language, it shouldn't exhibit low-level stuff like integer overflows and wraparound. I think that at least for zend_parse_parameters this should be changed. Overflowing float parameters should not be accepted. Instead throw the usual E_WARNING and return FAILURE. I'm not sure though what one should do about the explicit (int) cast. My preference would be to throw a notice and use the clipping behavior. Thoughts? Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC karma request
I'd like to see some version of the null-coalescing ternary operator (recently brought up in a thread started by Rafael Dohms) make it into PHP. To help it along, may I have RFC karma so I can draft a proposal? My PHP wiki account name is outis, e-mail is ww.ga...@gmail.com. If there's a better/approved way of getting RFC karma than posting on the internals list, please let me know. So far, I haven't been able to find any official documentation on how.
Re: [PHP-DEV] 6.0 And Moving Forward
People are forgetting why we have version numbers. Yes, it's very spectacular to have all the new stuff in a major release, but that's not what major versions are for. Major versions are for BC breaks. And point releases are for BC-compatible new features. Therefore in 5.x releases old and new features should co-exist, and in 6.x the old ones should just go. Otherwise there's no point of using versions *at all*, and PHP can just publish build numbers or dates. Here's a refresher of the rules of versioning: http://semver.org/ Stan Stan, just to clarify, I'm for BC breaks and overall evolution in a language. It makes perfect sense to me, to go through the steps of marking deprecated and later removing those... As is clear on Semantic Versioning http://semver.org What I was stating is that: IF you want to keep the old way of doing things around instead of removing them, it should be change settings/tag/whatever so it work as the old way and not change it so it works the new way, that was my only point. Cheers Daniel Macedo -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend_parse_parameters() improvements
Hi!
Some deficiencies in zpp have been constrai
ning the implementation of common scenarios such as 'allow integer or
NULL'* or the more general 'allow different types for an argument'**.
So I propose the changes in this branch:
https://github.com/cataphract/php-src/compare/zpp_improv
This looks interesting. I have a bit different idea about how to make
parameter not passed scenario - see
https://wiki.php.net/rfc/skipparams - but having something like l! would
work in that case too.
It'd be nice to have a description of these as an RFC though - so we
could use it in the docs, when updating READMEs and for reference -
tracking down commit messages is not very convenient.
Example:
http://lxr.php.net/xref/PHP_TRUNK/ext/intl/timezone/timezone_methods.cpp#143
In this case, NULL, int and string are allowed. This would become much
simpler:
if (arg == NULL || Z_TYPE_PP(arg) == IS_NULL) {
se = TimeZone::createEnumeration();
} else {
long l;
char *s;
int s_len;
if (zend_parse_parameter(ZEND_PARSE_PARAMS_QUIET,
1 TSRMLS_DC, arg, l, l) == SUCCESS) {
TimeZone::createEnumeration((int32_t) l);
} else if (zend_parse_parameter(ZEND_PARSE_PARAMS_QUIET,
1 TSRMLS_DC, arg, s, s, s_len) == SUCCESS) {
TimeZone::createEnumeration(s);
} else {
//raise errror
}
Wait, didn't you say applying zpp to arg as l, then as s would change
it? Or your function doesn't change it?
In any case, I think giving access to single-parameter parsing is a good
idea and allows functions to implement complex cases in more consistent
manner - right now I know there are some functions that return different
error messages than zpp does when they parse arguments, for example -
this can be fixes.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Integer overflows on float to int casts
Cap it at INT_MAX, yeah, that seems reasonable. A notice seems reasonable but production servers displaying errors... devs will go mad :) On Jul 18, 2012 11:39 PM, Nikita Popov nikita@gmail.com wrote: Hi internals! When a large floating point number is cast to an integer we currently have very low-level C behavior (integer overflow and wraparound): $ /c/php-5.4.1/php -r 'var_dump((int) 40);' int(-294967296) $ /c/php-5.4.1/php -r 'var_dump((int) 60);' int(1705032704) As a fun fact, if you do the same thing with a string float the number if clipped instead of wrapped: $ /c/php-5.4.1/php -r 'var_dump((int) 40);' int(2147483647) This also applies to zend_parse_parameters. l arguments are wrapped, L arguments are clipped. In my eyes this kind of behavior has nothing to do in PHP. PHP is a high-level language, it shouldn't exhibit low-level stuff like integer overflows and wraparound. I think that at least for zend_parse_parameters this should be changed. Overflowing float parameters should not be accepted. Instead throw the usual E_WARNING and return FAILURE. I'm not sure though what one should do about the explicit (int) cast. My preference would be to throw a notice and use the clipping behavior. Thoughts? Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend_parse_parameters() improvements
Em Thu, 19 Jul 2012 01:11:38 +0200, Stas Malyshev smalys...@sugarcrm.com
escreveu:
Example:
http://lxr.php.net/xref/PHP_TRUNK/ext/intl/timezone/timezone_methods.cpp#143
In this case, NULL, int and string are allowed. This would become much
simpler:
if (arg == NULL || Z_TYPE_PP(arg) == IS_NULL) {
se = TimeZone::createEnumeration();
} else {
long l;
char *s;
int s_len;
if (zend_parse_parameter(ZEND_PARSE_PARAMS_QUIET,
1 TSRMLS_DC, arg, l, l) == SUCCESS) {
TimeZone::createEnumeration((int32_t) l);
} else if (zend_parse_parameter(ZEND_PARSE_PARAMS_QUIET,
1 TSRMLS_DC, arg, s, s, s_len) == SUCCESS) {
TimeZone::createEnumeration(s);
} else {
//raise errror
}
Wait, didn't you say applying zpp to arg as l, then as s would change
it? Or your function doesn't change it?
Yes, the zval is potentially changed in both calls (that's why the
argument is passed with double indirection). But this is not a problem
here (in fact, it simplifies resource management -- since the second
zend_parse_parameter() changes the zval in the stack, the engine can
reclaim the zval and string automatically when the function returns).
There's to argument if its processing fails. zend_parse_parameters()
(plural) changes the arguments only until it fails. Yes, whether an
argument is changed or not depends on its position relative to the failing
argument.
Since zend_parse_parameter() takes only one argument this is not a problem
-- supposedly, you call zend_parse_parameter() successfully only once. In
any case, you can always copy the zval yourself.
In any case, I think giving access to single-parameter parsing is a good
idea and allows functions to implement complex cases in more consistent
manner - right now I know there are some functions that return different
error messages than zpp does when they parse arguments, for example -
this can be fixes.
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
On 19/07/12 04:49, Rasmus Lerdorf wrote:
On 07/18/2012 01:02 AM, Pierre Joye wrote:
hi,
On Wed, Jul 18, 2012 at 9:35 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
See the other answers, clear APIs, no more argument mess, cleanness.
Cleanness has nothing to do with pseudo-objects.You don't have to use
- to have clean APIs, and using - doesn't automatically make your APIs
clean.
I really do not want to have a semantic discussion here.
This syntax is sexy, allows us to clean our APIs, and is amazingly handy.
This makes no sense to me either. How does it let us clean the APIs? Can
you give an example? I have one:
$a = -5;
$b = -5;
echo $a-abs(); // Outputs 5
echo $b-abs(); // should still output 5
What has been cleaned here over:
echo abs($a);
echo abs($b);
other than being 2 characters longer to type? It's not like you can
remove abs() from the string pseudo-object, so you are essentially just
taking all the functions in the global namespace and attaching them as a
method to every pseudo-object. Is that clean?
I think there is something we can do around this, but an argument of it
is sexy and clean needs to be backed up with some actual implementation
details that make sense.
-Rasmus
Which is the needle, and which is the haystack?
$pos = strpos($string, 'a');
$pos = strpos('a', $string);
vs
$pos = $string-pos('a');
$pos = 'a'-pos($string);
I'm not proposing to use pos() as the method name, just showing an
example that this syntax can be cleaner.
David
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
On 07/18/2012 05:10 PM, David Muir wrote:
On 19/07/12 04:49, Rasmus Lerdorf wrote:
On 07/18/2012 01:02 AM, Pierre Joye wrote:
hi,
On Wed, Jul 18, 2012 at 9:35 AM, Stas Malyshev
smalys...@sugarcrm.com wrote:
Hi!
See the other answers, clear APIs, no more argument mess, cleanness.
Cleanness has nothing to do with pseudo-objects.You don't have to use
- to have clean APIs, and using - doesn't automatically make your
APIs
clean.
I really do not want to have a semantic discussion here.
This syntax is sexy, allows us to clean our APIs, and is amazingly
handy.
This makes no sense to me either. How does it let us clean the APIs? Can
you give an example? I have one:
$a = -5;
$b = -5;
echo $a-abs(); // Outputs 5
echo $b-abs(); // should still output 5
What has been cleaned here over:
echo abs($a);
echo abs($b);
other than being 2 characters longer to type? It's not like you can
remove abs() from the string pseudo-object, so you are essentially just
taking all the functions in the global namespace and attaching them as a
method to every pseudo-object. Is that clean?
I think there is something we can do around this, but an argument of it
is sexy and clean needs to be backed up with some actual implementation
details that make sense.
-Rasmus
Which is the needle, and which is the haystack?
$pos = strpos($string, 'a');
$pos = strpos('a', $string);
vs
$pos = $string-pos('a');
$pos = 'a'-pos($string);
I'm not proposing to use pos() as the method name, just showing an
example that this syntax can be cleaner.
Or you could simply remember that it is always haystack,needle for
strings and needle,haystack for arrays. Not that complicated.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call for voting: [RFC] Allow use T_AS in closure use statement
Hi: I saw you two vote against for this RFC. could you explain why? then maybe I can improve it. thanks On Wed, Jul 18, 2012 at 11:21 PM, Laruence larue...@php.net wrote: On Wed, Jul 18, 2012 at 11:19 PM, Leigh lei...@gmail.com wrote: I missed the discussion on this one, the RFC examples are very simple. Does it support aliasing array indices? For example: (use $matches[0] as $name) sorry, no, it's only support literal variable for now. thanks On Jul 18, 2012 3:55 PM, Laruence larue...@php.net wrote: Hi: Call for voting for Allow use T_AS in closure use statement, https://wiki.php.net/rfc/useas#voting any comment will be appreciated. thanks -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
On Wed, Jul 18, 2012 at 6:16 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 07/18/2012 05:10 PM, David Muir wrote:
On 19/07/12 04:49, Rasmus Lerdorf wrote:
On 07/18/2012 01:02 AM, Pierre Joye wrote:
hi,
On Wed, Jul 18, 2012 at 9:35 AM, Stas Malyshev
smalys...@sugarcrm.com wrote:
Hi!
See the other answers, clear APIs, no more argument mess, cleanness.
Cleanness has nothing to do with pseudo-objects.You don't have to use
- to have clean APIs, and using - doesn't automatically make your
APIs
clean.
I really do not want to have a semantic discussion here.
This syntax is sexy, allows us to clean our APIs, and is amazingly
handy.
This makes no sense to me either. How does it let us clean the APIs? Can
you give an example? I have one:
$a = -5;
$b = -5;
echo $a-abs(); // Outputs 5
echo $b-abs(); // should still output 5
What has been cleaned here over:
echo abs($a);
echo abs($b);
other than being 2 characters longer to type? It's not like you can
remove abs() from the string pseudo-object, so you are essentially just
taking all the functions in the global namespace and attaching them as a
method to every pseudo-object. Is that clean?
I think there is something we can do around this, but an argument of it
is sexy and clean needs to be backed up with some actual implementation
details that make sense.
-Rasmus
Which is the needle, and which is the haystack?
$pos = strpos($string, 'a');
$pos = strpos('a', $string);
vs
$pos = $string-pos('a');
$pos = 'a'-pos($string);
I'm not proposing to use pos() as the method name, just showing an
example that this syntax can be cleaner.
Or you could simply remember that it is always haystack,needle for
strings and needle,haystack for arrays. Not that complicated.
-Rasmus
Really? Good to know . . .
Re: [PHP-DEV] Call for voting: [RFC] Allow use T_AS in closure use statement
On Wed, Jul 18, 2012 at 6:53 PM, Laruence larue...@php.net wrote: Hi: I saw you two vote against for this RFC. could you explain why? then maybe I can improve it. thanks I can't speak for them, but it might have something to do with a lack of information. I don't recall seeing the discussion thread on this, either. Though I could've just missed it. More specifics I think would be helpful. --Kris
