Re: [PHP-DEV] User defined session serialize handler
Hi Thomas, On Sat, Jan 24, 2015 at 12:45 PM, Thomas Bley wrote: > Sessions take a big amount of data in production systems, so it might be > worth to use msgpack (or others) as an option. Yes, it is. PHP's serialize (both php/php_serialize handler uses PHP's serialize) is not a fastest serializer. msgpack seems good. I'll try few serialize methods see if there is good one or even may write binary serializer for the best performance. Once user defined session serialize handler is implemented, users may try various serializers by themselves, too. Thank you for your feedback! Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Removing base class from session handler
Hi, On Sat, Jan 24, 2015 at 2:24 AM, Yasuo Ohgaki wrote: > Hi Stas, > > On Sat, Jan 24, 2015 at 8:49 AM, Stanislav Malyshev > wrote: > >> > This is the only reasonable use I know. I would to write user >> > serializer(read/writer) >> > handler for it. >> >> So we went from no reasonable use to one reasonable use, documented at >> the manual. I think it is also reasonable to suppose there are more uses >> for it. >> > > This is because session module lacks user defined serializer. Save handler > handles session data storage. Serialize handler handles how data is > converted/represented. IMHO. > That's not the only use case. Some time ago I proposed a session.match_ip feature and argued that if I wanted to implement it in userland code, I'd have to implement the *whole* session handler from scratch. An example using the SessionHandler class proved me wrong in that regard. Surely, people are using it for other stuff as well and it's not about the serializer. > I would like to make SessionHandler deprecated, encourage user serialize > handler for new PHP because it's more efficient and clean. Do you agree? > How can it possibly be more efficient and clean if you have to re-implement everything with user-level code? > Let's keep SessionHandler class. However, > PHP_FUNCTION(session_set_save_handler) > should be cleaned up to verify implemented/extended interface/class. It's > BC. > Do you have opinion for this? php > session_set_save_handler(new stdclass); PHP Warning: session_set_save_handler() expects parameter 1 to be SessionHandlerInterface, object given in php shell code on line 1 Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] Types on the right or on the left
I would like to pick up this discussion again - now that the return type hint
RFC has passed, congratulations :)
As a quick reminder, this discussion should not be whether we want to put the
return types on the left or on the right but mainly if we want to have
consistency (I do not want to downgrade the return type hint RFC either, that
is the reason why I have waited till the vote was closed). Once agreed upon
that consistency should be key when it comes down to the place of type hints,
we can then discuss what approach PHP shall take in the future (all left or all
right).
The more I think about it the more I am in favour of putting types on the right
hand side. I think it is more readable and less ambiguous. Consider the
following:
class A{
private Foo $a; //is "Foo" a modifier as well?
private static $b; //or is "static" a type?
}
vs.
class A{
private $a : Foo;
private static $b;
}
Assuming we will introduce parameter modifiers such as final or similar in the
future, then it is also less ambiguous for parameter type hints:
function foo(final A $a, final $b){}
vs
function foo(final $a : A, final $b){}
I am sure people will tell me that such a change (all types on the right,
parameter type hints as well) is huge BC and unfeasible. I would agree that it
is a huge BC but I would claim it is necessary and manageable. Code could be
migrated automatically with an appropriate tool and it does not need to happen
for PHP 7 but maybe for PHP 8. Besides, pretty much the same impact has the
return type RFC now, because the manual should be updated accordingly to
reflect the new syntax IMO. Sounds like lot of work but it should be possible
to migrate the docs with a tool. And it needs to be done IMO otherwise the
WTF/minute measurement will increase when using PHP (due to lot of "WTF! In the
docs the return types are on the left and in code they are on the right hand
side") - but maybe I am wrong.
Anyway, I am primarily in favour of consistency - regardless if all left or all
right - and mixing both styles is a very bad idea IMO - do you know any
language which has taken a mixed approach (besides Hack)?
Cheers,
Robert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls
On 24 January 2015 00:15:01 GMT, Stanislav Malyshev wrote: >Hi! > >> Foo::bar(); // OK >> ['Foo', 'bar'](); // OK >> 'Foo::bar'(); // FATAL ERROR > >I'm not sure why one would ever need/want the latter. IMO, it just >looks >weird. Well, they both look weird as literals like that, but the array looks the wierder of the two to me. Representing a static call in some external configuration is an example where a single string in normal PHP syntax would make more sense than needing to create a 2-element array. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
On 24 January 2015 11:09:04 GMT, Robert Stoll wrote: >Besides, pretty much the same impact has the return type RFC now, >because the manual should be updated accordingly to reflect the new >syntax IMO. Sounds like lot of work but it should be possible to >migrate the docs with a tool. As I said in another thread, updating the manual is nothing at all like changing the language. It is a single, centrally-controlled set of content, which doesn't have to be compatible with multiple environments, and has a minimum requirement of internal consistency which has been met in some cases with arbitrary conventions unrelated to the language. It may even be possible to change the notation without changing the source, by altering the output templates, but if not, an automated change to use a new convention more similar to new language syntax is a no-brainer. As for the rest, I don't see the pressing need to break a whole bunch of established syntax here. It will just make it impossible to run code under multiple versions, and brings a very minor benefit. I'm not even convinced that return types and parameter types are related enough to require consistency in an ideal world. The type hint to the left of a parameter is the type of that parameter, but a return type hint is not the type of the function - if the function were a first-class object, it's type would be "function", or a specific type such as "function(int, string): string". The function annotation means "produces a", not "is a". This isn't a theoretically rigorous argument, but to my mind it gives a sufficient reason for the syntaxes to be chosen independently. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Default parent constructors RFC
Le 11/01/2015 01:34, Stanislav Malyshev a écrit : I'd like to initiate a vote on this RFC: https://wiki.php.net/rfc/default_ctor Hi, After discussing this RFC with other people of AFUP, we would be +1 on this, by a small margin. On one side, being able to always call a parent constructor without having to check if it exists could be useful, especially when the parent class is in a library. On the other hand, it feels like the current situation doesn't cause problems that often; and if a constructor is added to a parent class, it will likely expect specific parameters, which means child classes will need to be updated anyway. -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] User defined session serialize handler
On 24 January 2015 03:45:22 GMT, Thomas Bley wrote: >Sessions take a big amount of data in production systems, so it might >be worth to use msgpack (or others) as an option. This came up before, and it was pointed out that a fast implementation of something like msgpack would need to be implemented as an extension anyway, not userspace code. And extensions can already register a serialisation handler, so do not need a userspace callback; I believe igbinary implements this, for instance. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] User defined session serialize handler
On 24 January 2015 02:28:07 GMT, Yasuo Ohgaki wrote: >I also would like to php_serialize handler as the default serializer >and >make php/php_binary deprecated. > >php/php_binary serializers are made to work with register_globals and >have >many limitations. >e.g. Integer key not allowed, key cannot start with number, delimiter >chars >are invalid and >ignored, etc. php_serialize does not have such limitations at all. I'm in favour of this part. In the unlikely event that someone needs to access the same session data with PHP 5 and 7, they should be able to switch back to the old format, but for most users, plain serialise is a much more sensible format. An additional problem with the existing format is that there are no functions to work with it outside of the $_SESSION array, so you can't just unserialize a local copy. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] User defined session serialize handler
Hi Rowan, On Sun, Jan 25, 2015 at 12:35 AM, Rowan Collins wrote: > On 24 January 2015 03:45:22 GMT, Thomas Bley wrote: > >Sessions take a big amount of data in production systems, so it might > >be worth to use msgpack (or others) as an option. > > This came up before, and it was pointed out that a fast implementation of > something like msgpack would need to be implemented as an extension anyway, > not userspace code. And extensions can already register a serialisation > handler, so do not need a userspace callback; I believe igbinary implements > this, for instance. I agree that fast serializer should be implemented by native code. However, once user serialize handler is implemented, overhead of user serialize handler is calling 2 PHP functions. i.e. serialize/unserialize functions whatever module provides. Users may compress/encrypt session data whatever methods also. If user wants serialize/compress/encrypt, 6 PHP functions calls are required. It would be reasonably fast. User serialize handler provides much freedom than now. I cannot write all possible serialize handlers users want. Therefore, I would like to introduce user serialize handler. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] User defined session serialize handler
Hi all, On Sun, Jan 25, 2015 at 1:20 AM, Yasuo Ohgaki wrote: > However, once user serialize handler is implemented, overhead of user > serialize handler is calling 2 PHP functions. i.e. serialize/unserialize > functions whatever module provides. Users may compress/encrypt session data > whatever methods also. If user wants serialize/compress/encrypt, 6 PHP > functions calls are required. It would be reasonably fast. User serialize > handler provides much freedom than now I forgot about session_set_serialize_handler() call. So there is an additional PHP function call. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC][VOTE] Default parent constructors RFC
Hi all, On Sun, Jan 11, 2015 at 9:34 AM, Stanislav Malyshev wrote: > I'd like to initiate a vote on this RFC: > https://wiki.php.net/rfc/default_ctor > > TLDR: this RFC would make a call to parent::__construct() succeed (as in > "not produce a fatal error") even if the parent class does not define a > ctor. Same for __destruct and __clone. The motivation for it is in the > RFC and here: > https://php100.wordpress.com/2014/11/04/default-constructors/ > > I've chosen the simplest way of implementing it, as suggested by Dmitry, > in https://github.com/php/php-src/pull/990. There are other > alternatives, but I think the simpler the better. > > Previous discussion is at: http://marc.info/?t=14163026601&r=2&w=2 > It seems -1 vote are increasing. Therefore, I would like to mention benefits of this RFC again. This RFC is great for rapid app development/prototyping. There are many cases that base class constructors calls are needed or not. This RFC allow us to just call parent constructor, then add implementation later if it is needed. It makes code maintenance easier for production code also. I can understand the reason why people vote -1 (non existent method/function calls should not be able to be called and raise), but benefits override. IMHO. PHP is for easier/faster development, isn't it? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Removing base class from session handler
Hi Andrey, On Sat, Jan 24, 2015 at 6:34 PM, Andrey Andreev wrote: > > Let's keep SessionHandler class. However, > > PHP_FUNCTION(session_set_save_handler) > > should be cleaned up to verify implemented/extended interface/class. It's > > BC. > > Do you have opinion for this? > > php > session_set_save_handler(new stdclass); > PHP Warning: session_set_save_handler() expects parameter 1 to be > SessionHandlerInterface, object given in php shell code on line 1 As I pasted code in this thread, current code does not check if supplied object has valid class/interface, but it checks methods implemented. SdtClass does not have them obviously, therefore it raises error. It's a legacy code when PHP didn't have proper OOP support. This is the code that I'm willing to remove/change. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Types on the right or on the left
On Sat, Jan 24, 2015 at 7:42 AM, Rowan Collins wrote: > On 24 January 2015 11:09:04 GMT, Robert Stoll wrote: > >>Besides, pretty much the same impact has the return type RFC now, >>because the manual should be updated accordingly to reflect the new >>syntax IMO. Sounds like lot of work but it should be possible to >>migrate the docs with a tool. > > As I said in another thread, updating the manual is nothing at all like > changing the language. It is a single, centrally-controlled set of content, > which doesn't have to be compatible with multiple environments, and has a > minimum requirement of internal consistency which has been met in some cases > with arbitrary conventions unrelated to the language. It may even be possible > to change the notation without changing the source, by altering the output > templates, but if not, an automated change to use a new convention more > similar to new language syntax is a no-brainer. Assuming that we are using well-formed DocBook for the methodsynopsis (which at a glance we seem to do) then hopefully the doc renderer can take care of the change. It will need to change to use a chunking function, which I'm not familiar with yet. I'm certainly willing to look into this. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
Hi all,
On Sun, Dec 21, 2014 at 7:01 AM, F & N Laupretre
wrote:
> I don't know if this was discussed before. So, tell me what you think
> before
> I write an RFC.
>
>
>
> I would like to propose that namespaces, functions, and classes become
> case-sensitive (constants are already case-sensitive). Actually, I never
> understood why they are case-insensitive. Even if the performance gain is
> negligible, I think it could be the right time to question this.
>
I'm writing this mail without reading current zend code.
Anyway, is it feasible to raise E_DEPRECATE without much performance
penalty?
For example,
if (!strcmp(name, name_to_be_searched)) {
do_something;
} else if (!strcasecmp(name, name_to_be_searched) {
rase_error;
do_something;
}
Duplicated codes may be removed by macro. strcasecmp() checks may be removed
10 years later or more.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] Re: PHP7 Homework for everyone reading this list
I step in another failing test that I would like to confirm if that is an issue or it was an accepted backward incompatibility due the phpng (I couldn't find anything on the RFC and the UPGRADING regarding that). Here is the code: http://3v4l.org/h7TEV The issue happens when the variable used to split data using list() is also part of the variables that will receive the values. In the case of my example, $data contains the data to be splitted and also will receive the first value. Is that an issue or BC break? On Sat, Jan 24, 2015 at 12:53 AM, Juan Basso wrote: > This is not a segfault, but another issue exclusive from PHP 7 > https://bugs.php.net/bug.php?id=68897 > > On Fri, Jan 23, 2015 at 11:54 PM, Juan Basso wrote: > >> I found another segment fault on PHP 7 during CakePHP 3 tests. I reported >> the issue on https://bugs.php.net/bug.php?id=68896 >> >> On Fri, Jan 23, 2015 at 5:01 PM, Jan Ehrhardt wrote: >> >>> Jan Ehrhardt in php.internals (Fri, 23 Jan 2015 22:18:50 +0100): >>> >Dmitry Stogov in php.internals (Fri, 23 Jan 2015 17:54:45 +0400): >>> >>"master" branch. >>> > >>> >propro, raphf and pecl_http do not compile with the master branch. >>> >You'll have to checkout the phpng branch. These extensions did compile >>> >and load: >>> > >>> https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.htm >>> > >>> >Build: >>> > >>> https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.zip >>> >>> The TS build is very much alike: >>> https://phpdev.toolsforresearch.com/php-7.0.0-dev-Win32-VC11-x86.htm >>> https://phpdev.toolsforresearch.com/php-7.0.0-dev-Win32-VC11-x86.zip >>> >>> What you cannot see in phpinfo() is that php7apache2_4.dll and even >>> php7apache2_2.dll also compile fine. >>> >>> >Maybe there are other PECL extension that have PHP7 branches, unknown to >>> >you and me. >>> >>> Jan >>> >>> -- >>> PHP Internals - PHP Runtime Development Mailing List >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >>> >> >
Re: [PHP-DEV] Re: PHP7 Homework for everyone reading this list
Hey: On Sat, Jan 24, 2015 at 1:53 PM, Juan Basso wrote: > This is not a segfault, but another issue exclusive from PHP 7 > https://bugs.php.net/bug.php?id=68897 thanks, this one is fixed and committed, and also got a fix for the previosly segfault one, but I need do some confirms before I commit it.. thanks > > On Fri, Jan 23, 2015 at 11:54 PM, Juan Basso wrote: > >> I found another segment fault on PHP 7 during CakePHP 3 tests. I reported >> the issue on https://bugs.php.net/bug.php?id=68896 >> >> On Fri, Jan 23, 2015 at 5:01 PM, Jan Ehrhardt wrote: >> >>> Jan Ehrhardt in php.internals (Fri, 23 Jan 2015 22:18:50 +0100): >>> >Dmitry Stogov in php.internals (Fri, 23 Jan 2015 17:54:45 +0400): >>> >>"master" branch. >>> > >>> >propro, raphf and pecl_http do not compile with the master branch. >>> >You'll have to checkout the phpng branch. These extensions did compile >>> >and load: >>> >https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.htm >>> > >>> >Build: >>> >https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.zip >>> >>> The TS build is very much alike: >>> https://phpdev.toolsforresearch.com/php-7.0.0-dev-Win32-VC11-x86.htm >>> https://phpdev.toolsforresearch.com/php-7.0.0-dev-Win32-VC11-x86.zip >>> >>> What you cannot see in phpinfo() is that php7apache2_4.dll and even >>> php7apache2_2.dll also compile fine. >>> >>> >Maybe there are other PECL extension that have PHP7 branches, unknown to >>> >you and me. >>> >>> Jan >>> >>> -- >>> PHP Internals - PHP Runtime Development Mailing List >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >>> >> -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP7 Homework for everyone reading this list
Hey: On Sun, Jan 25, 2015 at 1:26 AM, Juan Basso wrote: > I step in another failing test that I would like to confirm if that is an > issue or it was an accepted backward incompatibility due the phpng (I > couldn't find anything on the RFC and the UPGRADING regarding that). > > Here is the code: http://3v4l.org/h7TEV > > The issue happens when the variable used to split data using list() is also > part of the variables that will receive the values. In the case of my > example, $data contains the data to be splitted and also will receive the > first value. > > Is that an issue or BC break? this is a knew BC break, please read "Changes to list()" section in the AST RFC https://wiki.php.net/rfc/abstract_syntax_tree thanks > > On Sat, Jan 24, 2015 at 12:53 AM, Juan Basso wrote: > >> This is not a segfault, but another issue exclusive from PHP 7 >> https://bugs.php.net/bug.php?id=68897 >> >> On Fri, Jan 23, 2015 at 11:54 PM, Juan Basso wrote: >> >>> I found another segment fault on PHP 7 during CakePHP 3 tests. I reported >>> the issue on https://bugs.php.net/bug.php?id=68896 >>> >>> On Fri, Jan 23, 2015 at 5:01 PM, Jan Ehrhardt wrote: >>> Jan Ehrhardt in php.internals (Fri, 23 Jan 2015 22:18:50 +0100): >Dmitry Stogov in php.internals (Fri, 23 Jan 2015 17:54:45 +0400): >>"master" branch. > >propro, raphf and pecl_http do not compile with the master branch. >You'll have to checkout the phpng branch. These extensions did compile >and load: > https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.htm > >Build: > https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.zip The TS build is very much alike: https://phpdev.toolsforresearch.com/php-7.0.0-dev-Win32-VC11-x86.htm https://phpdev.toolsforresearch.com/php-7.0.0-dev-Win32-VC11-x86.zip What you cannot see in phpinfo() is that php7apache2_4.dll and even php7apache2_2.dll also compile fine. >Maybe there are other PECL extension that have PHP7 branches, unknown to >you and me. Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php >>> >> -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP7 Homework for everyone reading this list
I see. Shouldn't this BC break be added on the UPGRADING file too? I can open a PR if necessary. On Sat, Jan 24, 2015 at 12:40 PM, Xinchen Hui wrote: > Hey: > > On Sun, Jan 25, 2015 at 1:26 AM, Juan Basso wrote: > > I step in another failing test that I would like to confirm if that is an > > issue or it was an accepted backward incompatibility due the phpng (I > > couldn't find anything on the RFC and the UPGRADING regarding that). > > > > Here is the code: http://3v4l.org/h7TEV > > > > The issue happens when the variable used to split data using list() is > also > > part of the variables that will receive the values. In the case of my > > example, $data contains the data to be splitted and also will receive the > > first value. > > > > Is that an issue or BC break? > this is a knew BC break, please read "Changes to list()" section in > the AST RFC https://wiki.php.net/rfc/abstract_syntax_tree > > thanks > > > > > On Sat, Jan 24, 2015 at 12:53 AM, Juan Basso wrote: > > > >> This is not a segfault, but another issue exclusive from PHP 7 > >> https://bugs.php.net/bug.php?id=68897 > >> > >> On Fri, Jan 23, 2015 at 11:54 PM, Juan Basso wrote: > >> > >>> I found another segment fault on PHP 7 during CakePHP 3 tests. I > reported > >>> the issue on https://bugs.php.net/bug.php?id=68896 > >>> > >>> On Fri, Jan 23, 2015 at 5:01 PM, Jan Ehrhardt > wrote: > >>> > Jan Ehrhardt in php.internals (Fri, 23 Jan 2015 22:18:50 +0100): > >Dmitry Stogov in php.internals (Fri, 23 Jan 2015 17:54:45 +0400): > >>"master" branch. > > > >propro, raphf and pecl_http do not compile with the master branch. > >You'll have to checkout the phpng branch. These extensions did > compile > >and load: > > > > https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.htm > > > >Build: > > > > https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.zip > > The TS build is very much alike: > https://phpdev.toolsforresearch.com/php-7.0.0-dev-Win32-VC11-x86.htm > https://phpdev.toolsforresearch.com/php-7.0.0-dev-Win32-VC11-x86.zip > > What you cannot see in phpinfo() is that php7apache2_4.dll and even > php7apache2_2.dll also compile fine. > > >Maybe there are other PECL extension that have PHP7 branches, > unknown to > >you and me. > > Jan > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > > >>> > >> > > > > -- > Xinchen Hui > @Laruence > http://www.laruence.com/ >
Re: [PHP-DEV] Re: PHP7 Homework for everyone reading this list
Hey: On Sun, Jan 25, 2015 at 1:43 AM, Juan Basso wrote: > I see. Shouldn't this BC break be added on the UPGRADING file too? I can > open a PR if necessary. > I think it's not necessary, for such a rare usage.. :) thanks > On Sat, Jan 24, 2015 at 12:40 PM, Xinchen Hui wrote: >> >> Hey: >> >> On Sun, Jan 25, 2015 at 1:26 AM, Juan Basso wrote: >> > I step in another failing test that I would like to confirm if that is >> > an >> > issue or it was an accepted backward incompatibility due the phpng (I >> > couldn't find anything on the RFC and the UPGRADING regarding that). >> > >> > Here is the code: http://3v4l.org/h7TEV >> > >> > The issue happens when the variable used to split data using list() is >> > also >> > part of the variables that will receive the values. In the case of my >> > example, $data contains the data to be splitted and also will receive >> > the >> > first value. >> > >> > Is that an issue or BC break? >> this is a knew BC break, please read "Changes to list()" section in >> the AST RFC https://wiki.php.net/rfc/abstract_syntax_tree >> >> thanks >> >> > >> > On Sat, Jan 24, 2015 at 12:53 AM, Juan Basso wrote: >> > >> >> This is not a segfault, but another issue exclusive from PHP 7 >> >> https://bugs.php.net/bug.php?id=68897 >> >> >> >> On Fri, Jan 23, 2015 at 11:54 PM, Juan Basso wrote: >> >> >> >>> I found another segment fault on PHP 7 during CakePHP 3 tests. I >> >>> reported >> >>> the issue on https://bugs.php.net/bug.php?id=68896 >> >>> >> >>> On Fri, Jan 23, 2015 at 5:01 PM, Jan Ehrhardt >> >>> wrote: >> >>> >> Jan Ehrhardt in php.internals (Fri, 23 Jan 2015 22:18:50 +0100): >> >Dmitry Stogov in php.internals (Fri, 23 Jan 2015 17:54:45 +0400): >> >>"master" branch. >> > >> >propro, raphf and pecl_http do not compile with the master branch. >> >You'll have to checkout the phpng branch. These extensions did >> > compile >> >and load: >> > >> >> https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.htm >> > >> >Build: >> > >> >> https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.zip >> >> The TS build is very much alike: >> https://phpdev.toolsforresearch.com/php-7.0.0-dev-Win32-VC11-x86.htm >> https://phpdev.toolsforresearch.com/php-7.0.0-dev-Win32-VC11-x86.zip >> >> What you cannot see in phpinfo() is that php7apache2_4.dll and even >> php7apache2_2.dll also compile fine. >> >> >Maybe there are other PECL extension that have PHP7 branches, >> > unknown to >> >you and me. >> >> Jan >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> >> >>> >> >> >> >> >> >> -- >> 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
Re: [PHP-DEV] Re: PHP7 Homework for everyone reading this list
On Sat, Jan 24, 2015 at 6:40 PM, Xinchen Hui wrote: > Hey: > > On Sun, Jan 25, 2015 at 1:26 AM, Juan Basso wrote: > > I step in another failing test that I would like to confirm if that is an > > issue or it was an accepted backward incompatibility due the phpng (I > > couldn't find anything on the RFC and the UPGRADING regarding that). > > > > Here is the code: http://3v4l.org/h7TEV > > > > The issue happens when the variable used to split data using list() is > also > > part of the variables that will receive the values. In the case of my > > example, $data contains the data to be splitted and also will receive the > > first value. > > > > Is that an issue or BC break? > this is a knew BC break, please read "Changes to list()" section in > the AST RFC https://wiki.php.net/rfc/abstract_syntax_tree > > thanks > We also document this on http://php.net/list: > Modification of the array during list() execution (e.g. using list($a, $b) = $b) results in undefined behavior. If we want, we could make this defined behavior (we would have to disable CV optimization on the $b fetch). I don't really care personally. Nikita
Re: [PHP-DEV] Removing base class from session handler
Hi Andrey, On Sat, Jan 24, 2015 at 6:34 PM, Andrey Andreev wrote: > > This is because session module lacks user defined serializer. Save > handler > > handles session data storage. Serialize handler handles how data is > > converted/represented. IMHO. > > > > That's not the only use case. > > Some time ago I proposed a session.match_ip feature and argued that if > I wanted to implement it in userland code, I'd have to implement the > *whole* session handler from scratch. An example using the > SessionHandler class proved me wrong in that regard. For me, IP address matching check does not belong to save handler. I would implement it in other place. What's the reason why you need to implement IP address matching in save handler? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Re: PHP7 Homework for everyone reading this list
I see. I guess that's fine. I opened a PR for CakePHP to update the code and avoid this. Thanks. On Sat, Jan 24, 2015 at 12:47 PM, Nikita Popov wrote: > On Sat, Jan 24, 2015 at 6:40 PM, Xinchen Hui wrote: > >> Hey: >> >> On Sun, Jan 25, 2015 at 1:26 AM, Juan Basso wrote: >> > I step in another failing test that I would like to confirm if that is >> an >> > issue or it was an accepted backward incompatibility due the phpng (I >> > couldn't find anything on the RFC and the UPGRADING regarding that). >> > >> > Here is the code: http://3v4l.org/h7TEV >> > >> > The issue happens when the variable used to split data using list() is >> also >> > part of the variables that will receive the values. In the case of my >> > example, $data contains the data to be splitted and also will receive >> the >> > first value. >> > >> > Is that an issue or BC break? >> this is a knew BC break, please read "Changes to list()" section in >> the AST RFC https://wiki.php.net/rfc/abstract_syntax_tree >> >> thanks >> > > We also document this on http://php.net/list: > > Modification of the array during list() execution (e.g. using list($a, > $b) = $b) results in undefined behavior. > > If we want, we could make this defined behavior (we would have to disable > CV optimization on the $b fetch). I don't really care personally. > > Nikita >
Re: [PHP-DEV] Re: PHP7 Homework for everyone reading this list
On Fri, Jan 23, 2015 at 10:18 PM, Jan Ehrhardt wrote: > Dmitry Stogov in php.internals (Fri, 23 Jan 2015 17:54:45 +0400): >>"master" branch. > > propro, raphf and pecl_http do not compile with the master branch. > You'll have to checkout the phpng branch. These extensions did compile > and load: > https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.htm > > Build: > https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.zip > > Maybe there are other PECL extension that have PHP7 branches, unknown to > you and me. > > Jan > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > Hello, may I use your build for testing my applications compability with PHP 7? I would like to try PHP 7, but I'm not really feeling like compiling it by myself for Windows (I probably even don't have all the tools needed for it); or is there a simple HOWTO for building it myself? Regards Pavel Kouril -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
Hi all, On Tue, Nov 4, 2014 at 12:39 AM, Andrea Faulds wrote: > > On 3 Nov 2014, at 15:07, Robert Stoll wrote: > > > > It adds the type hint on the right hand side of the function (of the > identifier). In contrast to parameters where the > > type hint is placed on the left hand side of the identifier. > > Mixing both, having some types on the left and others on the right, > seems like another inconsistency in the language > > design to me. > > These inconsistencies exist for two reasons: > > - Opposition to doing it the other way > - Hack already doing it this way > > I don’t think `function void foo();` will happen, since that’s been > previously rejected as it breaks gripping for “function foo”. Similarly, I > don’t think `public $foo: Foo;` will happen, given Hack does it as `public > Foo $foo;`. > I agree with Andrea. There are people who dislike syntax, and/or thinks PHP missing check(i.e. array format, etc). These people should request DbC. DbC is more powerful than simple type checks and have no performance penalty in production. (I'm not saying type hinting is useless. I'll use it where it is appropriate, too.) I wish I have time for diving into Zend code, but it would not happen in short term. Therefore, I'm hoping someone to implement DbC :) Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Re: PHP7 Homework for everyone reading this list
On Jan 25, 2015 12:45 AM, "Xinchen Hui" wrote: > > Hey: > > On Sun, Jan 25, 2015 at 1:43 AM, Juan Basso wrote: > > I see. Shouldn't this BC break be added on the UPGRADING file too? I can > > open a PR if necessary. > > > I think it's not necessary, for such a rare usage.. :) Every change should be there. Small or big. It will help migrations and when one wonders if something is a bug or an expected BC.
Re: [PHP-DEV] Re: PHP7 Homework for everyone reading this list
Pavel Kou?il in php.internals (Sat, 24 Jan 2015 19:07:28 +0100): >> https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.htm >> https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.zip https://phpdev.toolsforresearch.com/php-7.0.0-dev-Win32-VC11-x86.htm https://phpdev.toolsforresearch.com/php-7.0.0-dev-Win32-VC11-x86.zip >may I use your build for testing my applications compability with PHP7? Yes, of course. That is what they are for. In the meantime I have found out that PHP7 will run as mod_php in Apache VC11 x86. Need lines in the htttpd.conf something like: PHPINIDir "/phpdev/php70.x86/" LoadModule php7_module "/phpdev/php70.x86/php7apache2_4.dll" > I would like to try PHP 7, but I'm not really feeling like >compiling it by myself for Windows (I probably even don't have all the >tools needed for it); or is there a simple HOWTO for building it >myself? I am following more or less these guides: https://wiki.php.net/internals/windows https://wiki.php.net/internals/windows/stepbystepbuild For building PHP7 I am using Visual Studio 2012 Express for Windows Desktop aka VC11. I do not have a Pro version of VC11, but the Express version works fine as well. The hard part is to find the appriopate dependent libraries. http://windows.php.net/downloads/php-sdk/deps-5.6-vc11-x86.7z could give you a jump start, but if you want to build PECL extensions with dependent libraries you are on your own I build PHP myself for every 5.3/4/5/6 release. See http://www.apachelounge.com/viewtopic.php?t=6359 My PHP 5.6 nts builds contain contains 105 extensions. Only 44 of them compile for PHP7. There still is a long way to go for all extension maintainers! Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP7 Homework for everyone reading this list
Hi Jan, On Sat, January 24, 2015 21:31, Jan Ehrhardt wrote: > Pavel Kou?il in php.internals (Sat, 24 Jan 2015 19:07:28 +0100): > >>> > https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.htm > >>> > https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.zip > > > https://phpdev.toolsforresearch.com/php-7.0.0-dev-Win32-VC11-x86.htm > https://phpdev.toolsforresearch.com/php-7.0.0-dev-Win32-VC11-x86.zip > > >> may I use your build for testing my applications compability with PHP7? >> > > Yes, of course. That is what they are for. In the meantime I have found > out that PHP7 will run as mod_php in Apache VC11 x86. Need lines in the > htttpd.conf something like: > > PHPINIDir "/phpdev/php70.x86/" > LoadModule php7_module "/phpdev/php70.x86/php7apache2_4.dll" > > >> I would like to try PHP 7, but I'm not really feeling like >> compiling it by myself for Windows (I probably even don't have all the >> tools needed for it); or is there a simple HOWTO for building it myself? >> > > I am following more or less these guides: > https://wiki.php.net/internals/windows > https://wiki.php.net/internals/windows/stepbystepbuild > > > For building PHP7 I am using Visual Studio 2012 Express for Windows > Desktop aka VC11. I do not have a Pro version of VC11, but the Express > version works fine as well. > > The hard part is to find the appriopate dependent libraries. > http://windows.php.net/downloads/php-sdk/deps-5.6-vc11-x86.7z could give > you a jump start, but if you want to build PECL extensions with dependent > libraries you are on your own > > I build PHP myself for every 5.3/4/5/6 release. See > http://www.apachelounge.com/viewtopic.php?t=6359 > > > My PHP 5.6 nts builds contain contains 105 extensions. Only 44 of them > compile for PHP7. There still is a long way to go for all extension > maintainers! > thanks for your help testing PHP7. About > you a jump start, but if you want to build PECL extensions with dependent > libraries you are on your own > that's not true. Any PECL extensions being released and Windows supported do fetch their deps from http://windows.php.net/downloads/pecl/deps/ Also I hardly beleave any of 44 extensions building with PHP7 would be fully worky (well, maybe except http which was recently ported). Regarding the builds point - there are builds being done on almost every commit available here for master http://windows.php.net/downloads/snaps/master/ as well as for the other branches of interest. Thanks. anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Constant-Time Encoding Functions
Hi Scott, On Fri, Jan 23, 2015 at 12:21 AM, Scott Arciszewski wrote: > I've squashed and rebased my pull request that adds a cache-timing-safe > bin2hex implementation (named ts_bin2hex) to PHP. > > https://github.com/php/php-src/pull/909 > > Before I put more effort into the inverse operation (which, from what I can > tell, is already constant-time), does anyone have a better naming > convention suggestion? > First of all, I'm +1 for having dedicated API for these functions. i.e. Not an option for existing functions. I would rather postfix 'ts'. e.g. bin2hex_ts The reason why I prefer postfix is PHP functions are named like 'module name' _ 'function name' ts_*() seems like module function. Furthermore, should a similar effort be expended for base64 > encoding/decoding functions? > base64 is used to encode binary to text commonly. If it can be timing safe, it would be great! Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
[PHP-DEV] Deprecating all INI set/get functions and use ini_set/get()
Hi all, I would like to propose INI set/get function deprecation, raise E_DEPRECATED, and make PHP_INI_MH() use the CODING_STANDARDS. For example, session module has following INI set/get functions - http://php.net/manual/en/function.session-save-path.php - http://php.net/manual/en/function.session-module-name.php - http://php.net/manual/en/function.session-cache-expire.php - http://php.net/manual/en/function.session-cache-limiter.php - http://php.net/manual/en/function.session-name.php There are 5 PHP functions for session module alone. Some of them include runtime check, but these checks can be done with PHP_INI_MH() by using state parameter. In fact, runtime check should be done in PHP_INI_MH() to avoid bugs. Use of ini_set/get() has following pros and cons Pros - Less API, hence simpler API. - Modules will be less buggy. i.e. PHP_INI_MH() must handle "state" properly, but it tends to be forgotten, 3rd party modules especially. - Consistent coding style/API across modules, both internal and script. - Reduced documentations. INI descriptions are only in INI section. - Less documentations, hence less documentation bugs. - Better documentation. All user needs to know will be in INI section. - Awareness of INI setting use. Users are better to know they are using INI. i.e. All INI values has the same limitations, INI_SYSTEM/INI_PERDIR/INI_USER, stage limitations if any. - (Please point it out more advantages) Cons - Existing code modifications. (It's E_DEPRECATED. User may ignore.) - (Please point it out more disadvantages) Comments are appreciated. Regards, P.S. Enum for PHP_INI_MH() "stage" parameter type is better in PHP7. IMO. -- Yasuo Ohgaki yohg...@ohgaki.net
[PHP-DEV] Gifts and Handicrafts
Hello! We are Prosperity Arts & Crafts Co., Limited in China. We supply Crafts & Gifts with high quality and competitive price. Home & Garden Decors Holiday Gifts & Ornaments Religious Items Kitchen Accessories DIY & Promotional items Pls visit our website at www . ProsperityArtsandCrafts . com or www . prosperity-crafts . com for more information. We'd like to know more about your requirements and send you our quotation for review. Contact us if you are interesting! Best regards, Phillip (Export Manager) Prosperity Art & Craft Co., Limited Room 1803, No. 23 Kangcheng 1st Lane, Jimei, Xiamen, 361022 P.R.C Tel: 0086-592-6106212 Fax: 0086-592-6106312 E-mail: info (at) prosperity-crafts . com Skype: Prosperity-crafts Note: Our apology for the inconvenience caused if you do not like our this promotion e-mail. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
Hi all,
On Tue, Nov 4, 2014 at 5:50 AM, Stas Malyshev
wrote:
> > Again, an unfair comparison. Hack isn’t intended to be a completely
>
> I'm not sure what you refer to by "fair". Hack is not "intended", but IS
> a separate language - just read the manual and you will see, it is a new
> language which borrows some syntax from PHP. Just read their own site:
>
> Hack is a programming language for HHVM that interoperates seamlessly
> with PHP.
>
> I completely agree with this statement - Hack is a programming language
> that is different from PHP but built in a way to interoperate with it.
I agree with Stas also.
We may have both for compatibility and consistency. Hack may adopt later if
they want.
e.g.
Both
class Bar { public Foo $var; function( Foo $var); }
and
class Bar { public $var : Foo; function($var : Foo); }
may be accepted under PHP. Not many people care about a little compile time
overhead today.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] Gifts and Handicrafts
On 25/01/2015 01:11, Prosperity Crafts wrote: > spam deleted Do you use php in your development projects and have you got any questions or suggestions for php development? If the answer is no then you are clearly in the wrong newsgroups. Good bye.
Re: [PHP-DEV] Removing base class from session handler
Hi, On Sat, Jan 24, 2015 at 7:05 PM, Yasuo Ohgaki wrote: > Hi Andrey, > > On Sat, Jan 24, 2015 at 6:34 PM, Andrey Andreev wrote: >> >> > Let's keep SessionHandler class. However, >> > PHP_FUNCTION(session_set_save_handler) >> > should be cleaned up to verify implemented/extended interface/class. >> > It's >> > BC. >> > Do you have opinion for this? >> >> php > session_set_save_handler(new stdclass); >> PHP Warning: session_set_save_handler() expects parameter 1 to be >> SessionHandlerInterface, object given in php shell code on line 1 > > > As I pasted code in this thread, current code does not check if supplied > object > has valid class/interface, but it checks methods implemented. SdtClass does > not > have them obviously, therefore it raises error. > > It's a legacy code when PHP didn't have proper OOP support. This is the code > that I'm willing to remove/change. If I understand correctly, you're suggesting the removal of the old-style session_set_save_handler() calls where each function is passed as a separate argument? That could be a quite significant BC break. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Removing base class from session handler
Hi again, On Sat, Jan 24, 2015 at 7:48 PM, Yasuo Ohgaki wrote: > Hi Andrey, > > On Sat, Jan 24, 2015 at 6:34 PM, Andrey Andreev wrote: >> >> > This is because session module lacks user defined serializer. Save >> > handler >> > handles session data storage. Serialize handler handles how data is >> > converted/represented. IMHO. >> > >> >> That's not the only use case. >> >> Some time ago I proposed a session.match_ip feature and argued that if >> I wanted to implement it in userland code, I'd have to implement the >> *whole* session handler from scratch. An example using the >> SessionHandler class proved me wrong in that regard. > > > For me, IP address matching check does not belong to save handler. > I would implement it in other place. > > What's the reason why you need to implement IP address matching in > save handler? To prevent session fixation? Doesn't matter, I was just giving you an example. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Scalar Type Hints
Hi everyone, Just a few small updates. I’ve made a small change to this RFC. Instead of the strict mode syntax being declare(strict_typehints=TRUE), it’s now declare(strict_types=1) instead. This makes it a bit quicker to type - important given you’d need to type it a lot - without sacrificing much readability. It also avoids using the words “type hint”, which I understand are contentious to some people. The patch now includes a more extensive set of tests: https://github.com/TazeTSchnitzel/php-src/tree/scalar_type_hints_2_strict_mode/Zend/tests/typehints/ The pull request is also now green on Travis (aside from two failures on the debug build - but they also fail in master). Levi’s Return Types RFC has now passed, so now the RFC needs to cover that. The RFC currently doesn’t discuss return types, save for a paragraph in the Future Scope section. When the return types patch is merged, I’ll update the scalars patch, and then update the RFC. A point of contention here is whether or not return types should always be strict, or whether they should also obey the strict/weak modes. I’m not entirely sure on that one, that specific item may end up going to a vote. That said, I do lean towards always strict, given you can usually ensure your return type’s correct. Thanks. -- Andrea Faulds http://ajf.me/ PS: It’s rumoured that a certain other female internals developer may have endorsed this RFC at a certain recent PHP conference. That’s good to hear! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Scalar Type Hints
Hi! > going to a vote. That said, I do lean towards always strict, given > you can usually ensure your return type’s correct. Wait, so we would have two modes, strict and non-strict, but also in non-strict mode, return types still will be strict? Yay, consistency! -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Scalar Type Hints
Hey Stas, > On 25 Jan 2015, at 04:14, Stanislav Malyshev wrote: > > Hi! > >> going to a vote. That said, I do lean towards always strict, given >> you can usually ensure your return type’s correct. > > Wait, so we would have two modes, strict and non-strict, but also in > non-strict mode, return types still will be strict? Yay, consistency! Yes, it would have that inconsistency, so there’s also the other possibility of being weak for return types in weak mode. Thing is, I haven’t seen (so far) anyone who seems to think return types should be converted. We don’t do this for internal functions (to be fair, there’s no need, C is statically-typed). Them being strict would follow the robustness principle, too: “be conservative in what you send, be liberal in what you accept”. On the other hand, it may not be terribly fitting with “PHP’s weakly-typed nature”. It’s hard to say. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
Hi,
> De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
>
> > I would like to propose that namespaces, functions, and classes become
> > case-sensitive (constants are already case-sensitive). Actually, I never
> > understood why they are case-insensitive. Even if the performance gain is
> > negligible, I think it could be the right time to question this.
> >
>
> I'm writing this mail without reading current zend code.
>
> Anyway, is it feasible to raise E_DEPRECATE without much performance
> penalty?
> For example,
>
> if (!strcmp(name, name_to_be_searched)) {
> do_something;
> } else if (!strcasecmp(name, name_to_be_searched) {
> rase_error;
> do_something;
> }
>
> Duplicated codes may be removed by macro. strcasecmp() checks may be
> removed
> 10 years later or more.
Unfortunately, raising an E_DEPRECATED on case-sensitive mismatch is a huge
work, as case-insensitivity appears in a lot of locations throughout the core.
And the macro approach is not possible.
Actually, case insensitivity goes well beyond class and function names: it also
includes namespaces, scope resolution operators (self, parent, static), class
magic methods, method names (properties are already case-sensitive), language
keywords, and some stream wrapper protocols (like file and zlib). All these
case insensitive comparisons are done in a variety of ways, at various
locations in the code. Most store and compare names converted to lowercase
(which implies a problem with Unicode as correct conversion with an unknown
character set is impossible), some use strncasecmp...
So, making the code case-sensitive would be a important work, but raising an
E_DEPRECATED message would require much more work. Unfortunately, you can
forget the idea of a macro that can be removed anytime in the future :)
Cheers
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Types on the right or on the left
> De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki > > > Mixing both, having some types on the left and others on the right, > > seems like another inconsistency in the language > > > design to me. > > > > These inconsistencies exist for two reasons: > > > > - Opposition to doing it the other way > > - Hack already doing it this way > > > > I don’t think `function void foo();` will happen, since that’s been > > previously rejected as it breaks gripping for “function foo”. Similarly, I > > don’t think `public $foo: Foo;` will happen, given Hack does it as `public > > Foo $foo;`. > > I agree with Andrea. > > There are people who dislike syntax, and/or thinks PHP missing check(i.e. > array format, etc). These people should request DbC. > DbC is more powerful than simple type checks and have no performance > penalty in production. (I'm not saying type hinting is > useless. I'll use it where it is appropriate, too.) +1. I have been reading these discussions about type hinting for years. Every time, people try to bring strong typing through various artefacts, because they don't understand the benefits of loose typing. Some years ago, their model was java, today, it is a combination of java and Hack. Unfortunately, the RFC on return types was approved. It was just a question of time, with all these people pushing during years. Half-backed, short-term solution, attractive at first sight but bringing more problems than it solves... It will probably have catastrophic implications on the 'REAL' solutions someone may propose in the future. >From the beginning, I think that DbC based on phpdoc annotations, with >controlled type conversion (which ones are valid, which ones are not) and >switched on/off by an INI parameter would be the best solution to provide the >restrictions and checks developers are asking for. Unfortunately, half-backed, >short-term solutions, like return types and type hinting, will make proposing >such a solution harder, as we will need to keep BC. It will even be an >argument to fight against a better solution. Cheers François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Removing base class from session handler
Hi Andrey, On Sun, Jan 25, 2015 at 11:53 AM, Andrey Andreev wrote: > If I understand correctly, you're suggesting the removal of the > old-style session_set_save_handler() calls where each function is > passed as a separate argument? > > That could be a quite significant BC break. > No. Class/Interface support is there. I'm just going to remove legacy code and replace it to usual code. i.e. Check object against class/interface name, not methods in there. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Removing base class from session handler
Hi Andrey,
On Sun, Jan 25, 2015 at 11:54 AM, Andrey Andreev wrote:
> To prevent session fixation?
>
> Doesn't matter, I was just giving you an example.
>
If app may assume that clients have constant IP, then IP may be used to
prevent
stolen sessions. Unfortunately, we live in mobile world, so this solution
may be
used under very limited environments. Using save handler for this purpose
may
trigger error from unknow file/line.
I would advise to write following code somewhere in usual locations.
if ($_SESSION['last_ip'] !== $_SERVER['REMOTE_ADDR']) {
log_security_breach();
session_regenerate_id();
session_unset();
die_or_trigger_error_if_it_is_needed();
}
Anyway, if anyone would like to implement something fancy in save handlers,
beware that it may result in consequences that you may not be willing to
have.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
[PHP-DEV] Warnings in zend_alloc.h
Nut sure whether this is an issue or not but I see it a lot while
compiling master:
Zend/zend_alloc.h:57:236: warning: unknown attribute 'alloc_size'
ignored [-Wunknown-attributes]
__attribute__ ((visibility("default"))) void* _emalloc(size_t size,
const char *__zend_filename, const uint __zend_lineno,
const char *__zend_orig_filename, const uint __zend_orig_lineno)
__attribute__ ((__malloc__)) __attribute__ ((alloc_size(1)));
Zend/zend_alloc.h:61:250: warning: unknown attribute 'alloc_size'
ignored [-Wunknown-attributes]
__attribute__ ((visibility("default"))) void* _ecalloc(size_t nmemb,
size_t size , const char *__zend_filename, const uint __zend_lineno,
const char *__zend_orig_filename, const uint __zend_orig_lineno)
__attribute__ ((__malloc__)) __attribute__ ((alloc_size(1,2)));
Zend/zend_alloc.h:62:238: warning: unknown attribute 'alloc_size'
ignored [-Wunknown-attributes]
__attribute__ ((visibility("default"))) void* _erealloc(void *ptr,
size_t size, int allow_failure , const char *__zend_filename,
const uint __zend_lineno , const char *__zend_orig_filename,
const uint __zend_orig_lineno) __attribute__ ((alloc_size(2)));
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
