Re: [PHP-DEV] [RFC][DISCUSSION] Allow default value in list() syntax
Bump this to continue discussion of this RFC (
https://wiki.php.net/rfc/list_default_value).
In case some of you didn't follow it before. This RFC propose to allow set
default value in list() assignment：
list($a = 'default value') = $arr;
On 10 November 2015 at 11:14, reeze <re...@php.net> wrote:
> Hey Dan,
>
> On 9 November 2015 at 23:24, Dan Ackroyd <dan...@basereality.com> wrote:
>
>> Hi Reeze,
>>
>> On 9 November 2015 at 13:35, reeze <re...@php.net> wrote:
>> > Hi internals!
>> >
>> > I'd like to open a discussion on the RFC to allow set default values for
>> > list() assignment: https://wiki.php.net/rfc/list_default_value.
>> >
>> > What is your idea?
>>
>> I find the list construct to be quite magic already. Isn't it possible
>
> to get the affect that you want without adding anything to the core by
>> doing this:
>>
>> $defaults = ['default', 'default'];
>> $input = [1];
>>
>> list($a, $b) = array_replace($defaults, $input);
>>
>> I'd find that way easier to understand and explain to junior devs,
>>
>
> I saw the contrast way, it is more complex ;-). This seems like a trick.
> Many feature could also be remove,
> such as I refered in RFC: Null coalesce "??" and Ternary Operator "?:"
>
> And the trick is trick. If you want to unpack nested array.
>
> list($a, list(list($b))) = $array
>
> Then you might need a new trick to do that.
>
> You know we have default for function declaration:
> function func($a='default') {}; and almost all language have the feature,
> it is easier to understand from my perspective.
>
>
>> compared to having more functionality added to the 'list' magicness.
>>
>> cheers
>> Dan
>>
>
>
>
> --
> Reeze Xia
> http://reeze.cn
>
--
Reeze Xia
http://reeze.cn
[PHP-DEV] [RFC][DISCUSSION] Allow default value in list() syntax
Hi internals! I'd like to open a discussion on the RFC to allow set default values for list() assignment: https://wiki.php.net/rfc/list_default_value. What is your idea? Thanks. -- Reeze Xia http://reeze.cn
Re: [PHP-DEV] [RFC][DISCUSSION] Allow default value in list() syntax
Hey Dan,
On 9 November 2015 at 23:24, Dan Ackroyd <dan...@basereality.com> wrote:
> Hi Reeze,
>
> On 9 November 2015 at 13:35, reeze <re...@php.net> wrote:
> > Hi internals!
> >
> > I'd like to open a discussion on the RFC to allow set default values for
> > list() assignment: https://wiki.php.net/rfc/list_default_value.
> >
> > What is your idea?
>
> I find the list construct to be quite magic already. Isn't it possible
to get the affect that you want without adding anything to the core by
> doing this:
>
> $defaults = ['default', 'default'];
> $input = [1];
>
> list($a, $b) = array_replace($defaults, $input);
>
> I'd find that way easier to understand and explain to junior devs,
>
I saw the contrast way, it is more complex ;-). This seems like a trick.
Many feature could also be remove,
such as I refered in RFC: Null coalesce "??" and Ternary Operator "?:"
And the trick is trick. If you want to unpack nested array.
list($a, list(list($b))) = $array
Then you might need a new trick to do that.
You know we have default for function declaration:
function func($a='default') {}; and almost all language have the feature,
it is easier to understand from my perspective.
> compared to having more functionality added to the 'list' magicness.
>
> cheers
> Dan
>
--
Reeze Xia
http://reeze.cn
Re: [PHP-DEV] Request Feedback for Instance Variable Sugar RFC
Hi,
On 9 March 2015 at 17:43, Shawn McCool sh...@heybigname.com wrote:
I've never submitted an RFC. Whether or not you're interested in the
feature, please consider giving me feedback on the RFC itself so that I can
better understand how to succeed in the process.
== PHP RFC: Instance Variable Sugar ==
* Version: 0.1
* Date: 2015-03-09
* Author: Shawn McCool, sh...@heybigname.com
* Status: In Discussion
= Summary =
In order to access instance variables, one must use the `$this-` prefix.
The problem with this is that it reduces expressiveness in the language and
increases the amount of unnecessary decoration, reducing readability.
This might decrease readability, since we already comfortable with the
syntax $this-something, in my opinion
This RFC proposes a single character syntax sugar form of `$this-`.
Instead, an `@` can be used to reference instance variables.
The @ replaces the normal $ variable prefix.
= Example =
file php MyClass.php
?php
class Addition {
private $number
public function __construct($number) {
@number = $number;
}
public function original() {
return @number;
}
public function addTo($amount) {
return @number + $amount;
this is a BC break. this is the same as constant number + $amount. so this
syntax is not feasible.
}
}
/file
= Backwards Compatibility =
Leave `$this-` available.
= Proposed PHP Version(s) =
This is proposed for the next PHP x, currently PHP 7.
--
Shawn McCool | Big Name
sh...@heybigname.com
heybigname.com
--
Reeze Xia
http://reeze.cn
Re: [PHP-DEV] [Discussion] Deprecate function sizeof()
Hi, On 8 March 2015 at 00:41, Kalle Sommer Nielsen ka...@php.net wrote: Hi 2015-03-07 16:51 GMT+01:00 reeze re...@php.net: Hi internals, I'd like to deprecate function: sizeof() [1][2], which is an alias of count(). some people expect it return the memory size of the variable. The doc page's[1] user contributed notes indicate that too. What do you think? 'm a big -1 on this, while I know it returns the memory size in a C perspective, I think it makes perfect sense to remain an alias, it would break lots of applications for a very tiny to nothing gain. It is a deprecated warning I won't break code I think. This could makes those project more maintainable (new PHP programmer could be easier to maintain the code without surprise), and it will be trivial to fix this. We could move things forward ;-) -- regards, Kalle Sommer Nielsen ka...@php.net -- Reeze Xia http://reeze.cn
Re: [PHP-DEV] [Discussion] Deprecate function sizeof()
On 8 March 2015 at 09:39, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, On Sun, Mar 8, 2015 at 5:41 AM, Stanislav Malyshev smalys...@gmail.com wrote: I'd like to deprecate function: sizeof() [1][2], which is an alias of count(). some people expect it return the memory size of the variable. Why? So, some people are wrong, why we need to mess with the language to accommodate them? I don't think it is a good idea. The same opinion. Unless there are good enough reasons, these aliases should be kept. If Consistent function names RFC passes, aliases will be Yes, I think so, it didn't remove the alias, but propose use use count() instead. listed in main function page only. It may reduce confusions hopefully. That might helps. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- Reeze Xia http://reeze.cn
Re: [PHP-DEV] [Discussion] Deprecate function sizeof()
On 9 March 2015 at 06:44, Pierre Joye pierre@gmail.com wrote: On Sun, Mar 8, 2015 at 2:51 AM, reeze re...@php.net wrote: Hi internals, I'd like to deprecate function: sizeof() [1][2], which is an alias of count(). some people expect it return the memory size of the variable. The doc page's[1] user contributed notes indicate that too. What do you think? As I tend to like the idea to cleanup things, adding warning and deprecation warnings for the sake of it is not too appealing to me. Especially for this kind of things. Yes it will not really fix the confusion, and it is a small problem, I know few decent projects use sizeof, we could make the old code involve and more consist. sizeof() was kept because of BC since PHP4.0, count() should be the recommended function. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- Reeze Xia http://reeze.cn
[PHP-DEV] [Discussion] Deprecate function sizeof()
Hi internals, I'd like to deprecate function: sizeof() [1][2], which is an alias of count(). some people expect it return the memory size of the variable. The doc page's[1] user contributed notes indicate that too. What do you think? [1] http://php.net/sizeof [2] https://github.com/php/php-src/pull/1161 [3] http://stackoverflow.com/questions/3974385/php-array-count-or-sizeof -- Reeze Xia http://reeze.cn
Re: [PHP-DEV] Use behavior thoughts
On 6 March 2015 at 16:35, Alexander Lisachenko lisachenko...@gmail.com
wrote:
Hello!
2015-03-05 22:40 GMT+03:00 Anthony Ferrara ircmax...@gmail.com:
This requires use to immediately follow namespace declarations:
namespace Foo {
use Bar; //valid
}
namespace Bar {
use Foo; //valid, second namespace in file
}
namespace Baz {
echo Hi!;
use Foo; // Invalid
}
This did break approximately 30 internal tests, but they were all
testing this specific code path (or bugs related to it).
I like this way, because it's more logical and readable. There aren't
unpredictable effects and misunderstanding with interpretation of source
code.
+1
--
Reeze Xia
http://reeze.cn
[PHP-DEV] [Disccusion] Introduce error_clear_last() function
Hi internals, I would like to implement FR #45235. below copied from Github. What do you think about it? - You can view the Pull Request on github: https://github.com/php/php-src/pull/1135 Pull Request Description: In PHP a simple assign expression would raise error, if user use error_get_last() to check they can't guarantee the call site raise the error. This patch implement a function to clear the error state. http://php.net/error_get_last The top voted user contributed note are a tricky way to clear last error. also there are a lot of apps use the similar hacks. 1. https://github.com/mathnerd3141/doeqs_new/blob/ba23c478a0c819dc6b2f8f96f9df35d16505eed2/errors.php#L20 2. https://github.com/benfinke/cargo_plane/blob/4911bc6a91d8345aa62c81fb52c8bed9d216c44e/Splunk/Util.php#L89 Request: https://bugs.php.net/bug.php?id=45235 -- Reeze Xia http://reeze.cn
Re: [PHP-DEV] Re: About optimization for compiler
Hi, On 27 February 2015 at 14:26, Xinchen Hui larue...@gmail.com wrote: Hey: On Fri, Feb 27, 2015 at 2:22 PM, Xinchen Hui larue...@gmail.com wrote: Hey Internals: I was looking Bob's switch optimization.. then I start to worry about where is the place optimization should goes.. in generally, PHP is a interpreted language. IMO, it should compiler the PHP codes to opcode without any optimization(of course, we did some, but they won't change a lots of opcodes which should be generated).. and, since 5.5, we already have opcache bundled in.. thus, I am proposing a principle, that is: in the future, we only do optimization in opcache side, and keep or maybe big optimization? but I don't know how to define big or small optimizations now.. (small is the optimizations, we are sure it is safe, maybe) thanks Zend Compiler without any optimization... considering Zend Compiler do things in -O0. since, optimization always are dangerous.. if we only do them in opcache, user can still run them codes with disable opcache, or at least disable some optimization level which cause that.. what do you think? We may need to clarify which kind of optimizations we want to set a principle. There are different level's optimizations. Opcache is a opcode to opcode optimizer, but some optimizations might need lower level optimizations like Bob's, some might need to change base data structure. We have AST intermediate represent structure, there might be some AST level optimizations, this not opcache's job too. thanks -- Xinchen Hui @Laruence http://www.laruence.com/ -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Reeze Xia http://reeze.cn
Re: [PHP-DEV] [DISCUSSION] Make empty() a Variadic
Hi,
On 13 February 2015 at 19:31, Andrea Faulds a...@ajf.me wrote:
On 13 Feb 2015, at 11:16, Andrea Faulds a...@ajf.me wrote:
Hey,
On 13 Feb 2015, at 07:28, Michael Wallner m...@php.net wrote:
On 12/02/15 19:55, Thomas Punt wrote:
I'd like to propose to make empty() a variadic, where if any
arguments passed in are considered empty, then false is returned
Should that read if any arguments passed in are considered *NOT* empty,
then false is returned?
No, I think it's correct, if confusingly phrased. I believe Thomas is
proposing variadic empty() where TRUE is returned if any of its arguments
are empty, otherwise FALSE. So, empty($a, $b, $c) would be equivalent to
empty($a) || empty($b) || empty($c), much like isset($a, $b, $c) is
equivalent to (and implemented as) isset($a) isset($b) isset($c).
Wait, I think I made a mistake.
* Thomas proposed if any arguments passed in are considered empty, then
false is returned, i.e. !(empty($a) || empty($b) || empty($c)) if his
words are taken literally. This doesn't make much sense, I think it was a
mistake.
* You suggested he may have meant if any arguments passed in are
considered *NOT* empty, then false is returned, i.e. (empty($a)
empty($b) empty($c))
* I assume Thomas actually meant where if any arguments passed in are
considered empty, then *true* is returned, i.e. (empty($a) || empty($b) ||
empty($c))
Sorry for the confusion.
I think the || behaviour is the most useful, as it's the analogue of
isset's. So !empty($a, $b, $c) would work similarly to isset($a, $b, $c),
and similarly, !isset($a, $b, $c) would work similarly to empty($a, $b, $c).
For example: echo $a, $b, $c, empty($a, $b, $c), they are treated equal,
if the empty() means if any one of them is empty then result is TRUE, the
advantage of it disappeared:
if (empty($a, $b, $c)) {
// you might want to check it again.
if (empty($a)) {
//blah blah.
} else if (empty($b)) {
}
}
But that's just my opinion. :)
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Reeze Xia
http://reeze.cn
Re: [PHP-DEV] [RFC] Void Return Type
HI, On 14 February 2015 at 12:57, François Laupretre franc...@php.net wrote: De : Andrea Faulds [mailto:a...@ajf.me] I've written a small RFC and patch to add a void return type: https://wiki.php.net/rfc/void_return_type Please have a read over it. I think this would be a simple, yet useful addition. That's a nice addition and a beginning to distinguish void from null, as I imagine the function still returns null. Now, what about making void a real zval type ? It would open a lot of possibilities. Unlike null, conversions from void would raise an error. It would also be rejected as argument input type but could be used as an output type when arg is passed by ref, it could be the default type for return_value (huge BC break here) and so on... There's a need for a real 'no value' type different from null, as null has too many uses. If defined correctly, it can be a powerful addition. What is the benefit of passing a void value around just for return type? and the rest of engine will have to take care of IS_VOID type, it seems doesn't worth it. François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Reeze Xia http://reeze.cn
Re: [PHP-DEV] [RFC] Void Return Type
Do we really have to throw an catchable fatal error? the other return types make sense, why so strict? On 14 February 2015 at 11:18, Andrea Faulds a...@ajf.me wrote: Hi everyone, I've written a small RFC and patch to add a void return type: https://wiki.php.net/rfc/void_return_type Please have a read over it. I think this would be a simple, yet useful addition. Thanks! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Reeze Xia http://reeze.cn
Re: [PHP-DEV][RFC][VOTE] Group Use Declarations
Definitely +1 for me. That what I proposed before. you make it happened ;-) On 12 February 2015 at 22:25, Marcio Almada marcio.w...@gmail.com wrote: Yup sure. We are going to vote yes (behind my nickname). However, while I agree with all your arguments, we have more syntax and more semantics, it's kind of confusing. But it's a small one, so +1 for us. I bet there is no way to add such a feature without adding at least a small amount of syntax, and that's why I aimed for the minimal approach. Also, there is no better time to have it added other than on a major version release. Thanks for your questions and your vote :) -- Reeze Xia http://reeze.cn
[PHP-DEV] Re: Proposal: Introduce a new macro:php_error_docref_ex()
Hi, On 11 February 2015 at 19:15, Dmitry Stogov dmi...@zend.com wrote: Hi, I don't think it'll improve something, and may complicate merging from PHP5 (this is not a big issue, because merging is already not simple). Yes it just makes code looks a little better and cleaner. I didn't realized the merging problem. that might affect diffs which changes php_error_docref() In any case, the names should be swapped, to be used as: php_error_docref(E_WARNING, recursion detected); or php_error_docref_ex(NULL, E_WARNING, recursion detected); Yes I prefer this too. But considering the merging problem, I think I should hold this idea of update all of those calls. We may provider a simple version with default null docref for external extesions, but I didn't have proper name for that. also macros with __VA_ARGS__ may be not portable, s it should be implemented differently. Yes I should use ##__VA_ARGS__ instead. Thanks. Dmitry. On Wed, Feb 11, 2015 at 11:41 AM, Xinchen Hui larue...@php.net wrote: Hey: On Wed, Feb 11, 2015 at 4:35 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, On Wed, Feb 11, 2015 at 5:21 PM, reeze re...@php.net wrote: I think it is a cleanup, it works but there are too many duplication. it is the time to make the code clean and easier to understand. I've never used other than NULL also. Everyone is going to remove TSRM macros, it's right time to clean up. fine, if you want to change.. please, _ex means extending, so the name should not be php_error_docref_ex... thanks Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- Xinchen Hui @Laruence http://www.laruence.com/ -- Reeze Xia http://reeze.cn
[PHP-DEV] Re: Proposal: Introduce a new macro:php_error_docref_ex()
Hi,
On 12 February 2015 at 15:30, Dmitry Stogov dmi...@zend.com wrote:
We don't use macros with variable number of arguments in PHP.
this is not portable.
We could don't have to use variadic macros, we could try something like:
*+PHPAPI void php_error_doc0(int type, const char *format, ...)*
*+{*
*+* *va_list args;*
*+*
*+* *va_start(args, format);*
*+* *php_error_docref0(NULL, type, format, args);*
*+* *va_end(args);*
*+}*
*+*
*+#define php_error_doc php_error_doc0*
*+*
Thanks. Dmitry.
On Wed, Feb 11, 2015 at 6:01 PM, reeze re...@php.net wrote:
Hi,
On 11 February 2015 at 19:15, Dmitry Stogov dmi...@zend.com wrote:
Hi,
I don't think it'll improve something, and may complicate merging from
PHP5 (this is not a big issue, because merging is already not simple).
Yes it just makes code looks a little better and cleaner.
I didn't realized the merging problem. that might affect diffs which
changes php_error_docref()
In any case, the names should be swapped, to be used as:
php_error_docref(E_WARNING, recursion detected);
or
php_error_docref_ex(NULL, E_WARNING, recursion detected);
Yes I prefer this too.
But considering the merging problem, I think I should hold this idea of
update all of those calls.
We may provider a simple version with default null docref for external
extesions, but I didn't have proper name for that.
also macros with __VA_ARGS__ may be not portable, s it should be
implemented differently.
Yes I should use ##__VA_ARGS__ instead.
Thanks. Dmitry.
On Wed, Feb 11, 2015 at 11:41 AM, Xinchen Hui larue...@php.net wrote:
Hey:
On Wed, Feb 11, 2015 at 4:35 PM, Yasuo Ohgaki yohg...@ohgaki.net
wrote:
Hi all,
On Wed, Feb 11, 2015 at 5:21 PM, reeze re...@php.net wrote:
I think it is a cleanup, it works but there are too many
duplication. it
is the time to make the code clean and easier to understand.
I've never used other than NULL also.
Everyone is going to remove TSRM macros, it's right time to clean up.
fine, if you want to change..
please, _ex means extending,
so the name should not be php_error_docref_ex...
thanks
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
Xinchen Hui
@Laruence
http://www.laruence.com/
--
Reeze Xia
http://reeze.cn
--
Reeze Xia
http://reeze.cn
[PHP-DEV] Proposal: Introduce a new macro:php_error_docref_ex()
Hi all, There are a lot of code use php_error_docref() macro, the first parameter mostly is NULL, before PHP7, it looks like: *php_error_docref(NULL TSRML, E_WARNING, recursion detected);* in PHP7 *php_error_docref(NULL, E_WARNING, recursion detected);* looks better, but the first parameter look dumb. I did a simple statics, there are: Null docref: 2530 Not Null docref: 51 I searched on Github, it seems that almost all of the extension use NULL docref. So I propose add a new macro, like: php_error_error_docref_ex(E_WARNING, xxx). this could make code looks better and the extension maintainer's easier. Another option would be just update the php_error_docref() macro to remove the docref parameter, default to NULL but not add a new macro. What do you think about it? [1] https://github.com/php/php-src/pull/1075 -- Reeze Xia http://reeze.cn
[PHP-DEV] Re: Proposal: Introduce a new macro:php_error_docref_ex()
PS: Github search result: https://github.com/search?l=cq=php_error_docrefref=searchresultstype=Codeutf8=%E2%9C%93 It seems that no one need the docref at all. On 11 February 2015 at 16:07, reeze re...@php.net wrote: Hi all, There are a lot of code use php_error_docref() macro, the first parameter mostly is NULL, before PHP7, it looks like: *php_error_docref(NULL TSRML, E_WARNING, recursion detected);* in PHP7 *php_error_docref(NULL, E_WARNING, recursion detected);* looks better, but the first parameter look dumb. I did a simple statics, there are: Null docref: 2530 Not Null docref: 51 I searched on Github, it seems that almost all of the extension use NULL docref. So I propose add a new macro, like: php_error_error_docref_ex(E_WARNING, xxx). this could make code looks better and the extension maintainer's easier. Another option would be just update the php_error_docref() macro to remove the docref parameter, default to NULL but not add a new macro. What do you think about it? [1] https://github.com/php/php-src/pull/1075 -- Reeze Xia http://reeze.cn -- Reeze Xia http://reeze.cn
[PHP-DEV] Re: Proposal: Introduce a new macro:php_error_docref_ex()
I think it is a cleanup, it works but there are too many duplication. it is the time to make the code clean and easier to understand. I myself don't know why should I need the first NULL when I am a newcomer of writing extensions, it just seems everyone do that, before PHP7 there is a strange TSRML_CC macro, it is hard to maintain. On 11 February 2015 at 16:16, Xinchen Hui larue...@php.net wrote: On Wed, Feb 11, 2015 at 4:07 PM, reeze re...@php.net wrote: Hi all, There are a lot of code use php_error_docref() macro, the first parameter mostly is NULL, before PHP7, it looks like: php_error_docref(NULL TSRML, E_WARNING, recursion detected); in PHP7 php_error_docref(NULL, E_WARNING, recursion detected); looks better, but the first parameter look dumb. I did a simple statics, there are: Null docref: 2530 Not Null docref: 51 I searched on Github, it seems that almost all of the extension use NULL docref. So I propose add a new macro, like: php_error_error_docref_ex(E_WARNING, xxx). this could make code looks better and the extension maintainer's easier. Another option would be just update the php_error_docref() macro to remove the docref parameter, default to NULL but not add a new macro. What do you think about it? No. I can't see any benefit from it, but lots of changes. everything works well now. thanks [1] https://github.com/php/php-src/pull/1075 -- Reeze Xia http://reeze.cn -- Xinchen Hui @Laruence http://www.laruence.com/ -- Reeze Xia http://reeze.cn
Re: [PHP-DEV] Re: Annotated PHP 5-7 extension diff
Can we just use PHP7 instead of PHPNG in the wiki, that might be misleading.
On 11 February 2015 at 01:03, Jan Ehrhardt php...@ehrhardt.nl wrote:
Xinchen Hui in php.internals (Mon, 9 Feb 2015 14:49:43 +0800):
On Mon, Feb 9, 2015 at 5:06 AM, Jan Ehrhardt php...@ehrhardt.nl wrote:
https://wiki.php.net/phpng-upgrading
[snip]
ib_link = (ibase_db_link *)zend_fetch_resource2(Z_RES_P(link_arg),
link_id, LE_LINK, le_link, le_plink);
But this is only an educated guess based on looking at changes in other
extensions. At the moment I am struggling with the PHP7 translation of
this block:
these are changes are made recently, I've updated the relates section
in that wiki.
Thanks. The wiki now contains my educated guess with an alternative if
you know nothing about link_arg's type. Could you apply the PHP7 changes
to ext/interbase/interbase.c as well? The Wiki is inconsistent with the
actual PHP7 sources at the moment...
BTW, this seems to be a copy/paste error in the Wiki:
- if (zend_hash_find(EG(class_table), Z_STRVAL_P(key),\
Z_STRLEN_P(key)+1, (void**)ce_ptr) == SUCCESS) {
+ if ((func = zend_hash_find_ptr(ht, Z_STR_P(key))) != NULL) {
Jan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Reeze Xia
http://reeze.cn
Re: [PHP-DEV] Re: [RFC] Support internal function return types
Thanks a lot! On 5 February 2015 at 16:03, Dmitry Stogov dmi...@zend.com wrote: merged into master with the proposed changes. Thanks. Dmitry. On Thu, Feb 5, 2015 at 9:37 AM, reeze re...@php.net wrote: Hi Dmitry, On 5 February 2015 at 14:31, Dmitry Stogov dmi...@zend.com wrote: Hi reeze, The original return type patch was designed to support internal functions as well. So I think, this is just a good addition. Yes :) Only one note: I'm not sure, if we need the addition check in ZEND_DO_FCALL handler. On one hand it verifies that internal function returns proper result (but they MUST do it). On the other hand, it also slowdowns each additional call. Instead of modifying zend_verify_return_type() I would add zend_verify_internal_return_type(), and use: ZEND_ASSERT((fbc-common.fn_flags ZEND_ACC_HAS_RETURN_TYPE) zend_verify_internal_return_type(fbc, EX_VAR(opline-result.var))); This would allow catching error in DEBUG build, but won't slowdown RELEASE build. If you agree, I may just commit this. Sure! Thank you! Thanks. Dmitry. On Thu, Feb 5, 2015 at 7:01 AM, reeze re...@php.net wrote: PS: There is no enough unit tests to cover all of the branches, if we want then I have to add a bunch of for testing functions and classes in ZEND_DEBUG, what is the better way? On 5 February 2015 at 11:54, reeze re...@php.net wrote: Hi all, RFC: https://wiki.php.net/rfc/internal_function_return_types I noticed that return types RFC[1] didn't support internal functions, I just open a PR[2] to support it. There are some open issues we can discuss: 1. User land return types didn't stop the php, the current implementation raise error to stop PHP from start, this may help debug problem. 2. User land return types didn't support Nullable types, but the RFC return types internally support it, I think it is feature. is that acceptable? Thank you. --- [1] https://wiki.php.net/rfc/return_types [2] https://github.com/php/php-src/pull/1050 -- Reeze Xia http://reeze.cn -- Reeze Xia http://reeze.cn
Re: [PHP-DEV] Re: [RFC] Support internal function return types
Hi Dmitry, On 5 February 2015 at 14:31, Dmitry Stogov dmi...@zend.com wrote: Hi reeze, The original return type patch was designed to support internal functions as well. So I think, this is just a good addition. Yes :) Only one note: I'm not sure, if we need the addition check in ZEND_DO_FCALL handler. On one hand it verifies that internal function returns proper result (but they MUST do it). On the other hand, it also slowdowns each additional call. Instead of modifying zend_verify_return_type() I would add zend_verify_internal_return_type(), and use: ZEND_ASSERT((fbc-common.fn_flags ZEND_ACC_HAS_RETURN_TYPE) zend_verify_internal_return_type(fbc, EX_VAR(opline-result.var))); This would allow catching error in DEBUG build, but won't slowdown RELEASE build. If you agree, I may just commit this. Sure! Thank you! Thanks. Dmitry. On Thu, Feb 5, 2015 at 7:01 AM, reeze re...@php.net wrote: PS: There is no enough unit tests to cover all of the branches, if we want then I have to add a bunch of for testing functions and classes in ZEND_DEBUG, what is the better way? On 5 February 2015 at 11:54, reeze re...@php.net wrote: Hi all, RFC: https://wiki.php.net/rfc/internal_function_return_types I noticed that return types RFC[1] didn't support internal functions, I just open a PR[2] to support it. There are some open issues we can discuss: 1. User land return types didn't stop the php, the current implementation raise error to stop PHP from start, this may help debug problem. 2. User land return types didn't support Nullable types, but the RFC return types internally support it, I think it is feature. is that acceptable? Thank you. --- [1] https://wiki.php.net/rfc/return_types [2] https://github.com/php/php-src/pull/1050 -- Reeze Xia http://reeze.cn
[PHP-DEV] [RFC] Support internal function return types
Hi all, RFC: https://wiki.php.net/rfc/internal_function_return_types I noticed that return types RFC[1] didn't support internal functions, I just open a PR[2] to support it. There are some open issues we can discuss: 1. User land return types didn't stop the php, the current implementation raise error to stop PHP from start, this may help debug problem. 2. User land return types didn't support Nullable types, but the RFC return types internally support it, I think it is feature. is that acceptable? Thank you. --- [1] https://wiki.php.net/rfc/return_types [2] https://github.com/php/php-src/pull/1050
[PHP-DEV] Re: [RFC] Support internal function return types
PS: There is no enough unit tests to cover all of the branches, if we want then I have to add a bunch of for testing functions and classes in ZEND_DEBUG, what is the better way? On 5 February 2015 at 11:54, reeze re...@php.net wrote: Hi all, RFC: https://wiki.php.net/rfc/internal_function_return_types I noticed that return types RFC[1] didn't support internal functions, I just open a PR[2] to support it. There are some open issues we can discuss: 1. User land return types didn't stop the php, the current implementation raise error to stop PHP from start, this may help debug problem. 2. User land return types didn't support Nullable types, but the RFC return types internally support it, I think it is feature. is that acceptable? Thank you. --- [1] https://wiki.php.net/rfc/return_types [2] https://github.com/php/php-src/pull/1050
Re: [PHP-DEV] Re: [RFC][DISCUSSION] script() and script_once()
The name seems ambiguous , how about require_script/once to match do_sth pattern? On 5 February 2015 at 10:03, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, On Thu, Feb 5, 2015 at 10:53 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: I would like to discuss my must have it in PHP 7 item. PHP RFC: script() and script_once() https://wiki.php.net/rfc/script_and_script_once Since script()/script_once() is almost copy of require()/require_once(), it could be INI option. require_embed = On/Off This allows existing PHP script to be secure without rewriting. If many of you like this, I'll change the RFC. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Question regarding stream wrappers and op code cache
Hi Cesar, On 4 February 2015 at 07:26, Cesar Rodas ce...@rodas.me wrote: Hi Guys, I have a doubt, is it efficient include/require files from a source different than the real file system a stream wrapper class? My question is, would the op-code cache work as it would when reading a file form the filesystem? Yes it works if you are using 'phar' stream wrapper, the rest wrappers are not cached, @see https://github.com/php/php-src/blob/master/ext/opcache/ZendAccelerator.c#L138-L142 This RFC: https://wiki.php.net/rfc/streams-is-cacheable is aim to remove the restriction and allow stream wrapper itself to decide should it been cached by opcache. Cheers, -- César D. Rodas Open Source developer +595-983-161124 PGP: F9ED A265 A3AB C8A1 D145 7368 158A 0336 C707 0AA6
Re: [PHP-DEV] Enable error_handler callback parameters to be passed by reference
Yeah, seem other want it it too, so I just updated the PR to allow the
first four parameters been passed by reference.
On 23 January 2015 at 16:23, Nicolas Grekas nicolas.grekas+...@gmail.com
wrote:
function myErrorHandler($errno, $errstr, $errfile, $errline) {...}
It would be awesome to also pass $errfile and $errline by reference. This
would allow mapping compiled source to real source code and have
meaningful error file+line information.
By compiled, I mean e.g. inlined classes (like the bootstrap.cache.php
file in Symfony), or preprocessed sources, etc.
Nicolas
Re: [PHP-DEV] Enable error_handler callback parameters to be passed by reference
I like the idea, we have the similar scenario, we need to print request log
id to the log,
so I just made a PR to implement this:
https://github.com/php/php-src/pull/1018 the PR is against master,
but I think this could also been in 5.5.
On 22 January 2015 at 18:41, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Thomas,
On Wed, Jan 21, 2015 at 1:39 PM, Thomas Bley ma...@thomasbley.de wrote:
In userland it is sometimes necessary to extend PHP's notices/warnings
with additional information (e.g. username from session, stack trace,
etc.)
I'm proposing to enable error_handler callback parameters to be passed by
reference to be able to append additional data to error messages.
Example:
?php
ini_set('error_reporting', E_ALL);
ini_set('display_errors', 0);
ini_set('log_errors', 1);
ini_set('error_log', 'php_error.log');
function myErrorHandler($errno, $errstr, $errfile, $errline) {
if (!empty($_SESSION['username'])) {
$errstr .= ', username: '.$_SESSION['username'];
}
return false; // continue normal error handler
}
set_error_handler(myErrorHandler);
function test() {
echo tests; // Use of undefined constant tests
}
test();
Gives in php_error.log:
[21-Jan-2015 04:32:26 UTC] PHP Notice: Use of undefined constant tests -
assumed 'tests', username: ... in error.php on line 17
Instead of:
[21-Jan-2015 04:32:26 UTC] PHP Notice: Use of undefined constant tests -
assumed 'tests' in error.php on line 17
This would be very useful for accounting!
If you cannot send pull requests, please file this to bugs.php.net as
request.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] [RFC] Extension Prepend Files
I like the idea, I have implemented a util [1] to help writing extensions with PHP, I try the approach HHVM adopted by embedding PHP scripts to the binary file of extension, maybe it is what you want. I do like it been supported in core. I would like to implement the RFC if others like it. --- [1] https://github.com/reeze/php-ext-embed On 4 January 2015 at 19:52, Benjamin Eberlei kont...@beberlei.de wrote: Hey everyone, I want to open discussion on my RFC to strengthen the ability of extensions to provide functionality to developers in both C **and** PHP code. For this extensions can add PHP files to a list of prepend files that are part of every request execution exactly the same way the INI auto_prepend_file functionality works: https://wiki.php.net/rfc/extension_prepend_files I propose implementation details in the RFC, but they are completely up to discussion. I am even sure there is probably a better way than what I proposed, because I am not familiar with the code. greetings Benjamin
Re: [PHP-DEV] [RFC] Extension Prepend Files
Hi Benjanmin, I didn't try to cache opcode myself, I try it before, but I think it should be done by opcaches (avoid duplication and opcache will optimize the compiled opcode), so I use the method @François mentioned, I use a stream wrapper to take advantage of opcaches. there is a problem opcache didn't allow streams except `file://` and `phar://`, @François created a RFC to support it [1], if that was accepted, it should work with full speed :) -- [1] https://github.com/php/php-src/pull/976/files On 4 January 2015 at 21:02, Benjamin Eberlei kont...@beberlei.de wrote: Hey reeze, This looks like a fantastic approach. Can you explain how you compile the PHP code into the Shared Object? The README doesnt explain much. greetings Benjamin On Sun, Jan 4, 2015 at 1:33 PM, reeze re...@php.net wrote: I like the idea, I have implemented a util [1] to help writing extensions with PHP, I try the approach HHVM adopted by embedding PHP scripts to the binary file of extension, maybe it is what you want. I do like it been supported in core. I would like to implement the RFC if others like it. --- [1] https://github.com/reeze/php-ext-embed On 4 January 2015 at 19:52, Benjamin Eberlei kont...@beberlei.de wrote: Hey everyone, I want to open discussion on my RFC to strengthen the ability of extensions to provide functionality to developers in both C **and** PHP code. For this extensions can add PHP files to a list of prepend files that are part of every request execution exactly the same way the INI auto_prepend_file functionality works: https://wiki.php.net/rfc/extension_prepend_files I propose implementation details in the RFC, but they are completely up to discussion. I am even sure there is probably a better way than what I proposed, because I am not familiar with the code. greetings Benjamin
Re: [PHP-DEV] [RFC] Add is_cacheable() stream-wrapper operation
+1 for this PR. On 4 January 2015 at 09:36, François Laupretre franc...@tekwire.net wrote: Hi, I just wrote this RFC to propose a clean way for opcode caches to decide if a given URI is cacheable or not : https://wiki.php.net/rfc/streams-is-cacheable Please comment. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New function: spl_object_id() or spl_object_handle()
Won't `$obj1 === $obj2` work for you ?
On 28 November 2014 at 09:13, Bostjan Skufca bost...@a2o.si wrote:
Hello everyone,
this is a proposal to add new function to PHP core: spl_object_id()
The story:
Recently I was debugging some larger libraries and sorely missed a function
that would return an object ID. A function called spl_object_hash() exists,
but it returns identical hashes for equal objects. You need object ID to be
really sure if two references are indeed the same object or two identical
objects.
Most of the meat is described in this StackOverflow thread:
http://stackoverflow.com/questions/2872366/get-instance-id-of-an-object-in-php
The OP proposes OB+var_dump() magic, which works if objects are small.
Unfortunatelly I was hitting Allowed memory exceeded.
The second answer, given by Gustavo Lopes, describes how to create an
extension for this, which provides new function, named spl_object_id(). I
believe this function should be included in PHP core.
Sample implementation (not tested):
=
/* {{{ proto string spl_object_id(object obj)
Return id for given object */
PHP_FUNCTION(spl_object_id)
{
zval *obj;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, o, obj) == FAILURE)
{
return;
}
RETURN_LONG(Z_OBJ_HANDLE_P(obj));
}
/* }}} */
Two questions:
1. Do you think this function should be included in PHP core?
2. If so, what should this function be called? I am undecided between
spl_object_id() and spl_object_handle() and corresponding get_...()
variants.
Ad 2. I lean towards ..._id() as ..._handle() suggests that you can do
something with that handle (think open file handle, etc).
What is your opinion about this?
Tnx,
b.
Re: [PHP-DEV] [RFC] GitHub Pull Requests Triage Team
Big +1 for me. This is good a idea to make contributors' work easier. On 31 October 2014 05:57, John Bafford jbaff...@zort.net wrote: Hi, I would like to propose the creation of a team to triage the pull requests on GitHub, to help ensure that the pull requests are handled in a timely manner. I am also volunteering to lead such a team, should the RFC be approved. https://wiki.php.net/rfc/github-pr PHP's GitHub repository has over 180 open pull requests. Many of these are bug fixes or new tests that should be incorporated into PHP, but have not been because the PRs aren't being regularly monitored. As a result, the large number of open pull requests may also be discouraging contributions, as potential contributors may see that pull requests are not being acted on and decline to submit changes. Thanks, -John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 回复： [PHP-DEV] Internal object orientation documentation available!
ER r q -- Reeze Sent with sparrow 在 2013年6月12日星期三，13:05，Michael Wallner 写道： On 10 June 2013 20:33, Nikita Popov nikita@gmail.com wrote: Hi internals! We just published some rather extensive documentation on internal object orientation: http://www.phpinternalsbook.com/classes_objects.html This is part of a larger project aimed at documenting the engine and making it accessible to new contributors. Any feedback is appreciated! That looks awesome; just asking: why didn't it go into http://php.net/internals? -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 回复： [PHP-DEV] Re: [VOTE] Allow non-scalar keys in foreach
Hi Nikita, I got some test failure with the patch, one test failure and some memory leaks. see: https://gist.github.com/reeze/5101596 -- reeze | reeze.cn 已使用 Sparrow (http://www.sparrowmailapp.com/?sig) 在 2013年3月7日星期四，上午1:28，Dmitry Stogov 写道： On Wed, Mar 6, 2013 at 9:16 PM, Nikita Popov nikita@gmail.com (mailto:nikita@gmail.com) wrote: On Wed, Mar 6, 2013 at 5:41 PM, Dmitry Stogov dmi...@zend.com (mailto:dmi...@zend.com) wrote: Hi Nikita, few notes about the patch... - you may avoid estrndup() in zend_hash_current_key_zval_ex() for interned strings. Good idea, I'll do that. - I didn't completely get why did you change the key operand type from IS_TMP_VAR to IS_VAR and how it affects performance As I understood now you need to allocate new zval on each loop iteration even for foreach over plain arrays. :( Good point, I didn't consider the performance implication the type change would have. The intent behind that was to avoid copying the get_current_key zval into the temporary (and destroying it then), but I didn't consider how it affects normal arrays. This should be changed back to TMP_VAR. It would be great. I can agree that new features may work slower, but really don't like when they slowdown existing and mach more usual cases. I wonder what would be a good way to avoid allocating a temporary zval for the key and freeing it again. Do you think it would be okay to pass EX_T((opline+1)-result.var).tmp_var into -get_current_key() so the value can be written directly into it without doing extra allocs/frees? I'm not sure it'll work. TMP_VARs don't initialize refcount, they can't be referenced or marked as a possible root of garbage. I took only a very quick look over the patch and didn't understand all the details, but probably it must be possible to copy iterator key into TMP_VAR and call copy_ctor(). Please, let me review the patch when it's ready (I won't be available on March 8 and weekend). Thanks. Dmitry.
[PHP-DEV] 回复： [PHP-DEV] Current Status of O+ on Windows
+1 s, Switch to a new opcode cacher is much easier than update PHP, and ZO+ is already compatible with 5.5. we could use ZO+ as soon as possible. -- reeze | reeze.cn 已使用 Sparrow (http://www.sparrowmailapp.com/?sig) 在 2013年3月2日星期六，下午4:43，Ferenc Kovacs 写道： On Sat, Mar 2, 2013 at 9:39 AM, Zeev Suraski z...@zend.com (mailto:z...@zend.com) wrote: -Original Message- From: Ferenc Kovacs [mailto:tyr...@gmail.com] Sent: Saturday, March 02, 2013 10:15 AM To: Pierre Joye; Dmitry Stogov Cc: Christopher Jones; Matt Ficken; internals@lists.php.net (mailto:internals@lists.php.net) Subject: Re: [PHP-DEV] Current Status of O+ on Windows Did you experiment with any options? Putting the date of your O+ snapshot would also be handy. Latest from here are used: http://windows.php.net/downloads/pecl/snaps/Optimizer/7.0.0-dev/ Dates are included. It would be nice to have it in the report as well, but we always use latest revision. It would however be much easier if there were PECL releases. +1 Dmitry, is there any objection against creating a pecl release? Could you tag the first version? The current vote that's going on right now deals with putting the extension into PHP itself. If that happens (which seems awfully likely at this point), why do we need it in PECL? We'd very much rather invest our very limited cycles into the code itself. We're probably roughly a week away from having builds as a part of the PHP 5.5 snaps. Zeev I see. so no O+ for 5.5? having a pecl release would be a small amount of work, which I would glad to help with. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
[PHP-DEV] 回复： [PHP-DEV] [RFC] Remove calls with incompatible Context
在 2012年8月4日星期六，上午6:40，Andrew Faulds 写道：
On 03/08/12 23:36, Etienne Kneuss wrote:
On Mon, Jul 30, 2012 at 7:31 PM, Gustavo Lopes glo...@nebm.ist.utl.pt
(mailto:glo...@nebm.ist.utl.pt) wrote:
https://wiki.php.net/rfc/incompat_ctx
An RFC for deprecating and removing $this from incompatible context.
Comments are welcome.
4+ years ago Marcus already wanted to clean that up in PHP6.
Definitely +1.
Best,
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
While we're at it,
$a = 'this';
$$a = new StdClass();
should be an error.
Also $GLOBALS['this'] = new StdClass();
https://bugs.php.net/bug.php?id=52428
then so does: extract(array('this' = 'scalar')); and the similar situation
that may import variables.
--
Andrew Faulds
http://ajf.me/
[PHP-DEV] 回复： [PHP-DEV] Re: 回复： [PHP-DEV] [RFC] Proposal namespace importing with from syntax
Hi,
在 2012年7月25日星期三，下午1:27，Laruence 写道：
Hi:
is there any really usage? I didn't see before. I don't think every
Yes, eg:
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/EntityRepository.php#L24
it could be:
from Doctrine\Common\Collections use ExpressionBuilder, Criteria,
ArrayCollection, ExpressionBuilder;
The Motivation is that I found many projects that use namespace have the
problem of repeat type
the same namespace again and again.
python feature is proper for PHP. PHP is not python.
I think it could be useful to reduce duplication, but not copy everything from
Python.
like many useful features we borrowed from other languages ;-)
-1 on this RFC
+1 for Stas
and one more thing, BC break.
Yes, introduce new features may break things, eg the new trait,insteadof in
5.4, and maybe
the comming finally, yield etc. but if it is desired, I think it may worth it.
Thanks for your feedback!
there are many ORM or DB warpper libraries defines `from` method, like:
$db-select()-from();
thanks
On Wed, Jul 25, 2012 at 1:22 PM, Stas Malyshev smalys...@sugarcrm.com
(mailto:smalys...@sugarcrm.com) wrote:
Hi!
No, we can not import namespace directly for now :
Of course you can. You just missing on what namespace import means in
PHP, it's not like Java (though a bit like Python).
?php
namespace A {
class B {}
}
namespace {
use A;
var_dump(new B());
}
use A is a no-op, just as the warnings tell you. You can just write A\B.
It's only 2 characters more. If your A is longer, then you can alias it
to something shorter.
and if we need alias we could：
?php
// reduce
use GlobalNamespace\SubSpace\ThirdSpace\Class1;
use GlobalNamespace\SubSpace\ThirdSpace\Class2 as Alias2;
use GlobalNamespace\SubSpace\ThirdSpace\ForthSpace\Class3 as Alias3;
You could just do
use GlobalNamespace\SubSpace\ThirdSpace as Spc;
$a = new Spc\Class1();
Hi Stas,
That is what I am trying to propose, maybe it could be more DRY?
thanks :)
--
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
--
Laruence Xinchen Hui
http://www.laruence.com/
[PHP-DEV] [RFC] Proposal namespace importing with from syntax
Hi, internals, I'm proposing a improvement to namespace importing. when using 'use' statement to import many classes, we have to duplicate many times even we are importing from the same namespace. I propose a new syntax to import classes\functions\constant in a single statement. here is the example: ?php // reduce use GlobalNamespace\SubSpace\ThirdSpace\Class1; use GlobalNamespace\SubSpace\ThirdSpace\Class2; use GlobalNamespace\SubSpace\ThirdSpace\ForthSpace\Class3; // to from GlobalNamespace\SubSpace\ThirdSace use Class1, Class2 as Alias2, ForthSpace\Class3 as Alias3; ? The above code should be self-explained. More info could be found at the RFC page and the patch. RFC: https://wiki.php.net/rfc/namespace-importing-with-from PATCH : https://github.com/reeze/php-src/compare/rfc-from-use Any Opinion, suggestion, improvement will be much appreciated. Thanks -- reeze | http://reeze.cn
[PHP-DEV] 回复： [PHP-DEV] [RFC] Proposal namespace importing with from syntax
Hi Andrew, 在 2012年7月24日星期二，下午11:39，Andrew Faulds 写道： On 24/07/12 16:35, Reeze wrote: Hi, internals, I'm proposing a improvement to namespace importing. when using 'use' statement to import many classes, we have to duplicate many times even we are importing from the same namespace. I propose a new syntax to import classes\functions\constant in a single statement. here is the example: ?php // reduce use GlobalNamespace\SubSpace\ThirdSpace\Class1; use GlobalNamespace\SubSpace\ThirdSpace\Class2; use GlobalNamespace\SubSpace\ThirdSpace\ForthSpace\Class3; // to from GlobalNamespace\SubSpace\ThirdSace use Class1, Class2 as Alias2, ForthSpace\Class3 as Alias3; ? The above code should be self-explained. More info could be found at the RFC page and the patch. RFC: https://wiki.php.net/rfc/namespace-importing-with-from PATCH : https://github.com/reeze/php-src/compare/rfc-from-use Any Opinion, suggestion, improvement will be much appreciated. Thanks Ah, so something a la python's from x import y, z? Sounds good. Somewhat surprised we don't already have this. One comment: use Class1, Class2 as Alias2, ... ; confuses me a bit. I read it as use (Class1, Class2) as Alias2, ... ;. //Perhaps this is It means use Class1 **and** use Class2 but aliased with name Alias2 etc. It almost the same as bare 'use' statement, but with a common prefix :) Thanks just a formatting issue (with newlines it would be more clear), but it looks a little weird to me. Just my 2¢. -- Andrew Faulds http://ajf.me/
[PHP-DEV] 回复： [PHP-DEV] [RFC] Proposal namespace importing with from syntax
Hi Stas,
在 2012年7月25日星期三，上午2:33，Stas Malyshev 写道：
Hi!
from GlobalNamespace\SubSpace\ThirdSace use Class1, Class2 as Alias2,
ForthSpace\Class3 as Alias3;
I'm not sure it's necessary. If you import a real lot of the classes
from the same namespace, just import the parent namespace. And this
No, we can not import namespace directly for now :
?php
namespace A {
class B {}
}
namespace {
use A;
var_dump(new B());
}
Warning: The use statement with non-compound name 'A' has no effect in
/Users/reeze/Opensource/php-test/php-src-master/a.php on line 7
if we wan to archive the goal of import anything. the only way is to declare
the current namespace
as the parent namespace we want to import from, eg:
?php
namespace Zend {
class B {}
}
namespace *Zend* {
var_dump(new B());
}
but this is not preferred for use code declared as the library we used.
syntax makes less clear what is the true name of Class2 and also by
similarity to python syntax would lead people to think it does the same
thing python one does - which it is not.
Sorry, I didn't make myself clear. the example I posted is not correct. It
didn't have to alias the imported classes.
'use' statement can alias the imported class too, the proposed 'from xx use yy'
is almost
the same as 'use'
The correct example should be:
?php
// if we don't want to duplicated then the follow could be
use GlobalNamespace\SubSpace\ThirdSpace\Class1;
use GlobalNamespace\SubSpace\ThirdSpace\Class2;
use GlobalNamespace\SubSpace\ThirdSpace\Class3;
// reduced to
from GlobalNamespace\SubSpace\ThirdSace use Class1, Class2, Class3 ;
?
and if we need alias we could：
?php
// reduce
use GlobalNamespace\SubSpace\ThirdSpace\Class1;
use GlobalNamespace\SubSpace\ThirdSpace\Class2 as Alias2;
use GlobalNamespace\SubSpace\ThirdSpace\ForthSpace\Class3 as Alias3;
// to
from GlobalNamespace\SubSpace\ThirdSace use Class1, Class2 as Alias2,
ForthSpace\Class3 as Alias3;
?
Thanks stas.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
[PHP-DEV] 回复： [PHP-DEV] Make try/catch brackets optinal
Hi， 在 2012年7月19日星期四，下午6:45，Rune Kaagaard 写道： +1 for the consistency of it. It's surprising that: if ($foo) return $bar; else return 42; works and: try maybe_dangerous(); catch(Dynamite $e) handle_error(); There is no condition after `try`, it's really hard to read without bracket. it becomes even worse if it didn't format pretty as above. does not. On Thu, Jul 19, 2012 at 12:11 PM, Peter Beverloo pe...@lvp-media.com (mailto:pe...@lvp-media.com) wrote: On Thu, Jul 19, 2012 at 11:06 AM, Rafael Dohms lis...@rafaeldohms.com.br (mailto:lis...@rafaeldohms.com.br)wrote: On Thu, Jul 19, 2012 at 12:03 PM, Charlie Somerville char...@charliesomerville.com (mailto:char...@charliesomerville.com) wrote: This has code readability problem written all over it. When maintaining it also has problems, like with the bracket-less if's. You would need to add brackets if you add an extra line here, as well as you might get unexpected behaviour of you forget to add brackets in that case. I've often heard people make this argument, but I've never found it to be a real concern in practise. Is this really such a common problem? I have seen this problem happen, people losing time trying to figure out what is wrong only to find its a missing bracket. As Paul said, this is bug-prone. Other bracket-less blocks allow authors to shoot themselves in the foot equally so, yet PHP supports these as well. The actual problem here is an inconsistency in the parser, which I'd consider to be a bug. Peter -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 回复： [PHP-DEV] installing from source on mac osx 10.7.3
Hi, I guess /usr/local/bin is writable. then: which version of php and autoconf? it may set the EXEEXT=.dSYM if so /usr/local/bin/php may becomes /usr/local/bin/php.dSYM will you take a look at the generated Makefile is there any value of this variable EXEEXT = ? -- reeze | reeze.cn 在 2012年7月15日星期日，上午11:45，Yader Hernandez 写道： I can't seem to get a vanilla php binary from a simple $ ./configure make make install The last few lines indicate that everything went well: Installing PHP SAPI module: cgi Installing PHP CGI binary: /usr/local/bin/ *Installing PHP CLI binary: /usr/local/bin/* Installing PHP CLI man page: /usr/local/man/man1/ Installing build environment: /usr/local/lib/php/build/ Installing header files: /usr/local/include/php/ Installing helper programs: /usr/local/bin/ program: phpize program: php-config Installing man pages: /usr/local/man/man1/ page: phpize.1 page: php-config.1 Installing PEAR environment: /usr/local/lib/php/ [PEAR] Archive_Tar - installed: 1.3.7 [PEAR] Console_Getopt - installed: 1.3.0 [PEAR] Structures_Graph- installed: 1.0.4 [PEAR] XML_Util - installed: 1.2.1 [PEAR] PEAR - installed: 1.9.4 Wrote PEAR system config file at: /usr/local/etc/pear.conf You may want to add: /usr/local/lib/php to your php.ini include_path when I look into /usr/local/bin the php cli binary is not there. Doing a locate does not find any php binary (even after an updatedb). There is one output that can be interpreted as an error but I don't think it has anything to do with not compiling php: Generating phar.php Generating phar.phar PEAR package PHP_Archive not installed: generated phar will require PHP's phar extension be enabled. I'm running on mac osx 10.7.3. I have no problems on Ubuntu 11.04. Has anyone ran into this issue? Is there some output I should be paying attention to?
Re: [PHP-DEV] Re: [PHP-QA] running tests in parallel?
look forward your futhur work！ make test takes really long time， with valgrind is almost unacceptable。 -- Reeze Sent from my iphone On 2012年5月3日Thursday at 19:42, Olivier Doucet wrote: Hi, 2012/5/3 zoe slattery aparac...@gmail.com: Hi Some years ago (in 2009) Stefan Priebsch, myself and a GSOC student worked on a version of run-tests.php which would run tests in parallel - I wrote about it here: http://zoomsplatter.blogspot.co.uk/2009/07/on-no-not-more-tests.html. I'm very glad you have free time to finish this :) I looked at source code recently, but was unable to see what was missing to get it running. I think I emailed you about this a year ago, then I moved to QA report project ;) Having tests running in parallel will be a huge improvement. Also having different output (like XML) will help for loading user feedbacks in http://qa.php.net/reports/ If you need any help on this, feel free to ask. Olivier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug/Req:#61422#39003 enble Type Hint autoloading
Hi internals: danko reported this bug#61422: Lack of autoload on type hinting breaks class_alias。 now parmeter type hint DID NOT trying to autoload. I think allow it autoloading could be helpful. BUGSCommit for quick refer: - https://bugs.php.net/bug.php?id=61422 - https://bugs.php.net/bug.php?id=39003 - http://svn.php.net/viewvc?view=revisionrevision=220906 PROPOSAL(FR)： **I'm asking if we can enable type hint autoloading?** I did some homework: - Before FIX for #39003, parameter type hint will try to autoload the hint class if not found. after this fix it will not. in bug#39003: the final result was DOC Problem, seems we all agreed that it SHOULD autoloading. - But in revision: http://svn.php.net/viewvc?view=revisionrevision=220906 It was **FIXED** I try to search RFC about typehint, I didn't find anything about it. It was commited really long time ago almost 6 years ago, it would be very nice if Antony Dovgal still remember it;) REASON： Here is my reason to ask whether we can enable it: 1. Autoload will only happened when function/method calling. so does any other autoloading, I mean it wouldn't hurt performance. 2. Class will be used for sure, so trying to autoload it is reasonable: - If we need check certain Class, then we have to use the class in function/method. - most of time it already loaded*, so autoloading happened rarely. 3. If pass the wrong type and the hinted class not found this gives autoloader a change to handle it like the #61422' (https://bugs.php.net/bug.php?id=61422)s test script did. we can do something if not found. since we use the class in function/method, autoload the class is reasonable. most of the time we would not use the *FEATURE*, but it could make it more flexible. PATCH: 1. change zend_verify_arg_class_kind to autoload class 2. if class can't load, zend_fetch_class silently return (No fatal here) to give zend_verify_arg_class_kind a chance to report previous catchable_fatal_error eg： Catchable fatal error: Argument 1 passed to func() must be an instance of AX, integer given。 a simple patch attached request for comment. Finally, What do you guys think about it? Thanks. Best, -- reeze | simpie.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Bug/Req:#61422#39003 enble Type Hint autoloading
Hi, Laruence:
I mean pass a wrong class object to a function/method. if the type
hinted Class didn't loaded, we
could try to load it. (if it's the right class, nothing happened), eg.
function func(NotFoundClass $a) {}
maybe we could pass another class instance.
$a = new DemoClass();
func($a);
It would be useful for class_alias like Bug#61422 requested.
It's a little narrow feature usage scenario，but it gives a way to handle
it. so I think
It might be useful。
if failed to autoload it raise E_CATCHABLE_FATAL, loaded class will simple
released
if user catch the E_CATABLE_FATAL, loaded class will be useful, since it
will be used later.
if loaded success everyone is happy.
On 1 May 2012 20:25, Laruence larue...@php.net wrote:
On Tue, May 1, 2012 at 8:03 PM, reeze reeze@gmail.com wrote:
Hi internals:
danko reported this bug#61422: Lack of autoload on type hinting breaks
class_alias。
now parmeter type hint DID NOT trying to autoload. I think allow it
autoloading could be helpful.
BUGSCommit for quick refer:
- https://bugs.php.net/bug.php?id=61422
- https://bugs.php.net/bug.php?id=39003
- http://svn.php.net/viewvc?view=revisionrevision=220906
PROPOSAL(FR)：
**I'm asking if we can enable type hint autoloading?**
I did some homework:
- Before FIX for #39003, parameter type hint will try to autoload the
hint
class if not found.
after this fix it will not. in bug#39003: the final result was
DOC
Problem, seems we all agreed
that it SHOULD autoloading.
- But in
revision: http://svn.php.net/viewvc?view=revisionrevision=220906 It was
**FIXED**
I try to search RFC about typehint, I didn't find anything
about
it. It was commited really long time ago
almost 6 years ago, it would be very nice if Antony
Dovgal still
remember it;)
REASON：
Here is my reason to ask whether we can enable it:
1. Autoload will only happened when function/method calling. so does any
other autoloading,
I mean it wouldn't hurt performance.
2. Class will be used for sure, so trying to autoload it is reasonable:
- If we need check certain Class, then we have to use the class in
function/method.
- most of time it already loaded*, so autoloading happened rarely.
3. If pass the wrong type and the hinted class not found this gives
autoloader a change to handle it
like the #61422's test script did. we can do something if not found.
since we use the class in
function/method, autoload the class is reasonable. most of the time
we
would not use the *FEATURE*,
but it could make it more flexible.
PATCH:
1. change zend_verify_arg_class_kind to autoload class
2. if class can't load, zend_fetch_class silently return (No fatal here)
to
give zend_verify_arg_class_kind a chance
to report previous catchable_fatal_error eg：
Catchable fatal error: Argument 1 passed to func() must be an instance of
AX, integer given。
a simple patch attached request for comment.
Finally, What do you guys think about it?
Hi:
thanks for writing this, but I was a little confused, please
correct me if I mis-understand you.
if you pass a right instance of class to a function , how can that
class not be loaded already?
for example:
function foo(Foo_Bar $a) {
}
how can you pass a Foo_Bar instance to function foo without
Foo_Bar class already defined?
thanks
Thanks.
Best,
--
reeze | simpie.com
--
Laruence Xinchen Hui
http://www.laruence.com/
--
http://reeze.cn
[PHP-DEV] [PATCH][Discussion] Ensure property name a valid label and properly handle array2object conversionReq for bugfix review.
Hi, folks:
Recently I have been trying to fix bugs on bugs.php.net. I've been looking at
the bug: https://bugs.php.net/bug.php?id=61655.
for short: after convert a stdClass with a property with number name to array
can't be access anymore.
after some code searching, I found that. class property lookup differs from
array's. when convert the
internal HashTable won't be touched. class property always lookup by string,
but array will try to handle
numeric(@see Zend/zend_hash.h:307 ZEND_HANDLE_NUMERIC macro).
I don't know whether this has been discussed before, if so forgive me please.
now PHP allow to access property with this syntax: $obj-{$expr} $expr can be
anything. PHP
didn't try to validate whether it is a valid label or not. the only problem is
we can't access it directly
like: $expr = '007gun'; $obj-{$expr} = 10; echo $obj-007gun; It's not a big
problem, we can still access
it with the same syntax. but after convert to array, we got problem.
On the contrary array to object conversion have the same problem:
?php
$ar = array(0 = value, 000invlidlabel = 2, key = value2);
$obj = (object)$ar;
$obj-0 will never be accessible, 000invilidlabel can be access, but can't
use normal property access syntax.
I know PHP make use of HashTable a lot, maybe because of performance concern or
historical reason.
but we always want to be better.
In my opinion:
1. I see no reason why user will set an invalid label as property name. because
It can be access with $obj-{$expr} only or sometime can never been accessed.
2. for the same reason array to object should at least let developer know
something they may not want to happen did happened.
so I make some change:
1. set a property name should be valid label(__set magic method also follow it)
2. raise warning and move invlid property names to a special property when
convert a array contains invlid key name to stdClass.
I just want to make things more consist, or maybe we just make sure numeric
keys works consist since php is so flexible.
Any thoughts?
BTW: I sent bugfix for bug#61347 ArrayIterator misrewind and gives misleading
notice when manipulating empty/moved to end array
https://github.com/php/php-src/pull/38 thanks @nikic @cataphract's great
suggestions, will someone take a look, do I still have to improve it?
Thank you!
--
reeze | reeze.cn
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 回复： [PHP-DEV] resume after exception
If just for exception recovery how about implement ruby's retry ?
http://www.tutorialspoint.com/ruby/ruby_loops.htm Ruby retry statement section.
在 2012年4月2日星期一，下午8:44，Rasmus Schultz 写道：
I was just reading about the new async/await keywords in C# 5.0, and while
this has no particular relevance to PHP as such, it got me thinking about
this idea...
What if you could resume execution after an exception was thrown?
Fictive example:
function test()
{
echo Begin Test!\n;
throw new Interrupt();
echo Execution resumed!;
}
try
{
test();
}
catch (Interrupt $e)
{
echo Execution interrupted.\n;
resume;
}
The output of this would be:
Begin Test!
Execution interrupted.
Execution resumed!
In other words, Interrupt is a new type of Exception, from which you can
recover, using the new resume keyword.
Taking this one step further, imagine it were also possible to serialize()
an Interrupt - and resume it at a later time. This would open up entirely
new possibilities for (AJAX) web-application frameworks, which would be
able to suspend execution, serialize the script state, return a response,
wait for further interaction from the user, and then resume execution.
I'm sure there are lots of problems with this idea, and perhaps it's not a
good fit for PHP at all, but I figured it couldn't harm to put the idea out
there anyway :-)
Any thoughts?
[PHP-DEV] 回复： [PHP-DEV] Re: bugs needs fix before 5.4.1
在 2012年3月31日星期六，下午3:31，Stas Malyshev 写道： On 3/30/12 7:27 PM, Yasuo Ohgaki wrote: Hi Stas, Just FYI. Following bugs are needed to be fixed before 5.4.1, I think. https://bugs.php.net/bug.php?id=61526 Which is right, doc or code? Both. The parameter means that first argument (object) can be a string, and if it is, it will be passed to autoloader to find the class. See bug #55475 for the discussion. If is set to false does it means the first parameter can't be string? Can't we just make the last parameter to autoload=true|false. if the first parameter is a string then try to find the class if not try autoloadding. if string will not be a String Class in 5.* I think it's ok to do like this. eg: callable and many mixed paramter. what do you think? https://bugs.php.net/bug.php?id=61507 This is worse than isset($str[0][0]) issue. Non-string offsets do not work in strings, because they don't make sense in strings. -- 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
[PHP-DEV] 回复： [PHP-DEV] Re: bugs needs fix before 5.4.1
Hi, From the NEWS file : + . Fixed bug #55475 (is_a() triggers autoloader, new optional 3rd argument to + is_a and is_subclass_of). (alan_k) The 3rd argument is add to let user choose autoload or not, but not a string or not. so maybe we can make it more clear. -- reeze 已使用 Sparrow (http://www.sparrowmailapp.com/?sig) 发送 在 2012年3月31日星期六，下午3:58，reeze 写道： 在 2012年3月31日星期六，下午3:31，Stas Malyshev 写道： On 3/30/12 7:27 PM, Yasuo Ohgaki wrote: Hi Stas, Just FYI. Following bugs are needed to be fixed before 5.4.1, I think. https://bugs.php.net/bug.php?id=61526 Which is right, doc or code? Both. The parameter means that first argument (object) can be a string, and if it is, it will be passed to autoloader to find the class. See bug #55475 for the discussion. If is set to false does it means the first parameter can't be string? Can't we just make the last parameter to autoload=true|false. if the first parameter is a string then try to find the class if not try autoloadding. if string will not be a String Class in 5.* I think it's ok to do like this. eg: callable and many mixed paramter. what do you think? https://bugs.php.net/bug.php?id=61507 This is worse than isset($str[0][0]) issue. Non-string offsets do not work in strings, because they don't make sense in strings. -- 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
[PHP-DEV] 回复： [PHP-DEV] Re: bugs needs fix before 5.4.1
在 2012年3月31日星期六，下午4:35，Stas Malyshev 写道： Hi! If is set to false does it means the first parameter can't be string? It can. But it won't be seen as a class name, but rather as a string, that is not an object that is an instance of a subclass of anything, so it will return false. Can't we just make the last parameter to autoload=true|false. if the first parameter is a string then try to find the class if not try autoloadding. We discussed all the solutions already and chose this one, please see discussion on the list and the bug I've referred to. I see no point in going through the same discussion again. Thanks for your kindly explanation and yohagaki's doc update I've got it.
Re: [PHP-DEV] Call non-static method staticly raise E_STRICT, but why call a static method instancely won't
On 2011年4月26日星期二 at 上午10:31, David Muir wrote:
On 26/04/11 09:37, Ben Schmidt wrote:
Back in PHP4 it was the only way to simulate an static call, but
nowadays it really don't make sense at all.
class Foo {
static function toString(Bar $bar) {
return 'Foo::toString($bar)';
}
function toString() {
return '$this-toString()';
}
}
$foo = new Foo();
echo $foo-toString(); // instance
echo Foo::toString(); // class
PHP will complain about the 2nd method (can't redefine function) but
for me
are 2 completely different methods.
I belive the current Object Model could be improved. isn't?
I agree. Backward compatibility is the only reason to keep this. It's a
pretty compelling reason, though. It's hard to know how to phase it out
non-invasively, too.
Ben.
Why not just deprecate it, and throw a E_STRICT warning? That's how
we're dealing with all other future BC breaks.
+1 just like call non-static method statically did
David
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Call non-static method staticly raise E_STRICT, but why call a static method instancely won't
Hi,
I am not sure it's the right place to discuss this. someday I found I call a
static method _instancely_.
the method is just a helper method when reviewing my code. I know I do the
wrong thing, but PHP doesn't
complain about it. then I do some tests like below:
?php
error_reporting(E_ALL ^ E_STRICT);
class A {
public function static staticFunc() {
echo static;
}
public function instanceFunc() {
echo instace;
}
}
A::instanceFunct(); // Strict Standards: Non-static method A::instanceFunc() ...
$a = new A();
$a-staticFunc(); // Just static no E_STRICT error raised
I know it's the wrong way to do like these, maybe there are some historical
reasons to allow these.
I just wonder why previous method call raise E_STRICT but later not.
Yes, something could be done doesn't means we should, but we could stop things
like happened.
-
http://reeze.cn
