Re: [PHP-DEV] new json, push generated file?
On Tue, February 10, 2015 14:15, Jakub Zelenka wrote: Hi Anatol, On Tue, Feb 10, 2015 at 12:24 PM, Anatol Belski anatol@belski.net wrote: It's actually so that there is a range of tool versions supported. That means any version within the range should be valid for use. If another range of versions is defined, so it's obviously to follow it. It's good to make thoughts about the new features, but that'll be probably require updating the guidelines and changing the valid versions range. First of all it's great that you are adding the the type and cross platform fixes into json. I understand why you needed to regenerate the file. Well, thank you for your work ) As you say there is a supported range. The problem is that the range is too high which is very limiting for adding new features at the moment. What I don't want to do is to force all users compile the new tool version from source because distros are still outdated . There also is no need to require the new version for the whole PHP if it's needed just for json generation. IMHO that's exactly what is going to happen - users willing to regenerate the parser will have to get eventually another re2c version if they don't have it. As for me - I've just compiled re2c 0.13.6 for windows. But in general - using different tools for different parts of the core were probably a mess. As I said in the PR. This change won't affect anyone who doesn't change json scanner and parser which is 99% of all users that build PHP. The 1% is probably just me so it's not really complicated IMHO... I would also like to add all of this to the json README (it's very outdated and I plan to update it anyway) and possibly other build doc if we have any. Yeah, so why don't just push file and have it done? ATM there might be some fixes needed, so regeneration required. Later on it's supposed to be a very rare case - just in case of bugs or new development. Btw also people who don't have a required re2c/bison/etc version for whatever reasons would still be able to compile, test or develop other parts. That's not actually completely true on linux. At least not on my platform. I can recreate this on my system when I do following: 1. install a different version of re2c then the one Zend/zend_language_scanner.c (e.g. 0.13.6) 2. git checkout master 3. ./configure ... make 4. checkout PHP-5.6 5. checkout master 6. make 7. git status ( it shows Zend/zend_language_scanner.c as regenerated using 0.13.6 ) The fact that I checked out the 5.6 [4] (it doesn't have to be just 5.6 but some other branch with more changes) and then back master [5] caused regeneration zend_language_scanner.c in [6]. The point is that as soon as you start changing branches often, it gets regenerated even if you don't change it. And then you need to have the required version because otherwise the build fails. I want to prevent that for json generated files. This would be especially visible for bison where the version differs more between users compare to re2c where the most users are on 0.13.5. That's exactly what the PR (config.m4 changes) does. As the versions in the range are interchangeable, it gives much more flexibility. Right now, if you open some release tarball - it is possible you see files generated with different bison/re2c versions because it doesn't matter much. Maybe it'd be worth it to move one step after another, see what features can be implemented and how do they improve? Maybe they'll be so crucial to even make a special case that one can say - yeah, don't care about flexibility? Not that one would restrict something without having the bare reason in the hand. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotated PHP 5-7 extension diff
Lester Caine in php.internals (Mon, 09 Feb 2015 21:39:16 +): On 09/02/15 15:03, Jan Ehrhardt wrote: Despite the extensive list of changes, imagick does not compile anymore with the current PHP7 git head (Win32 VC11). Jan ... try the latest code from Dan ... Just got both php7 and php5.6.5 running including a populated phpinfo on each so I'm moving on ... It was a VC11 specific error. I trimmed a lot of errors down to 1 pull request: https://github.com/mkoppanen/imagick/pull/74 Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] zend_get_parameters_ex rework
in interbase/ibase_blobs.c
zval *blob_arg, *string_arg;
ibase_blob *ib_blob;
RESET_ERRMSG;
if (ZEND_NUM_ARGS() != 2 || zend_get_parameters_ex(2, blob_arg,
string_arg) == FAILURE) {
WRONG_PARAM_COUNT;
}
ZEND_FETCH_RESOURCE(ib_blob, ibase_blob *, blob_arg, -1, Interbase
blob, le_blob);
I've got that if changes to
if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, rr,
blob_arg, string_arg)) {
return;
}
But I suspect I need to change the *string_arg to a character string so
'rc' and add a string_len field. At least that is what I think I'm
seeing from the samples I have found.
--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hey: On Wed, Feb 11, 2015 at 11:36 AM, Xinchen Hui larue...@php.net wrote: Hey: On Fri, Feb 6, 2015 at 4:14 AM, Andrea Faulds a...@ajf.me wrote: Good evening, At long last, I’m going to put the RFC to a vote. It’s been long enough - I don’t think there needs to be, or will be, much further discussion. I’d like to make sure that everyone voting understands the RFC fully. Please read the RFC in full: the details are important. And if anyone has any questions or uncertainties, please ask them before voting. I am very happy to answer them. I would urge everyone who wants type hints to vote for this RFC. It is not a perfect solution, but there can be no perfect solution to this issue. However, I think it is better than most of the alternatives suggested thus far - see the rationale section, and previous discussions. Crucially, this RFC would keep PHP a weakly-typed language, and not force either strict typing, nor weak typing, on anyone who does not want it. It would allow the addition of type hints to existing codebases. It would not create a situation where userland functions are strict yet internal functions are not, because the strict mode affects both. I’ve tested the implementation myself on my own code, and it worked well, providing benefits other proposals would not have given (see my previous post about my experiences). Voting starts today (2015-02-05) and ends in two weeks’ time (2015-02-19). In addition to the vote on the main RFC, there is also a vote on the type aliases issue, and a vote to reserve the type names for future RFCs’ sake if this RFC fails. The RFC can be found here, and it contains a voting widget: https://wiki.php.net/rfc/scalar_type_hints Thank you for your time. Actually, I was surprised by the progress of voting now... Seems never have so many users to vote... and bulk of active core developers are vote against on it. As a PHP user, I actually don't care about scalar type hinting much.. but I am strongly objecting declare thing... image of, one line setting care make a project doesn't work... image of, a larger project, some devers user strict_type, some for safe doesn't use.. then they have to add declare to every files's head... it's a nightmare I , here, acking you please reconsidering your vote... ?php include_one lib/.php // it use strict type declare(strict_types=0); //damned , restore it. $a = new B; // autoload, target file use strict type, declare(strict_types = 0); //damned, restore it. ? am I wrong?! thanks thanks -- Andrea Faulds http://ajf.me/ -- 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] [RFC][DISCUSSION] Script only includes
Hi Pierre, On Tue, Feb 10, 2015 at 6:19 PM, Pierre Joye pierre@gmail.com wrote: On Tue, Feb 10, 2015 at 7:52 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, Some of you are tired with this topic, but please take a look the RFC [RFC] Script only includes - this is 3rd version. https://wiki.php.net/rfc/script_only_include Please let me know what you like or dislike. I said before but this RFC tries to solve a problem using yet another security feature in the engine while the OS and the webserver provides way better solutions without adding a possible new pandora box from a security point of view. Many extensions may have to deal with it too. I can only create an empty for all upcoming CVEs about xyz not following script_embed. Alone that tells me that we should not try again to make php more secure using such features. I suppose script_embed ini setting is siimilar to open_basedir but for exec only, which would prevent any script to be exec'ed (require, include, via handlers but works for fopenco) while open_basedir would remain the same (aka also for fopenco). Now, that does prevent one to shoot himself in the foot, eval(file_get_contents());. Yes, this is stupid thing to do, just a bit more stupid that require someuploadedfile; but not much more. Trying to implement security measures to prevent people to exec codes from an unknown file is a bad idea. They will do it one way or another. And if anyone application still do include/require(random/uploaded files), then they surely have many other problems to solve but none of them is really a php problem I think I understood your point of view perfectly and thank you for your comment. We just have different point of views. This is the last serious PHP design issue for me. I've been thinking how it could be resolved for a long time and this is the best. I hope you agree to remove risks of script inclusions. Let's be nicer to new PHP users! Don't let them down by embedded mode include()/require()! Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC][DISCUSSION] Script only includes
Yasuo Ohgaki wrote: We have been tried to educate users already and introduced some mitigations e.g. allow_url_include, open_basedir. However, enough time is passed to prove that wasn't enough, isn't it? PHP (many and these are _only_ few of them in the wild) http://www.exploit-db.com/search/?action=searchfilter_page=1filter_description=PHPfilter_author=filter_platform=0filter_type=0filter_lang_id=0filter_exploit_text=inclusionfilter_port=0filter_osvdb=filter_cve= I've arbitrarily checked the top most entry (u5CMS), and the LFI was caused by `echo file_get_contents($_GET['...'])` basically. There was neither include|require(_once) involved, nor move_uploaded_file(). From my, admittedly very limited, experience, this is a rather common source of LFI vulnerabilities in PHP applications. I'm afraid that educating developers is the only way to avoid this kind of vulnerability. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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] [VOTE] Scalar Type Hints
Hey: On Fri, Feb 6, 2015 at 4:14 AM, Andrea Faulds a...@ajf.me wrote: Good evening, At long last, I’m going to put the RFC to a vote. It’s been long enough - I don’t think there needs to be, or will be, much further discussion. I’d like to make sure that everyone voting understands the RFC fully. Please read the RFC in full: the details are important. And if anyone has any questions or uncertainties, please ask them before voting. I am very happy to answer them. I would urge everyone who wants type hints to vote for this RFC. It is not a perfect solution, but there can be no perfect solution to this issue. However, I think it is better than most of the alternatives suggested thus far - see the rationale section, and previous discussions. Crucially, this RFC would keep PHP a weakly-typed language, and not force either strict typing, nor weak typing, on anyone who does not want it. It would allow the addition of type hints to existing codebases. It would not create a situation where userland functions are strict yet internal functions are not, because the strict mode affects both. I’ve tested the implementation myself on my own code, and it worked well, providing benefits other proposals would not have given (see my previous post about my experiences). Voting starts today (2015-02-05) and ends in two weeks’ time (2015-02-19). In addition to the vote on the main RFC, there is also a vote on the type aliases issue, and a vote to reserve the type names for future RFCs’ sake if this RFC fails. The RFC can be found here, and it contains a voting widget: https://wiki.php.net/rfc/scalar_type_hints Thank you for your time. Actually, I was surprised by the progress of voting now... Seems never have so many users to vote... and bulk of active core developers are vote against on it. As a PHP user, I actually don't care about scalar type hinting much.. but I am strongly objecting declare thing... image of, one line setting care make a project doesn't work... image of, a larger project, some devers user strict_type, some for safe doesn't use.. then they have to add declare to every files's head... it's a nightmare I , here, acking you please reconsidering your vote... thanks -- Andrea Faulds http://ajf.me/ -- 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] Design by Contract
Hi Dmitry and Joe,
On Wed, Feb 11, 2015 at 6:29 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov dmi...@zend.com wrote:
You are welcome to edit https://wiki.php.net/rfc/dbc2
It looks like we have similar views, so just make it better in a way you
think.
Looks good to me. It's much better than original. Thank you folks.
We have related issue like how internal module incorporate with DbC.
However
these could be future issues.
I would like explain one of the reason why I bring up internal module.
http://php.net/manual/en/class.sessionhandlerinterface.php
Session has internal interface definitions like
SessionHandlerInterface {
/* Methods */
abstract public bool close ( void )
abstract public bool destroy ( string $session_id )
abstract public bool gc ( string $maxlifetime )
abstract public bool open ( string $save_path , string $name )
abstract public string read ( string $session_id )
abstract public bool write ( string $session_id , string $session_data )
}
but it should be like follows to be precise.
SessionHandlerInterface {
/* Methods */
abstract public bool close ( void )
return($ret, is_bool($ret));
abstract public bool destroy ( string $session_id )
require(strlen($session_id) 0)
return($ret, is_bool($ret));
abstract public bool gc ( string $maxlifetime )
require($maxlifetime = 0)
return($ret, is_int($ret) $ret = -1);
abstract public bool open ( string $save_path , string $name )
require(is_string($save_path))
require(is_string($name));
return($ret, is_bool($ret));
abstract public string read ( string $session_id )
require(strlen($session_id) 0)
return($ret, is_bool($ret) || is_string($ret));
abstract public bool write ( string $session_id , string $session_data )
require(is_string($session_id) strlen($session_id) 0)
require(is_string($session_data))
return($ret, is_bool($ret));
}
This definition is more user friendly. There were too many user save
handlers
that do not return proper values because of current interface limitation.
Scalar type and return type hint helps, but it does not cover
return($ret, is_int($ret) $ret = -1);
for example.
If you think this is easy to implement and should be in the RFC, I would
appreciated it
and use it to raise assertion errors just like user class/interface.
BTW, these restrictions are coded as error in current session module and
should
be checked by the module always. It's not mandatory for the RFC, but just a
missing piece.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] [RFC][DISCUSSION] Script only includes
Hi Matteo, On Tue, Feb 10, 2015 at 5:22 PM, Matteo Beccati p...@beccati.com wrote: On 10/02/2015 01:52, Yasuo Ohgaki wrote: Some of you are tired with this topic, but please take a look the RFC [RFC] Script only includes - this is 3rd version. https://wiki.php.net/rfc/script_only_include Please let me know what you like or dislike. I understand you goal, but ini settings are *bad*. We need less of them, not more. Developing applications or libraries that are resilient to all possible variants in the ini settings is painful. It's a waste of time for both users and developers trying to provide support. I proposed script()/script_once() at first. Considering new names that might break existing apps, I choose INI. The INI may be removed in the future, if include/require has an option. e.g. require string $filename [, bool $embed_mode_flag]; Would you like me to include this change proposal in the RFC? Even if we have embed_mode_flag, we are better to have the INI option for a while for smooth migration. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC][DISCUSSION] Script only includes
Hi Christoph, On Wed, Feb 11, 2015 at 10:45 AM, Christoph Becker cmbecke...@gmx.de wrote: We have been tried to educate users already and introduced some mitigations e.g. allow_url_include, open_basedir. However, enough time is passed to prove that wasn't enough, isn't it? PHP (many and these are _only_ few of them in the wild) http://www.exploit-db.com/search/?action=searchfilter_page=1filter_description=PHPfilter_author=filter_platform=0filter_type=0filter_lang_id=0filter_exploit_text=inclusionfilter_port=0filter_osvdb=filter_cve= I've arbitrarily checked the top most entry (u5CMS), and the LFI was caused by `echo file_get_contents($_GET['...'])` basically. There was neither include|require(_once) involved, nor move_uploaded_file(). From my, admittedly very limited, experience, this is a rather common source of LFI vulnerabilities in PHP applications. I'm afraid that educating developers is the only way to avoid this kind of vulnerability. It's not my point. These are only surface of them as you can see it contains only open source project's vulnerabilities. Script inclusion is common by evidence, unlike others. This is what I'm trying to change. Are PHP programmers are worse than others? I don't think they are. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hey: On Wed, Feb 11, 2015 at 11:45 AM, Xinchen Hui larue...@php.net wrote: Hey: On Wed, Feb 11, 2015 at 11:36 AM, Xinchen Hui larue...@php.net wrote: Hey: On Fri, Feb 6, 2015 at 4:14 AM, Andrea Faulds a...@ajf.me wrote: Good evening, At long last, I’m going to put the RFC to a vote. It’s been long enough - I don’t think there needs to be, or will be, much further discussion. I’d like to make sure that everyone voting understands the RFC fully. Please read the RFC in full: the details are important. And if anyone has any questions or uncertainties, please ask them before voting. I am very happy to answer them. I would urge everyone who wants type hints to vote for this RFC. It is not a perfect solution, but there can be no perfect solution to this issue. However, I think it is better than most of the alternatives suggested thus far - see the rationale section, and previous discussions. Crucially, this RFC would keep PHP a weakly-typed language, and not force either strict typing, nor weak typing, on anyone who does not want it. It would allow the addition of type hints to existing codebases. It would not create a situation where userland functions are strict yet internal functions are not, because the strict mode affects both. I’ve tested the implementation myself on my own code, and it worked well, providing benefits other proposals would not have given (see my previous post about my experiences). Voting starts today (2015-02-05) and ends in two weeks’ time (2015-02-19). In addition to the vote on the main RFC, there is also a vote on the type aliases issue, and a vote to reserve the type names for future RFCs’ sake if this RFC fails. The RFC can be found here, and it contains a voting widget: https://wiki.php.net/rfc/scalar_type_hints Thank you for your time. Actually, I was surprised by the progress of voting now... Seems never have so many users to vote... and bulk of active core developers are vote against on it. As a PHP user, I actually don't care about scalar type hinting much.. but I am strongly objecting declare thing... image of, one line setting care make a project doesn't work... image of, a larger project, some devers user strict_type, some for safe doesn't use.. then they have to add declare to every files's head... it's a nightmare I , here, acking you please reconsidering your vote... ?php include_one lib/.php // it use strict type declare(strict_types=0); //damned , restore it. $a = new B; // autoload, target file use strict type, declare(strict_types = 0); //damned, restore it. ? am I wrong?! seems I am wrong with this, it's a false alarm... it can restore automatically. ignore me.. : thanks thanks thanks -- Andrea Faulds http://ajf.me/ -- 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/ -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http
On 06/02/15 17:44, Daniel Lowrey wrote: I’ve rewritten the RFC for pecl_http and hopefully addressed most of the things mentioned previously. I you still find anything lacking, please let me know, so I can expand the RFC accordingly. And of course, everything else is up for discussion. I may not have been clear before, but just to be sure ... I would really like to see the pecl/http RFC broken up into multiple voting options instead of one giant yes or no as per my previously mentioned concerns: 1. There is a lot of *really* useful functionality in pecl/http that IMO should be bundled with the standard PHP distribution. 2. There is some functionality here that isn't HTTP-specific and should exist in other extensions. 3. There is some functionality here that IMO belongs in pecl/ and not ext/ 4. There is some functionality here that will likely upset some people because it's subjective I also want to reiterate my feeling that PHP *does not* need to bundle yet another HTTP client -- especially one that brings other pecl dependencies with it. There's just no reason for doing this (other than API waffling). Performance is not a valid reason (we have ext/curl, which is fine if you want something that's compiled). Also, when you consider that HTTP resource traversal is more than adequately handled in userland already this addition just doesn't make a ton of sense to me. Let's bring the things that actually benefit from being compiled into the standard distribution; the rest should stay in pecl. If you doubt that this is a solved problem in userland consider the performance of my own 100% userland HTTP client demonstrated here without the use of curl or any other extensions: https://gist.github.com/rdlowrey/54171625334670ccb9f5 If this proposal is all or nothing then I have to vote no ... and it would be a shame to miss out on the beneficial portions of pecl/http :( While I think it's not a particularly good reason to vote no, it may very well be a valid one; but I'm not conviced that splitting it up makes the situation any better. I really don't want to compete with the client you've written, but it seems this is the only thing you oppose to? -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Design by Contract
Hi Alexander, De : Alexander Lisachenko [mailto:lisachenko...@gmail.com] This is built on top of reflection+annotation+parser extension. Why not to implement this for PHP? From my point of view, this is just an additional feature, that can be used by limited number of developers. I like the idea. IMO, DbC directives should be defined outside of function body. I proposed doc blocks because it exists and is already parsed but a generic syntax for annotations along with a full API to interact with extensions would be much better. Most important : if we define that, for example, everything outside of a class/function enclosed in [], is an annotation, it is easy to enhance PHP 5 to ignore such syntax, without having to backport the whole feature. So, people can start using it for PHP 7 and keep the possibility to run their code under PHP 5. That's something that would be much harder with the current dbc2 proposal. I will modify my RFC (https://wiki.php.net/rfc/dbc) to open it to any sort of annotations. Do you think you have enough time to write something in due time ? Ask for help if you need. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http
Caching connections within the same request and reusing them is not spooky, but caching them long term, across requests, across security domains, for extended time - is spooky. This is exactly what reverse proxies like Nginx and the Akamai CDN do: reuse the connection between the proxy and origin even after the browser endpoint has disconnected from the proxy. Like Mike said, it isn't spooky, since the reuse of an HTTP persistent connection makes no claim about HTTP state. Heck, Firefox could take over Chrome's HTTP connections and it would still be to-spec, regardless of whether they shared credentials. Of course it is incumbent on the remote server to keep things stateless above the TCP level, but if it can't do that it shouldn't advertise persistent connections. -- Sandy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http
On 04/02/15 18:57, Pavel Kouřil wrote: On Wed, Feb 4, 2015 at 6:17 PM, Andrea Faulds a...@ajf.me wrote: Hey, On 4 Feb 2015, at 17:10, Crypto Compress cryptocompr...@googlemail.com wrote: I would go with Http\ Why not the reserved Php\Http\? This sounds good to me. php\ is already reserved, and it’s similar to the common community convention of vendor\packagename. (e.g. ajf\escapes.) Would work well with Composer and Packagist too, as it could be a virtual php/http package (Packagist naming convention). Also, I’d like to say I’d prefer php\HTTP or php\http over php\Http. Capitalising an acronym doesn’t feel right to me, perhaps because case is usually significant, Following the Casing Rules Used by Titles. Of php\HTTP and php\http, php\http is probably better since the case matches that of php\. It could also be PHP\HTTP, I guess, but lowercase is somehow more appealing to me. Thoughts? Personally, From my userland point of view, I would expect it to follow the same capitalization rules as classes are supposed to follow, making it Php\Http. So, should I make a separate vote out of this? * http * HTTP * Http * php\http * PHP\HTTP * Php\Http * PHttP The last one was a joke actually, well, lame, I know. Can we rule any of these out definitely? As already mentioned, the case is not as relevant because we don't depend on an autoloader... -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Annotated PHP 5-7 extension diff
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
Re: [PHP-DEV] Design by Contract
Hi Yasuo, Le Tue, 10 Feb 2015 07:25:00 +0100, Yasuo Ohgaki yohg...@ohgaki.net a écrit: Updated wiki page. https://wiki.php.net/rfc/dbc2 While I agree this RFC is going in the right direction, I don't like the use of require and return. They are already used for something completely different, I think it will make the code more difficult to understand (for beginners) and parse (for external programs). IDE will have some difficulties too. I've discussed about it with some PHP developers who work with me, and they all agree. If it was me, I would use pre and post, in and out or requires and ensures. I understand that creating more keywords isn't something pleasant, but it would make the code more readable and logical. Regards, Benoit. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design by Contract
completely agree. contracts must be permanent.
Thanks. Dmitry.
On Tue, Feb 10, 2015 at 10:40 AM, Joe Watkins pthre...@pthreads.org wrote:
Example code never works, I can just say that's a bad abstraction,
vertebrate and invertebrate are distinct and abstraction should reflect
that.
Why should we provide a way to change contracts is the question ?
It doesn't seem to make sense to do that, a derived class should be able
to define additional contracts, but not change the contracts of it's parent.
Cheers
Joe
On Tue, Feb 10, 2015 at 7:36 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Joe,
On Tue, Feb 10, 2015 at 4:31 PM, Joe Watkins pthre...@pthreads.org
wrote:
Actually I'm not sure it's at all sane to try to override contracts, I'd
actually avoid that completely, so no need to name contracts and no need
for magic __invariant.
For example,
class Animal {
protected $legs;
require($legs = 0);
}
class Snake extends Animal {
// Snake is fine, no leg
}
class Human extends Animal {
// 2 legs. $this-leg === 2
}
Overriding makes sense for many cases.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] Design by Contract
I'm happy to clean up the RFC after Dmitry's changes are merged.
Happy to author some of the content if Yasuo is busy or wants help ?
Cheers
Joe
On Tue, Feb 10, 2015 at 8:29 AM, Dmitry Stogov dmi...@zend.com wrote:
A bit updated version of RFC is attached.
As I removed more than added, I decided not to put it on wiki before
internal agreement.
Actually, I would also remove most part of introduction as well, to make
RFC more compact and clean.
I cnahged $ into $ret, because $ just won't work. Some better solution
is welcome.
The RFC misses contract inheritance rules. They must be defined separately
for preconditions, postconditions and invariants.
Yasuo, could you please check, how it's implemented in D and add missing
section.
We will need English correction after all.
Thanks. Dmitry.
On Tue, Feb 10, 2015 at 11:19 AM, Dmitry Stogov dmi...@zend.com wrote:
completely agree. contracts must be permanent.
Thanks. Dmitry.
On Tue, Feb 10, 2015 at 10:40 AM, Joe Watkins pthre...@pthreads.org
wrote:
Example code never works, I can just say that's a bad abstraction,
vertebrate and invertebrate are distinct and abstraction should reflect
that.
Why should we provide a way to change contracts is the question ?
It doesn't seem to make sense to do that, a derived class should be able
to define additional contracts, but not change the contracts of it's parent.
Cheers
Joe
On Tue, Feb 10, 2015 at 7:36 AM, Yasuo Ohgaki yohg...@ohgaki.net
wrote:
Hi Joe,
On Tue, Feb 10, 2015 at 4:31 PM, Joe Watkins pthre...@pthreads.org
wrote:
Actually I'm not sure it's at all sane to try to override contracts,
I'd actually avoid that completely, so no need to name contracts and no
need for magic __invariant.
For example,
class Animal {
protected $legs;
require($legs = 0);
}
class Snake extends Animal {
// Snake is fine, no leg
}
class Human extends Animal {
// 2 legs. $this-leg === 2
}
Overriding makes sense for many cases.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] [RFC][DISCUSSION] Script only includes
On 10.02.15 01:52, Yasuo Ohgaki wrote: Some of you are tired with this topic, but please take a look the RFC [RFC] Script only includes - this is 3rd version. https://wiki.php.net/rfc/script_only_include Please let me know what you like or dislike. How exactly does this detection work? move_uploaded_file() searches “start tag” token if it is located as the first token. What constitutes first token in this context? Would this be detected as a PHP file? -8 root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin bin:x:2:2:bin:/bin:/usr/sbin/nologin ?php phpinfo(); -8 thanks, - Markus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Script only includes
Hi Yasuo, On 10/02/2015 01:52, Yasuo Ohgaki wrote: Some of you are tired with this topic, but please take a look the RFC [RFC] Script only includes - this is 3rd version. https://wiki.php.net/rfc/script_only_include Please let me know what you like or dislike. I understand you goal, but ini settings are *bad*. We need less of them, not more. Developing applications or libraries that are resilient to all possible variants in the ini settings is painful. It's a waste of time for both users and developers trying to provide support. Cheers -- Matteo Beccati Development Consulting - http://www.beccati.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
FYI, the patch doesn't cause a performance regression. I built on and tested with IIS/Windows. Performance remains the same for Wordpress, Symfony and Joomla. Mediawiki actually increased slightly (5%), so performance is increase/decrease is not an issue here, the language and engine are. If you're interested, see: http://windows.php.net/downloads/snaps/ostc/pftt/perf/results-20150209-master_rcaf5521-scalar_type_hints_2_strict_mode-8436.html Regards -M On Mon, Feb 9, 2015 at 6:43 PM, Pierre Joye pierre@gmail.com wrote: On Feb 10, 2015 1:22 AM, Lars Strojny l...@strojny.net wrote: Hi Matteo, sorry for the late response. On 07 Feb 2015, at 12:46, Matteo Beccati p...@beccati.com wrote: Maybe it's just me, but I didn't quite understand the point you are making here. Are you saying that declares are more or less like ini settings? Yes, exactly that. The new declare()-statement will fundamentally change how the engine behaves and one will have two learn more or less two flavors of PHP. Even worse I am forced to use the PHP flavor the person picked who changed the declare() statement last. No. You are not. cu, Lars
Re: [PHP-DEV] Design by Contract
I think __RETURN__ is better than $ret. Dmitry. On Tue, Feb 10, 2015 at 12:43 PM, Patrick Schaaf p...@bof.de wrote: Am 10.02.2015 09:29 schrieb Dmitry Stogov dmi...@zend.com: I cnahged $ into $ret, because $ just won't work. Some better solution is welcome. Also think $ would be awful. Don't like $ret either. What about a magic constant __RETURN__ or __RESULT__? This would stand out very well when glancing at the expression, would fit in with naming of other magic constants, and might even be made to work in finally blocks, where the same need for access to the returned value exists. best regards Patrick
Re: [PHP-DEV] Design by Contract
$this-a = require( 100);
This is already valid-ish code ..
On Tue, Feb 10, 2015 at 9:56 AM, Robert Stoll p...@tutteli.ch wrote:
We could provide an Invariant class in order to support invariant cases at
least to a certain degree:
http://3v4l.org/vjBRG
Of course, that does not provide the same support as native invariants but
maybe better than nothing. At least we would have a consistent Invariant
class throughout the code bases.
We could go even further and provide some syntactic sugar in order that
one does not need to write new Invariant(...) as in line 28 -- for instance:
$this-a = require( 100);
which is short for
$this-a = new Invariant(function($value){return $value 100;}, '$this-a
100');
Cheers,
Robert
-Ursprüngliche Nachricht-
Von: Dmitry Stogov [mailto:dmi...@zend.com]
Gesendet: Dienstag, 10. Februar 2015 08:06
An: Joe Watkins
Cc: Yasuo Ohgaki; PHP Internals; Stanislav Malyshev
Betreff: Re: [PHP-DEV] Design by Contract
good point, but I think we can do nothing about that.
Anyway, it should be reflected in RFC.
Dmitry.
On Tue, Feb 10, 2015 at 9:59 AM, Joe Watkins pthre...@pthreads.org
wrote:
I'm not sure we can always enforce invariant contracts ...
Evaluating invariant expressions on entry and exit is not enough,
since a property can be changed without the use of a method.
Can or should, we do anything about that ?
This should also be covered in the RFC, I think.
Cheers
Joe
On Tue, Feb 10, 2015 at 6:49 AM, Dmitry Stogov dmi...@zend.com
wrote:
Hi,
can I make some minor correction?
Thanks. Dmitry.
On Tue, Feb 10, 2015 at 9:25 AM, Yasuo Ohgaki yohg...@ohgaki.net
wrote:
Hi Dmitry,
On Tue, Feb 10, 2015 at 1:43 PM, Dmitry Stogov dmi...@zend.com
wrote:
On Feb 9, 2015 11:20 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Dmitry and Joe,
On Mon, Feb 9, 2015 at 8:27 PM, Dmitry Stogov dmi...@zend.com
wrote:
yes. this may work.
probably better to put it after extends and implements.
Dmitry.
On Mon, Feb 9, 2015 at 2:19 PM, Joe Watkins
pthre...@pthreads.org
wrote:
Could this be described as a requirement of the class ?
class Mine
require(invariant-expr)
extends Something
implements Someface {
public function method($param) : return
require(input-expr),
return(output-expr) {
}
}
To avoid invariant keyword maybe.
This would work.
If users have adopted DbC in some way, 'invariant' may be used
already.
I see two issues.
Interface works, but most classes are class without interfaces.
Then
users have to repeat
require()/return() many times to check class state or have to use
interface for DbC.
In D classes may have invariant constraints. We may use require
keyword for it. The constraints ineritance rules and order of calls
to constrains must be the same s in D.
class Foo {
private $sum = 0;
require($this-sum = 0); // invariant constraint will be
called before and after every method
function add($n) {
$this-sum += $n;
}
}
OK. I'll update the RFC.
Since compiler does not know a method() is for DbC invariant, it
will
be compiled and exists
in production execution.
Use of interface:
- no additional keyword (pros)
- requires interface for DbC, most classes does not require
interface (cons)
- if interface is not used, user has to repeat invariant
conditions
over and over (cons)
- requires to define method that should not exist in production
(cons)
I didn't understand you idea.
Joe's idea was to use Interface for invariant condition grouping.
If we use your idea, issue is solved.
class Foo {
private $sum = 0;
require($this-sum = 0); // invariant constraint will be
called before and after every method
function add($n) {
$this-sum += $n;
}
}
Ok.
New keyword:
- does not require interface for efficient definition (pros).
- new keyword (cons)
It seems we are better to choose proper keyword for 'invariant'.
'invariant' is not common, so 'invariant'
may be good enough choice. Does anyone use 'invariant' as
function/method/class/constant names?
If there is better name, suggestion is appreciated.
On place closure call like javascript is not supported in PHP,
but
function works with assert.
?php
function foo() { return FALSE; }
assert(foo());
?
PHP Warning: assert(): Assertion failed in - on line 3
This wouldn't be changed for require()/return()/invariant()?
We need a switch to change development/production. I'll use
dbc=On/Off for now.
If you have any
Re: [PHP-DEV] [VOTE] Scalar Type Hints
On Tue, Feb 10, 2015 at 4:56 PM, Dmitry Stogov dmi...@zend.com wrote: If you measure performance impact using CPU performance counters (VTune, oprofile, perf) or even better CPU emulator (callgrind) you'll see slight degradation. It's also clear that it makes some degradation from code review. 1% difference is invisible because measurement mistake is usually bigger and also performance may change from build to build because of different code layout. At the application level the impact is not relevant. Anyway, this is not a stopper, just an issue that would be great to fix. Full ack. And I would really love to see the same kindness for this RFC and the unsolved issues it may have than the one we had for phpng. This RFC also remembers how critical it is to have a two phases RFC for such complex tasks. It is demoralizing and a waste of time to do things as we do now, for such huge thing. Cheers, Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design by Contract
On 09/02/15 23:47, Yasuo Ohgaki wrote: The RFC draft is ready. https://wiki.php.net/rfc/dbc2 These contracts are evaluated development time only. Therefore, there is no performance penalty with DbC. Sorry but that makes no sense to me at all. If this is something only to use with an IDE then why does it have to have anything that is visible at 'run time'? This seems to be going down the track of we will be compiling this eventually and that is just not what PHP *IS* about. These are more hints, but assume that at runtime what they define is not relevant? ALL of this discussion on type hinting how ever it is handled is simply sidestepping the major plus on PHP with associative arrays. I see no point expanding every database record read to 'magic access functions' for multiple variables and it *IS* the scalar values stored in these arrays that needs the 'hint/constraint' control. I am getting even more confused about just what all the different factions are trying to achieve. Yes I know I can totally ignore all of it, but with my current tools losing traction because of all the 'better ways of working' what in my opinion IS the best way to allow different factions to add their own pet style is drowning simple clean solutions such as docblock. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Script only includes
On Tue, Feb 10, 2015 at 7:52 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, Some of you are tired with this topic, but please take a look the RFC [RFC] Script only includes - this is 3rd version. https://wiki.php.net/rfc/script_only_include Please let me know what you like or dislike. I said before but this RFC tries to solve a problem using yet another security feature in the engine while the OS and the webserver provides way better solutions without adding a possible new pandora box from a security point of view. Many extensions may have to deal with it too. I can only create an empty for all upcoming CVEs about xyz not following script_embed. Alone that tells me that we should not try again to make php more secure using such features. I suppose script_embed ini setting is siimilar to open_basedir but for exec only, which would prevent any script to be exec'ed (require, include, via handlers but works for fopenco) while open_basedir would remain the same (aka also for fopenco). Now, that does prevent one to shoot himself in the foot, eval(file_get_contents());. Yes, this is stupid thing to do, just a bit more stupid that require someuploadedfile; but not much more. Trying to implement security measures to prevent people to exec codes from an unknown file is a bad idea. They will do it one way or another. And if anyone application still do include/require(random/uploaded files), then they surely have many other problems to solve but none of them is really a php problem. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] Design by Contract
We could provide an Invariant class in order to support invariant cases at
least to a certain degree:
http://3v4l.org/vjBRG
Of course, that does not provide the same support as native invariants but
maybe better than nothing. At least we would have a consistent Invariant class
throughout the code bases.
We could go even further and provide some syntactic sugar in order that one
does not need to write new Invariant(...) as in line 28 -- for instance:
$this-a = require( 100);
which is short for
$this-a = new Invariant(function($value){return $value 100;}, '$this-a
100');
Cheers,
Robert
-Ursprüngliche Nachricht-
Von: Dmitry Stogov [mailto:dmi...@zend.com]
Gesendet: Dienstag, 10. Februar 2015 08:06
An: Joe Watkins
Cc: Yasuo Ohgaki; PHP Internals; Stanislav Malyshev
Betreff: Re: [PHP-DEV] Design by Contract
good point, but I think we can do nothing about that.
Anyway, it should be reflected in RFC.
Dmitry.
On Tue, Feb 10, 2015 at 9:59 AM, Joe Watkins pthre...@pthreads.org wrote:
I'm not sure we can always enforce invariant contracts ...
Evaluating invariant expressions on entry and exit is not enough,
since a property can be changed without the use of a method.
Can or should, we do anything about that ?
This should also be covered in the RFC, I think.
Cheers
Joe
On Tue, Feb 10, 2015 at 6:49 AM, Dmitry Stogov dmi...@zend.com wrote:
Hi,
can I make some minor correction?
Thanks. Dmitry.
On Tue, Feb 10, 2015 at 9:25 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Dmitry,
On Tue, Feb 10, 2015 at 1:43 PM, Dmitry Stogov dmi...@zend.com wrote:
On Feb 9, 2015 11:20 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Dmitry and Joe,
On Mon, Feb 9, 2015 at 8:27 PM, Dmitry Stogov dmi...@zend.com
wrote:
yes. this may work.
probably better to put it after extends and implements.
Dmitry.
On Mon, Feb 9, 2015 at 2:19 PM, Joe Watkins
pthre...@pthreads.org
wrote:
Could this be described as a requirement of the class ?
class Mine
require(invariant-expr)
extends Something
implements Someface {
public function method($param) : return
require(input-expr),
return(output-expr) {
}
}
To avoid invariant keyword maybe.
This would work.
If users have adopted DbC in some way, 'invariant' may be used
already.
I see two issues.
Interface works, but most classes are class without interfaces.
Then
users have to repeat
require()/return() many times to check class state or have to use
interface for DbC.
In D classes may have invariant constraints. We may use require
keyword for it. The constraints ineritance rules and order of calls
to constrains must be the same s in D.
class Foo {
private $sum = 0;
require($this-sum = 0); // invariant constraint will be
called before and after every method
function add($n) {
$this-sum += $n;
}
}
OK. I'll update the RFC.
Since compiler does not know a method() is for DbC invariant, it
will
be compiled and exists
in production execution.
Use of interface:
- no additional keyword (pros)
- requires interface for DbC, most classes does not require
interface (cons)
- if interface is not used, user has to repeat invariant
conditions
over and over (cons)
- requires to define method that should not exist in production
(cons)
I didn't understand you idea.
Joe's idea was to use Interface for invariant condition grouping.
If we use your idea, issue is solved.
class Foo {
private $sum = 0;
require($this-sum = 0); // invariant constraint will be
called before and after every method
function add($n) {
$this-sum += $n;
}
}
Ok.
New keyword:
- does not require interface for efficient definition (pros).
- new keyword (cons)
It seems we are better to choose proper keyword for 'invariant'.
'invariant' is not common, so 'invariant'
may be good enough choice. Does anyone use 'invariant' as
function/method/class/constant names?
If there is better name, suggestion is appreciated.
On place closure call like javascript is not supported in PHP,
but
function works with assert.
?php
function foo() { return FALSE; }
assert(foo());
?
PHP Warning: assert(): Assertion failed in - on line 3
This wouldn't be changed for require()/return()/invariant()?
We need a switch to change development/production. I'll use
dbc=On/Off for now.
If you have any better idea, please let me know. (dbc will be
INI_SYSTEM)
Check the expectations RFC. I think, it's going to be 3 state
switch, zero-cost disable, run-time disable, run-time enable. So,
it may be INI_ALL, but it won't be possible to switch from/to zero-cost
at run-time.
Ok.
For
Re: [PHP-DEV] Design by Contract
D uses block syntax:
ensure(ret) {
}
In this case, passing 'ret' as a 'parameter' looks more or less natural.
In our case, two sets of brackets looks weird.
Predefined variable or constant looks better.
A agree, __RETURN__ is longer than $ret, but it also won't conflict with
other variables.
I don't see a perfect solution yet.
may be something similar to Smaltalk block syntax: return(var-name,
expression [, optional-message])
function add($a, $b)
return($ret, $ret 0)
{
return $a + $b;
}
Thanks. Dmitry.
On Tue, Feb 10, 2015 at 1:03 PM, Joe Watkins pthre...@pthreads.org wrote:
The solution D uses is allowing the programmer to declare the name of the
return value like, we could do something like:
public function method()
return ($result) ($result = 10 $result = 0) {
return 5;
}
If you didn't need the result, were working with a scope variable, or
maybe even a param taken by reference:
public function method()
return ($expr) {
/* ... */
}
I'm not keen on __CONSTANTS__, it's long, and if you have the choice to
name the variable you have the option of making the expression ...
expressive ...
Cheers
Joe
On Tue, Feb 10, 2015 at 9:48 AM, Dmitry Stogov dmi...@zend.com wrote:
I think __RETURN__ is better than $ret.
Dmitry.
On Tue, Feb 10, 2015 at 12:43 PM, Patrick Schaaf p...@bof.de wrote:
Am 10.02.2015 09:29 schrieb Dmitry Stogov dmi...@zend.com:
I cnahged $ into $ret, because $ just won't work. Some better
solution is welcome.
Also think $ would be awful. Don't like $ret either. What about a magic
constant __RETURN__ or __RESULT__? This would stand out very well when
glancing at the expression, would fit in with naming of other magic
constants, and might even be made to work in finally blocks, where the same
need for access to the returned value exists.
best regards
Patrick
Re: [PHP-DEV] Design by Contract
Am 10.02.2015 09:29 schrieb Dmitry Stogov dmi...@zend.com: I cnahged $ into $ret, because $ just won't work. Some better solution is welcome. Also think $ would be awful. Don't like $ret either. What about a magic constant __RETURN__ or __RESULT__? This would stand out very well when glancing at the expression, would fit in with naming of other magic constants, and might even be made to work in finally blocks, where the same need for access to the returned value exists. best regards Patrick
Re: [PHP-DEV] [VOTE] Scalar Type Hints
If you measure performance impact using CPU performance counters (VTune, oprofile, perf) or even better CPU emulator (callgrind) you'll see slight degradation. It's also clear that it makes some degradation from code review. 1% difference is invisible because measurement mistake is usually bigger and also performance may change from build to build because of different code layout. Anyway, this is not a stopper, just an issue that would be great to fix. Thanks. Dmtiry. On Tue, Feb 10, 2015 at 11:09 AM, Matt Ficken themattfic...@gmail.com wrote: FYI, the patch doesn't cause a performance regression. I built on and tested with IIS/Windows. Performance remains the same for Wordpress, Symfony and Joomla. Mediawiki actually increased slightly (5%), so performance is increase/decrease is not an issue here, the language and engine are. If you're interested, see: http://windows.php.net/downloads/snaps/ostc/pftt/perf/results-20150209-master_rcaf5521-scalar_type_hints_2_strict_mode-8436.html Regards -M On Mon, Feb 9, 2015 at 6:43 PM, Pierre Joye pierre@gmail.com wrote: On Feb 10, 2015 1:22 AM, Lars Strojny l...@strojny.net wrote: Hi Matteo, sorry for the late response. On 07 Feb 2015, at 12:46, Matteo Beccati p...@beccati.com wrote: Maybe it's just me, but I didn't quite understand the point you are making here. Are you saying that declares are more or less like ini settings? Yes, exactly that. The new declare()-statement will fundamentally change how the engine behaves and one will have two learn more or less two flavors of PHP. Even worse I am forced to use the PHP flavor the person picked who changed the declare() statement last. No. You are not. cu, Lars
Re: [PHP-DEV] Design by Contract
The solution D uses is allowing the programmer to declare the name of the
return value like, we could do something like:
public function method()
return ($result) ($result = 10 $result = 0) {
return 5;
}
If you didn't need the result, were working with a scope variable, or maybe
even a param taken by reference:
public function method()
return ($expr) {
/* ... */
}
I'm not keen on __CONSTANTS__, it's long, and if you have the choice to
name the variable you have the option of making the expression ...
expressive ...
Cheers
Joe
On Tue, Feb 10, 2015 at 9:48 AM, Dmitry Stogov dmi...@zend.com wrote:
I think __RETURN__ is better than $ret.
Dmitry.
On Tue, Feb 10, 2015 at 12:43 PM, Patrick Schaaf p...@bof.de wrote:
Am 10.02.2015 09:29 schrieb Dmitry Stogov dmi...@zend.com:
I cnahged $ into $ret, because $ just won't work. Some better
solution is welcome.
Also think $ would be awful. Don't like $ret either. What about a magic
constant __RETURN__ or __RESULT__? This would stand out very well when
glancing at the expression, would fit in with naming of other magic
constants, and might even be made to work in finally blocks, where the same
need for access to the returned value exists.
best regards
Patrick
Re: [PHP-DEV] [RFC][DISCUSSION] Script only includes
On Tue, Feb 10, 2015 at 1:52 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, Some of you are tired with this topic, but please take a look the RFC [RFC] Script only includes - this is 3rd version. https://wiki.php.net/rfc/script_only_include Please let me know what you like or dislike. Thank you. -- Yasuo Ohgaki yohg...@ohgaki.net Hello, IMHO the real solution to this problem is to educate the programmers how to write safer applications, not by ini settings. Regards Pavel Kouril -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design by Contract
may be something similar to Smaltalk block syntax: return(var-name,
expression [, optional-message])
That's a good approximation of perfect, I think ... looks okay to me.
Cheers
Joe
On Tue, Feb 10, 2015 at 10:21 AM, Dmitry Stogov dmi...@zend.com wrote:
D uses block syntax:
ensure(ret) {
}
In this case, passing 'ret' as a 'parameter' looks more or less natural.
In our case, two sets of brackets looks weird.
Predefined variable or constant looks better.
A agree, __RETURN__ is longer than $ret, but it also won't conflict with
other variables.
I don't see a perfect solution yet.
may be something similar to Smaltalk block syntax: return(var-name,
expression [, optional-message])
function add($a, $b)
return($ret, $ret 0)
{
return $a + $b;
}
Thanks. Dmitry.
On Tue, Feb 10, 2015 at 1:03 PM, Joe Watkins pthre...@pthreads.org
wrote:
The solution D uses is allowing the programmer to declare the name of the
return value like, we could do something like:
public function method()
return ($result) ($result = 10 $result = 0) {
return 5;
}
If you didn't need the result, were working with a scope variable, or
maybe even a param taken by reference:
public function method()
return ($expr) {
/* ... */
}
I'm not keen on __CONSTANTS__, it's long, and if you have the choice to
name the variable you have the option of making the expression ...
expressive ...
Cheers
Joe
On Tue, Feb 10, 2015 at 9:48 AM, Dmitry Stogov dmi...@zend.com wrote:
I think __RETURN__ is better than $ret.
Dmitry.
On Tue, Feb 10, 2015 at 12:43 PM, Patrick Schaaf p...@bof.de wrote:
Am 10.02.2015 09:29 schrieb Dmitry Stogov dmi...@zend.com:
I cnahged $ into $ret, because $ just won't work. Some better
solution is welcome.
Also think $ would be awful. Don't like $ret either. What about a
magic constant __RETURN__ or __RESULT__? This would stand out very well
when glancing at the expression, would fit in with naming of other magic
constants, and might even be made to work in finally blocks, where the same
need for access to the returned value exists.
best regards
Patrick
Re: [PHP-DEV] Design by Contract
Hello, internals!
DbC is good thing, but the way you want to do this via language changes is
really awful. Why do you want to add more custom features into the
language, instead of providing an API to extend it in a more natural way by
framework developers?
Many existing implementation of DbC is just kind of bytecode compilers and
IDE tools. Main idea of DbC is to help developer with writing a better code
without errors. But then, during compiling (production mode) all checks
will be removed.
Am I one who think that this code is looking weird?
public function destroy($id)
require(strlen http://www.php.net/strlen($id) 10)
return(is_bool http://www.php.net/is_bool($))
{
@unlink http://www.php.net/unlink($this-path . $id);
}
This part of code is breaks block structure of function, adding custom
part of code, which is not related to the function logic itself.
Instead of doing this weird syntax only for personal fun, just think
about more general usages of parser and assertions.
As you know, I'm working with aspect-oriented programming in PHP and
have a library for that. And it wasn't easy to implement it, because
there is no API for that from PHP. This techniques can be also used
for DbC as well.
So, my suggestion is to drop current rfc and start more general one,
called PHP Language Extension API, which will include an API for
defining metadata and API for opcode manipulation. Compare previous
example with another one with plain metadata:
[Require = strlen http://www.php.net/strlen($id) 10)]
[Return = is_bool http://www.php.net/is_bool($__result))
public function destroy($id)
{
@unlink http://www.php.net/unlink($this-path . $id);
}
This code then will be parsed and PHP hooks that were registered by
register_parser_extension() will be called and extension will
produce a valid opcodes for that for method destroy(), by modifying AST-node.
This way is much elegant and can be reused later for many features,
like Design By Contracts, native SQL support syntax in PHP (LINQ),
Aspect-Oriented Programming, hooks and much more.
Just stop to create custom features in the engine itself and give this
work for framework and PHP-extension developers.
2015-02-10 13:32 GMT+03:00 Lester Caine les...@lsces.co.uk:
On 09/02/15 23:47, Yasuo Ohgaki wrote:
The RFC draft is ready.
https://wiki.php.net/rfc/dbc2
These contracts are evaluated development time only. Therefore, there is
no performance penalty with DbC.
Sorry but that makes no sense to me at all. If this is something only to
use with an IDE then why does it have to have anything that is visible
at 'run time'? This seems to be going down the track of we will be
compiling this eventually and that is just not what PHP *IS* about.
These are more hints, but assume that at runtime what they define is not
relevant?
ALL of this discussion on type hinting how ever it is handled is simply
sidestepping the major plus on PHP with associative arrays. I see no
point expanding every database record read to 'magic access functions'
for multiple variables and it *IS* the scalar values stored in these
arrays that needs the 'hint/constraint' control.
I am getting even more confused about just what all the different
factions are trying to achieve. Yes I know I can totally ignore all of
it, but with my current tools losing traction because of all the 'better
ways of working' what in my opinion IS the best way to allow different
factions to add their own pet style is drowning simple clean solutions
such as docblock.
--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new json, push generated file?
Hey On Tue, Feb 10, 2015 at 2:47 AM, Xinchen Hui larue...@php.net wrote: why make this thing in this way complicated? why not just simply include the generated files as others did? First of all the others did exactly what I have already done. :) It means they included re2c generated files and did not include bison generated files. There are few reasons why I would like to do it slightly differently in json and make the re-generation optional. 1. I want to prevent an accidental re-generation of files with the old version of re2c and bison. It happens to me from time to time when I switch branches and build often. Then I see that I have changes (git diff) in the zend_language_scanner.c and other re2c generated files even if I haven't edited them. The reason is because the version that I use is different and the files got regenerated (you won't see that if you use the same version). That could be even bigger problem with bison where the the version differences are much more often. 2. As soon as I start using new features (like utf8 ranges in re2c) that are not available in the old version and someone would try to do some changes in the scanner and regenerate it, then it would fail with error. I believe that it's better if the user gets a warning during the configuration and the compilation exits the build instead of generating an error. 3 It is sort of a signal which version is currently supported and it hopefully prevents things like regenerating files with the old version and pushing it to the repo (as Anatol did yesterday in https://github.com/php/php-src/commit/89893541305594eba373c15156eb54d7a7cb5960 ). As I said in the PR. This change won't affect anyone who doesn't change json scanner and parser which is 99% of all users that build PHP. The 1% is probably just me so it's not really complicated IMHO... I would also like to add all of this to the json README (it's very outdated and I plan to update it anyway) and possibly other build doc if we have any. Cheers Jakub
Re: [PHP-DEV] Design by Contract
2015-02-10 14:56 GMT+03:00 Patrick Schaaf b...@bof.de: Ahem. Any open ended API-for-frameworks will A) force me to pick a framework and bend to the way it wants these things to look, and B) result in fragmentation and incompatibilities for any two pieces of code/library developed with different such frameworks in mind. That will be a total mess. It's another task for another people, typically for standartization group, like PSR, JSR, PEP, etc. Framework developers should rely on interfaces and should provide interfaces. For Java world this works (some ideas here http://java.dzone.com/articles/jsr-305-and-design-contract) If put all the things into the PHP core, it will become much bigger, more slower and hard to maintain. Later posts describes EOL for some extensions and SAPIs, but this place will not be clean, because another custom feature XXX is landed on free space. I would like to see a language with good extension API. For now, it's almost impossible to extend a parser, even from extension level (however, PHP7 will have a hook for that, thanks God).
Re: [PHP-DEV] Design by Contract
Hi Joe, On Tue, Feb 10, 2015 at 4:40 PM, Joe Watkins pthre...@pthreads.org wrote: It doesn't seem to make sense to do that, a derived class should be able to define additional contracts, but not change the contracts of it's parent. I forgot that invariants in D and Eiffel implicitly inherits parent's invariants. So classes that causes problems have design bug. Please go ahead editing the file. I wouldn't have time until next morning. There will be hours. I'll wait as long as it takes. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Design by Contract
Hi Joe,
You are welcome to edit https://wiki.php.net/rfc/dbc2
It looks like we have similar views, so just make it better in a way you
think.
Thanks. Dmitry.
On Tue, Feb 10, 2015 at 11:49 AM, Joe Watkins pthre...@pthreads.org wrote:
I'm happy to clean up the RFC after Dmitry's changes are merged.
Happy to author some of the content if Yasuo is busy or wants help ?
Cheers
Joe
On Tue, Feb 10, 2015 at 8:29 AM, Dmitry Stogov dmi...@zend.com wrote:
A bit updated version of RFC is attached.
As I removed more than added, I decided not to put it on wiki before
internal agreement.
Actually, I would also remove most part of introduction as well, to make
RFC more compact and clean.
I cnahged $ into $ret, because $ just won't work. Some better solution
is welcome.
The RFC misses contract inheritance rules. They must be defined
separately for preconditions, postconditions and invariants.
Yasuo, could you please check, how it's implemented in D and add missing
section.
We will need English correction after all.
Thanks. Dmitry.
On Tue, Feb 10, 2015 at 11:19 AM, Dmitry Stogov dmi...@zend.com wrote:
completely agree. contracts must be permanent.
Thanks. Dmitry.
On Tue, Feb 10, 2015 at 10:40 AM, Joe Watkins pthre...@pthreads.org
wrote:
Example code never works, I can just say that's a bad abstraction,
vertebrate and invertebrate are distinct and abstraction should reflect
that.
Why should we provide a way to change contracts is the question ?
It doesn't seem to make sense to do that, a derived class should be
able to define additional contracts, but not change the contracts of it's
parent.
Cheers
Joe
On Tue, Feb 10, 2015 at 7:36 AM, Yasuo Ohgaki yohg...@ohgaki.net
wrote:
Hi Joe,
On Tue, Feb 10, 2015 at 4:31 PM, Joe Watkins pthre...@pthreads.org
wrote:
Actually I'm not sure it's at all sane to try to override contracts,
I'd actually avoid that completely, so no need to name contracts and no
need for magic __invariant.
For example,
class Animal {
protected $legs;
require($legs = 0);
}
class Snake extends Animal {
// Snake is fine, no leg
}
class Human extends Animal {
// 2 legs. $this-leg === 2
}
Overriding makes sense for many cases.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] Design by Contract
Am 10.02.2015 12:45 schrieb Alexander Lisachenko lisachenko...@gmail.com : DbC is good thing, but the way you want to do this via language changes is really awful. Why do you want to add more custom features into the language, instead of providing an API to extend it in a more natural way by framework developers? Ahem. Any open ended API-for-frameworks will A) force me to pick a framework and bend to the way it wants these things to look, and B) result in fragmentation and incompatibilities for any two pieces of code/library developed with different such frameworks in mind. That will be a total mess. Having it in the language means I can just use it. Unit tests can just use it, especially the PHP tests themselves. And if and where frameworks think they need to mess with it, they can surely be given some Reflection API to have a go at it. best regards Patrick
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors Update
On Sat, Feb 7, 2015 at 2:32 PM, Matteo Beccati p...@beccati.com wrote: Hi Levi, I have updated the RFC for removing PHP 4 constructors[1]. Notably, I have pushed off the removal to PHP 8, and instead only deprecate them in PHP 7. The rationale is that eventual consistency in this matter is good enough for now, and going slow may help avoid a Python 2 vs 3 type disaster where older libraries aren't updated fast enough. I intend to put this to vote soon, as we are approaching the March feature freeze, so please chime in if you have been wanting to voice your opinion and haven't. Over-long email - sorry about it! ;) I strongly opposed this RFC in past. I've also seen people suggesting to grumpy old men like me that the time spent complaining was probably enough to fix our legacy codebases to replace PHP4-constructors. That is certainly not true in my case, but I've decided to accept the challenge and build a tool to convert PHP4-constructors to __construct, automating the required tasks as much as possible. Such work is an ongoing PR to PHP-CS-Fixer[1], which will hopefully be merged in the next few weeks. I've advertised it before, but I'd like to do it again, as I think it greatly reduces the impact of the BC break of your RFC. I've ran it on the (legacy) open source application I maintain and it detected and converted most of the classes[2]: 962 changed files with 351 additions and 884 deletions. The only manual changes I had to do were fixing a few calls to the grandparent constructors[3]. What I can tell from this experience is that dropping PHP4-constructors shouldn't be quite as bad as I thought it was, at least now that there's a tool that does most of the job for you. Adapting (all of) PEAR should be fairly straightforward in case someone is willing to do that. thanks for looking into this and taking your time to help with the migration! The real challenge I will have to face in the future is the removal of Scoped calls of non-static methods from incompatible $this context, which has been applied and temporarily reverted soon after. Many PEAR (and possibly non-PEAR) classes in our codebase have methods that have been designed to work both as static/non-static methods[4] which won't soon work any more in PHP7. Granted, I've voted yes on this one and I still would today, but I'd expect that fixing that code once the revert is reverted is going to be much trickier than just renaming a bunch of constructors. we discussed this related to PEAR and Nikita agreed that the original implementation of the removal was too strict: http://chat.stackoverflow.com/transcript/11?m=21058930#21058930 and he even come up with an alternative solution: https://github.com/php/php-src/pull/1026 (not sure why didn't he merged or announced it for discussion yet). -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Design by Contract
Hi Dmitry and Joe, On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov dmi...@zend.com wrote: You are welcome to edit https://wiki.php.net/rfc/dbc2 It looks like we have similar views, so just make it better in a way you think. Looks good to me. It's much better than original. Thank you folks. We have related issue like how internal module incorporate with DbC. However these could be future issues. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Design by Contract
Hi Dmitry and Joe,
On Wed, Feb 11, 2015 at 6:29 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov dmi...@zend.com wrote:
You are welcome to edit https://wiki.php.net/rfc/dbc2
It looks like we have similar views, so just make it better in a way you
think.
Looks good to me. It's much better than original. Thank you folks.
We have related issue like how internal module incorporate with DbC.
However
these could be future issues.
It seems we are better to have scope explanation. precondition/invariant
does not
matter but postcondition is. For example,
function foo() {
return($ret, $ret 0 $tmp 0, 'Error');
$tmp = 0;
// do something using $tmp
}
if this is allowed or not is ambiguous.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
On 10 Feb 2015, at 9:29 am, Anatol Belski anatol@belski.net wrote: Hi, the voting on the removals in PHP7 in hereby finished. The results are item yes:no sapi/aolserver 32:0 sapi/apache32:0 sapi/apache_hooks 31:0 sapi/apache2filter 23:1 sapi/caudium 30:0 sapi/continuity28:0 sapi/isapi 28:0 sapi/milter10:9 sapi/phttpd26:0 sapi/pi3web24:0 sapi/roxen 23:0 sapi/thttpd25:0 sapi/tux 25:0 sapi/webjames 25:0 ext/imap 14:19 ext/mcrypt 15:18 ext/mssql 17:13 ext/pdo_dblib 4:18 ext/sybase_ct 17:1 As most of the items are considered to be removed, the ones to stay untouched by the 50%+1 requirement are ext/imap ext/mcrypt ext/pdo_dblib I'm going to implement and tag the changes considered ASAP. Regarding the stuff to considered to be removed from the core - if there are some supporters, the sources will be made available in the git tag. They can be anytime ported to PHP7 and possibly resurrected. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Does this mean PHP will be taking on the role of maintaining libmcrypt as well? If a security issue is found, what is the course of action? Cheers, David Sent from my iPhone -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
On 10 February 2015 21:38:02 GMT, David Muir davidkm...@gmail.com wrote: On 10 Feb 2015, at 9:29 am, Anatol Belski anatol@belski.net wrote: Hi, the voting on the removals in PHP7 in hereby finished. The results are item yes:no sapi/aolserver 32:0 sapi/apache32:0 sapi/apache_hooks 31:0 sapi/apache2filter 23:1 sapi/caudium 30:0 sapi/continuity28:0 sapi/isapi 28:0 sapi/milter10:9 sapi/phttpd26:0 sapi/pi3web24:0 sapi/roxen 23:0 sapi/thttpd25:0 sapi/tux 25:0 sapi/webjames 25:0 ext/imap 14:19 ext/mcrypt 15:18 ext/mssql 17:13 ext/pdo_dblib 4:18 ext/sybase_ct 17:1 As most of the items are considered to be removed, the ones to stay untouched by the 50%+1 requirement are ext/imap ext/mcrypt ext/pdo_dblib I'm going to implement and tag the changes considered ASAP. Regarding the stuff to considered to be removed from the core - if there are some supporters, the sources will be made available in the git tag. They can be anytime ported to PHP7 and possibly resurrected. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Does this mean PHP will be taking on the role of maintaining libmcrypt as well? If a security issue is found, what is the course of action? It means people want to find some more friendly way of moving forward rather than deleting the extension and letting users deal with the consequences. I don't think anyone has suggested maintaining the underlying library. Several have suggested attempting to build at least a partial compatibility layer on top of openssl or other maintained libraries. Others have suggested adding aggressive warnings whenever the extension is used. I'm sure more suggestions will follow. What is clear is that *something* should be done, but that consensus was that simple removal was not appropriate in this case. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design by Contract
I think reusing syntax for existing operator in completely unrelated
context is a big mistake.
I keep hearing that, I agree, but adding keywords presents it's own
problems.
The keywords can always be changed, maybe they can be a voting option even.
Cheers
Joe
On Wed, Feb 11, 2015 at 6:56 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
Please steer clear of using the assert API, and in so doing avoid BC
concerns with the current assert API.
The operator can be called something other than assert, I'm sure the
thesaurus has a lot of possibilities.
Please avoid adding a magic method and use the suggested syntax for
invariant.
class Some {
require(invariant-expr);
I think reusing syntax for existing operator in completely unrelated
context is a big mistake. Having code outside of functions is probably
not the best idea too.
--
Stas Malyshev
smalys...@gmail.com
Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi David, On Tue, February 10, 2015 22:38, David Muir wrote: On 10 Feb 2015, at 9:29 am, Anatol Belski anatol@belski.net wrote: Hi, the voting on the removals in PHP7 in hereby finished. The results are item yes:no sapi/aolserver 32:0 sapi/apache32:0 sapi/apache_hooks 31:0 sapi/apache2filter 23:1 sapi/caudium 30:0 sapi/continuity 28:0 sapi/isapi 28:0 sapi/milter10:9 sapi/phttpd 26:0 sapi/pi3web24:0 sapi/roxen 23:0 sapi/thttpd 25:0 sapi/tux 25:0 sapi/webjames 25:0 ext/imap 14:19 ext/mcrypt 15:18 ext/mssql 17:13 ext/pdo_dblib 4:18 ext/sybase_ct 17:1 As most of the items are considered to be removed, the ones to stay untouched by the 50%+1 requirement are ext/imap ext/mcrypt ext/pdo_dblib I'm going to implement and tag the changes considered ASAP. Regarding the stuff to considered to be removed from the core - if there are some supporters, the sources will be made available in the git tag. They can be anytime ported to PHP7 and possibly resurrected. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Does this mean PHP will be taking on the role of maintaining libmcrypt as well? If a security issue is found, what is the course of action? not that I knew, libmcrypt is not maintained. An alternative were openssl probably. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi David, On Tue, February 10, 2015 22:38, David Muir wrote: On 10 Feb 2015, at 9:29 am, Anatol Belski anatol@belski.net wrote: Hi, the voting on the removals in PHP7 in hereby finished. The results are item yes:no sapi/aolserver 32:0 sapi/apache32:0 sapi/apache_hooks 31:0 sapi/apache2filter 23:1 sapi/caudium 30:0 sapi/continuity 28:0 sapi/isapi 28:0 sapi/milter10:9 sapi/phttpd 26:0 sapi/pi3web24:0 sapi/roxen 23:0 sapi/thttpd 25:0 sapi/tux 25:0 sapi/webjames 25:0 ext/imap 14:19 ext/mcrypt 15:18 ext/mssql 17:13 ext/pdo_dblib 4:18 ext/sybase_ct 17:1 As most of the items are considered to be removed, the ones to stay untouched by the 50%+1 requirement are ext/imap ext/mcrypt ext/pdo_dblib I'm going to implement and tag the changes considered ASAP. Regarding the stuff to considered to be removed from the core - if there are some supporters, the sources will be made available in the git tag. They can be anytime ported to PHP7 and possibly resurrected. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Does this mean PHP will be taking on the role of maintaining libmcrypt as well? If a security issue is found, what is the course of action? not that I knew, libmcrypt is not maintained. An alternative were openssl probably. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Script only includes
Hi!
Some of you are tired with this topic, but please take a look the RFC
[RFC] Script only includes - this is 3rd version.
https://wiki.php.net/rfc/script_only_include
Please let me know what you like or dislike.
I think there are several issues with this RFC:
1. It does not protect against all the problems it purports to protect.
I.e. if you want to protect against local PHP code accessing evil
uploaded files, local PHP code can also do echo
file_get_contents('/etc/paswd') and still have a problem (actually, very
common LFI issue). Even if the application only allows to require
random file, it may be possible to inject data via other means - such as
data stream, URL, temp files, session files, etc. Upload is not the only
way inputs can be controlled.
2. Legitimate files can include ? as byte sequence - in fact, it is
almost guaranteed big enough binary file would contain it. Restricting
upload of such files would break uploading functionality on many sites.
3. General approach of this RFC is, given site with glaring security
hole in their code, give them a measure of protection against some of
the consequences. This looks like safe_mode approach, and that proved
ineffective in the past.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design by Contract
Hi!
1) contracts in doc-commetns https://wiki.php.net/rfc/dbc
/**
* @requires ($a = 0)
*/
function foo($a) {
}
We've spent several years rejecting annotations because no information
can be in comments, not even a little bit, not even a tiny. Now we'd
have full-blown running code in comments? How would this code be
debugged/profiled/interpreted by tools? Writing PHP parser is not easy
right now, but this would turn it into nightmare (what if you have a
comment inside @requires? etc.)
2) contracts as part of the language https://wiki.php.net/rfc/dbc2
function foo($a)
require($a = 0)
{
}
This is a step better but still we have the similar issues with
readability, to which reuse of 'require' is added.
3) contracts in annotations
requires($a = 0)
function foo($a) {
}
That one actually looks better to me, but: I'm not sure how annotation
syntax is supposed to support expressions or closures, yet more - how it
is supposed to share the scope with the function. I.e., if you define
annotation class/method/function/data structure/whatever it is, what it
is supposed to receive? Is it some special form of annotation for this
purpose only (meh)?
Oh, and syntax is *ugly* ;)
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotated PHP 5-7 extension diff
Hi all, On Fri, Feb 6, 2015 at 10:38 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: It looks like this: https://gist.github.com/anonymous/15cbc9947edb4f0a71fd It uses session save handler uses PS_MOD() which is legacy. I may help to adopt PS_MOD_TIMESTAMP(). It eliminates writes and boost session performance a lot if apps do not update session data always. My environment is [yohgaki@dev helm]$ rpm -q memcached memcached-1.4.17-3.fc21.x86_64 I've just built it with current master/php7 branch and I got Without Valgrind = FAILED TEST SUMMARY - Memcached::cas() with strange key [ext/memcached/tests/experimental/cas_invalid_key.phpt] Memcached::deleteByKey() [ext/memcached/tests/experimental/delete_bykey.phpt] Memcached::get() [ext/memcached/tests/experimental/get.phpt] Memcached::getByKey() with CAS [ext/memcached/tests/experimental/get_bykey_cas.phpt] Memcached::phpinfo() [ext/memcached/tests/experimental/moduleinfo.phpt] = = WARNED TEST SUMMARY - Memcached store, fetch touch expired key [ext/memcached/tests/expire.phpt] (warn: XFAIL section but test passes) = With Valgrind = FAILED TEST SUMMARY - Memcached::cas() with strange key [ext/memcached/tests/experimental/cas_invalid_key.phpt] Memcached::deleteByKey() [ext/memcached/tests/experimental/delete_bykey.phpt] Memcached::get() [ext/memcached/tests/experimental/get.phpt] Memcached::getByKey() with CAS [ext/memcached/tests/experimental/get_bykey_cas.phpt] Memcached::phpinfo() [ext/memcached/tests/experimental/moduleinfo.phpt] = = WARNED TEST SUMMARY - Memcached store, fetch touch expired key [ext/memcached/tests/expire.phpt] (warn: XFAIL section but test passes) = = LEAKED TEST SUMMARY - Memcached::set()/delete() UDP [ext/memcached/tests/experimental/get_udp.phpt] Memcached::setMultiByKey() [ext/memcached/tests/experimental/setmulti_bykey.phpt] Memcached::setMulti() [ext/memcached/tests/setmulti.phpt] = If this is normal, I'll ignore them all and start adopting new save handler API. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Annotated PHP 5-7 extension diff
Hey: On Wed, Feb 11, 2015 at 2:07 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, On Fri, Feb 6, 2015 at 10:38 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: It looks like this: https://gist.github.com/anonymous/15cbc9947edb4f0a71fd It uses session save handler uses PS_MOD() which is legacy. I may help to adopt PS_MOD_TIMESTAMP(). It eliminates writes and boost session performance a lot if apps do not update session data always. My environment is [yohgaki@dev helm]$ rpm -q memcached memcached-1.4.17-3.fc21.x86_64 I've just built it with current master/php7 branch and I got Without Valgrind = FAILED TEST SUMMARY - Memcached::cas() with strange key [ext/memcached/tests/experimental/cas_invalid_key.phpt] Memcached::deleteByKey() [ext/memcached/tests/experimental/delete_bykey.phpt] Memcached::get() [ext/memcached/tests/experimental/get.phpt] Memcached::getByKey() with CAS [ext/memcached/tests/experimental/get_bykey_cas.phpt] Memcached::phpinfo() [ext/memcached/tests/experimental/moduleinfo.phpt] = = WARNED TEST SUMMARY - Memcached store, fetch touch expired key [ext/memcached/tests/expire.phpt] (warn: XFAIL section but test passes) = With Valgrind = FAILED TEST SUMMARY - Memcached::cas() with strange key [ext/memcached/tests/experimental/cas_invalid_key.phpt] Memcached::deleteByKey() [ext/memcached/tests/experimental/delete_bykey.phpt] Memcached::get() [ext/memcached/tests/experimental/get.phpt] Memcached::getByKey() with CAS [ext/memcached/tests/experimental/get_bykey_cas.phpt] Memcached::phpinfo() [ext/memcached/tests/experimental/moduleinfo.phpt] = = WARNED TEST SUMMARY - Memcached store, fetch touch expired key [ext/memcached/tests/expire.phpt] (warn: XFAIL section but test passes) = = LEAKED TEST SUMMARY - Memcached::set()/delete() UDP [ext/memcached/tests/experimental/get_udp.phpt] Memcached::setMultiByKey() [ext/memcached/tests/experimental/setmulti_bykey.phpt] Memcached::setMulti() [ext/memcached/tests/setmulti.phpt] = The fails must be know... relates to key name checking the leaks needs to be take care, I will look into it. anyway, these should not affects your work, thanks If this is normal, I'll ignore them all and start adopting new save handler API. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- 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] Design by Contract
We have related issue like how internal module incorporate with DbC.
However
these could be future issues.
I think this should be an additional RFC, so we'll put this under future
issues I think.
A little more clarification, following interface definition is allowed
or not?
Currently, we're saying that abstract functions (and interface functions)
may not use contracts.
Since interface methods are abstract functions, and abstract functions do
no have a body, it doesn't seem to make sense to allow them to use
contracts.
The contracts are supposed to purtain to the body of the function, or the
body of all functions in a class in the case of invariants: No body, no
contracts.
I'll make this clear ...
I'll work a bit more on the RFC today ...
Cheers
Joe
On Wed, Feb 11, 2015 at 3:01 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Dmitry and Joe,
On Wed, Feb 11, 2015 at 6:29 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov dmi...@zend.com wrote:
You are welcome to edit https://wiki.php.net/rfc/dbc2
It looks like we have similar views, so just make it better in a way you
think.
Looks good to me. It's much better than original. Thank you folks.
We have related issue like how internal module incorporate with DbC.
However
these could be future issues.
I would like explain one of the reason why I bring up internal module.
http://php.net/manual/en/class.sessionhandlerinterface.php
Session has internal interface definitions like
SessionHandlerInterface {
/* Methods */
abstract public bool close ( void )
abstract public bool destroy ( string $session_id )
abstract public bool gc ( string $maxlifetime )
abstract public bool open ( string $save_path , string $name )
abstract public string read ( string $session_id )
abstract public bool write ( string $session_id , string $session_data )
}
but it should be like follows to be precise.
SessionHandlerInterface {
/* Methods */
abstract public bool close ( void )
return($ret, is_bool($ret));
abstract public bool destroy ( string $session_id )
require(strlen($session_id) 0)
return($ret, is_bool($ret));
abstract public bool gc ( string $maxlifetime )
require($maxlifetime = 0)
return($ret, is_int($ret) $ret = -1);
abstract public bool open ( string $save_path , string $name )
require(is_string($save_path))
require(is_string($name));
return($ret, is_bool($ret));
abstract public string read ( string $session_id )
require(strlen($session_id) 0)
return($ret, is_bool($ret) || is_string($ret));
abstract public bool write ( string $session_id , string $session_data )
require(is_string($session_id) strlen($session_id) 0)
require(is_string($session_data))
return($ret, is_bool($ret));
}
This definition is more user friendly. There were too many user save
handlers
that do not return proper values because of current interface limitation.
Scalar type and return type hint helps, but it does not cover
return($ret, is_int($ret) $ret = -1);
for example.
If you think this is easy to implement and should be in the RFC, I would
appreciated it
and use it to raise assertion errors just like user class/interface.
BTW, these restrictions are coded as error in current session module and
should
be checked by the module always. It's not mandatory for the RFC, but just
a missing piece.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] Design by Contract
I think we can't support contracts on interfaces and abstract methods.
How D works?
Thanks. Dmitry.
On Wed, Feb 11, 2015 at 1:56 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Dmitry and Joe,
On Wed, Feb 11, 2015 at 6:29 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov dmi...@zend.com wrote:
You are welcome to edit https://wiki.php.net/rfc/dbc2
It looks like we have similar views, so just make it better in a way you
think.
Looks good to me. It's much better than original. Thank you folks.
We have related issue like how internal module incorporate with DbC.
However
these could be future issues.
A little more clarification, following interface definition is allowed or
not?
interface Some {
require($this-last_result 1000); // Force classes to have
$this-result
function bar($a, $b)
require($a $b)
return($ret, $ret 1000);
function getLastResult()
return($ret, $this-last_result === $ret);
}
I suppose it is supported, but it may be better to be explicit.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] Design by Contract
I still don't see what's wrong with just putting the code
at the beginning of the function and whenever you want to check it
That makes inheritance of contracts awkward/impossible/impractical:
class Some {
public function method() {
assertOrWhatever($expr);
}
}
class Other extends Some {
public function method() {
}
}
The implementation of Other::method cannot inherit or otherwise make use of
the contracts made by Some.
Putting invariants in the class scope and pre/post conditions in the
function prototype makes inheritance relatively easy.
This seems to answer all your questions.
Cheers
Joe
On Wed, Feb 11, 2015 at 7:11 AM, Joe Watkins pthre...@pthreads.org wrote:
I think reusing syntax for existing operator in completely unrelated
context is a big mistake.
I keep hearing that, I agree, but adding keywords presents it's own
problems.
The keywords can always be changed, maybe they can be a voting option even.
Cheers
Joe
On Wed, Feb 11, 2015 at 6:56 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
Please steer clear of using the assert API, and in so doing avoid BC
concerns with the current assert API.
The operator can be called something other than assert, I'm sure the
thesaurus has a lot of possibilities.
Please avoid adding a magic method and use the suggested syntax for
invariant.
class Some {
require(invariant-expr);
I think reusing syntax for existing operator in completely unrelated
context is a big mistake. Having code outside of functions is probably
not the best idea too.
--
Stas Malyshev
smalys...@gmail.com
Re: [PHP-DEV] Design by Contract
it's possible to achieve the same validation just with assert() spread over the code. It's nothing wrong with this, but this is not DbC. The question, if we need DbC at all, is still open. Thanks. Dmitry. On Wed, Feb 11, 2015 at 10:05 AM, Stanislav Malyshev smalys...@gmail.com wrote: Hi! Hello, internals! DbC is good thing, but the way you want to do this via language changes is really awful. Why do you want to add more custom features into the Agreed here. I still don't see what's wrong with just putting the code at the beginning of the function and whenever you want to check it. Why this need to change the language syntax? OK, you don't like assert because it's limited or performance-costly or whatever. We can fix that. Why we need weird syntax that places function code in three different places, reuses existing syntax constructs for things that have nothing to do with their original use and look like Perl YAPH signature? I understand implementing fashionable concepts is fun, but must they come with weird syntax? Why can't we keep it simple? -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
On Wed, Feb 11, 2015 at 7:36 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 02/10/2015 07:57 PM, Xinchen Hui wrote:
am I wrong?!
seems I am wrong with this, it's a false alarm... it can restore
automatically.
Yeah, declare() doesn't span files so that isn't a problem.
My worry is still the lack of type coercion for internal calls. I tested
it on some apps and it will take quite a bit of tedious and rather
useless effort to fix these to run in strict mode. Some examples of
common things that are fatal errors in strict mode:
ini_set('precision', 14);
ini_set('display_errors', 1);
ini_set('display_errors', true);
ok, not common, but tan(4/2) fatal, tan(5/2) no error
Wordpress has this function, spot the error:
function add_magic_quotes( $array ) {
foreach ( (array) $array as $k = $v ) {
if ( is_array( $v ) ) {
$array[$k] = add_magic_quotes( $v );
} else {
$array[$k] = addslashes( $v );
}
}
return $array;
}
$v may not always be a string (it died with a float for me), so the
fix is to cast:
$array[$k] = addslashes( (string)$v );
Also from Wordpress:
$formatted = number_format( $number, absint( $decimals ),
$wp_locale-number_format['decimal_point'],
$wp_locale-number_format['thousands_sep'] );
Here number_format() is expecting a float but $number is a string. So
again, the only real fix is to cast.
And in Drupal8 *without turning on strict*:
use Drupal\Component\Utility\String;
it dies with: Fatal error: string cannot be used as a class name in
/var/www/drupal/core/includes/bootstrap.inc on line 11
That String class is everywhere in Drupal. They are going to have a
fun time with that. See
https://gist.githubusercontent.com/anonymous/d9252deeeb2aae1a5af5/raw/053155130d22551b1404d0a9b94e27424544b6d1/gistfile1
From Geeklog:
if (strtolower($topic) != strtolower($archivetid)) {
$sql .= AND ta.tid != '{$archivetid}' ;
}
$topic can be null there. Looking at the logic, not really a bug,
just a natural reliance on null being coerced to
Also from Geeklog:
if( empty( $date )) {
// Date is empty, get current date/time
$stamp = time();
} else if( is_numeric( $date )) {
// This is a timestamp
$stamp = $date;
} else {
// This is a string representation of a date/time
$stamp = strtotime( $date );
}
// Format the date
$date = strftime( $dateformat, $stamp );
strftime() expects an integer for the timestamp there, but as the
above logic shows, they are expecting a numeric string to be fine.
No bug, just another forced cast.
And another number_format() instance where arg1 is not necessarily
a float. Obviously not a bug, so we have to cast again:
return number_format( $number, $dc, $ds, $ts );
In Opencart:
$this-image = imagecreatetruecolor($width, $height);
imagecreatetruecolor() expects parameter 1 to be integer, string
given in /var/www/opencart/system/library/image.php on line 89
You could argue this is a bug, I guess, but the width and height are
coming from a database and are integers in the db, but since the db
returns strings. Another cast...
I was genuinely hoping to find some bugs with this exercise. I suppose
it is because I did it on mature projects and at this stage those sorts
of bugs have already been fixed. But I still fear that people are going
to want to be enable strictness everywhere and then they will quickly
learn that they better cast stuff to be safe which makes the whole thing
rather pointless. And I feel pretty sorry for the Drupal folks. That
list of 1000+ instances of their String class is going to suck to fix.
-Rasmus
Helo,
the Drupal thing seems scary.
Also, I realized one thing why I think the strict version is a bad
idea for PHP (in the state PHP is now - in an ideal world I would love
to have nothing but strongly typed PHP, but that's offtopic) - PHP has
many functions that return multiple types, so you cannot do foo(bar())
if bar() has multiple return types. :(
Regards
Pavel Kouril
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design by Contract
So it turns out that invariant is already deprecated in D, they have dropped it in favour of immutable properties. I guess I'll have to install an old version, or try to extract everything we need from their obviously outdated documentation ... Grrr ... Cheers Joe On Wed, Feb 11, 2015 at 7:50 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Dmitry, On Wed, Feb 11, 2015 at 4:26 PM, Dmitry Stogov dmi...@zend.com wrote: I think we should just repeat the related D semantic. It must be defined in contracts inheritance rules. What if we have contracts for prototype method in parent class and interface? Should we still validate contracts of parent and interface if we add our owns? etc. Both D and Eiffel evaluates all contracts defined in parents/interfaces. Both D and Eiffel has method like invariant definition. They don't inherit explicitly, but inherit implicitly always. That's why I sent strange mail. I read code and misunderstood by mistake. I don't code with D much, but I really like the feature ;) Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Design by Contract
Got it, but currently we don't declare internal classes/interfaces in PHP.
We do it with internal C API, of course we may extend it to support
contracts, but it looks too complex for C.
It's easier to make all necessary validation directly in C code.
I don't think we should propose something related now.
Thanks. Dmitry.
On Wed, Feb 11, 2015 at 6:01 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Dmitry and Joe,
On Wed, Feb 11, 2015 at 6:29 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov dmi...@zend.com wrote:
You are welcome to edit https://wiki.php.net/rfc/dbc2
It looks like we have similar views, so just make it better in a way you
think.
Looks good to me. It's much better than original. Thank you folks.
We have related issue like how internal module incorporate with DbC.
However
these could be future issues.
I would like explain one of the reason why I bring up internal module.
http://php.net/manual/en/class.sessionhandlerinterface.php
Session has internal interface definitions like
SessionHandlerInterface {
/* Methods */
abstract public bool close ( void )
abstract public bool destroy ( string $session_id )
abstract public bool gc ( string $maxlifetime )
abstract public bool open ( string $save_path , string $name )
abstract public string read ( string $session_id )
abstract public bool write ( string $session_id , string $session_data )
}
but it should be like follows to be precise.
SessionHandlerInterface {
/* Methods */
abstract public bool close ( void )
return($ret, is_bool($ret));
abstract public bool destroy ( string $session_id )
require(strlen($session_id) 0)
return($ret, is_bool($ret));
abstract public bool gc ( string $maxlifetime )
require($maxlifetime = 0)
return($ret, is_int($ret) $ret = -1);
abstract public bool open ( string $save_path , string $name )
require(is_string($save_path))
require(is_string($name));
return($ret, is_bool($ret));
abstract public string read ( string $session_id )
require(strlen($session_id) 0)
return($ret, is_bool($ret) || is_string($ret));
abstract public bool write ( string $session_id , string $session_data )
require(is_string($session_id) strlen($session_id) 0)
require(is_string($session_data))
return($ret, is_bool($ret));
}
This definition is more user friendly. There were too many user save
handlers
that do not return proper values because of current interface limitation.
Scalar type and return type hint helps, but it does not cover
return($ret, is_int($ret) $ret = -1);
for example.
If you think this is easy to implement and should be in the RFC, I would
appreciated it
and use it to raise assertion errors just like user class/interface.
BTW, these restrictions are coded as error in current session module and
should
be checked by the module always. It's not mandatory for the RFC, but just
a missing piece.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] Design by Contract
I think we should just repeat the related D semantic.
It must be defined in contracts inheritance rules.
What if we have contracts for prototype method in parent class and
interface?
Should we still validate contracts of parent and interface if we add our
owns?
etc.
Thanks. Dmitry.
On Wed, Feb 11, 2015 at 10:08 AM, Joe Watkins pthre...@pthreads.org wrote:
D has them:
http://dlang.org/interface.html#interface-contracts
Maybe we could allow pre/post contracts but invariants don't make sense on
interfaces.
The question is, do we want to make them always available when possible,
or do we want to make them available where it seems most useful and or
least complex ?
I prefer the latter, everyone else ?
Cheers
Joe
On Wed, Feb 11, 2015 at 7:02 AM, Dmitry Stogov dmi...@zend.com wrote:
I think we can't support contracts on interfaces and abstract methods.
How D works?
Thanks. Dmitry.
On Wed, Feb 11, 2015 at 1:56 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Dmitry and Joe,
On Wed, Feb 11, 2015 at 6:29 AM, Yasuo Ohgaki yohg...@ohgaki.net
wrote:
On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov dmi...@zend.com wrote:
You are welcome to edit https://wiki.php.net/rfc/dbc2
It looks like we have similar views, so just make it better in a way
you think.
Looks good to me. It's much better than original. Thank you folks.
We have related issue like how internal module incorporate with DbC.
However
these could be future issues.
A little more clarification, following interface definition is allowed
or not?
interface Some {
require($this-last_result 1000); // Force classes to have
$this-result
function bar($a, $b)
require($a $b)
return($ret, $ret 1000);
function getLastResult()
return($ret, $this-last_result === $ret);
}
I suppose it is supported, but it may be better to be explicit.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi Adam, On Wed, February 11, 2015 00:53, Adam Harvey wrote: Finally, Anatol's tally was wrong for this one: it was 17:3 for removal. That's a pretty strong indicator by itself. Yeah, my typo, thanks for the correction :) Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design by Contract
Hi Dmitry, On Wed, Feb 11, 2015 at 4:26 PM, Dmitry Stogov dmi...@zend.com wrote: I think we should just repeat the related D semantic. It must be defined in contracts inheritance rules. What if we have contracts for prototype method in parent class and interface? Should we still validate contracts of parent and interface if we add our owns? etc. Both D and Eiffel evaluates all contracts defined in parents/interfaces. Both D and Eiffel has method like invariant definition. They don't inherit explicitly, but inherit implicitly always. That's why I sent strange mail. I read code and misunderstood by mistake. I don't code with D much, but I really like the feature ;) Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC][DISCUSSION] Script only includes
Hi Matteo, On Wed, Feb 11, 2015 at 12:48 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: On Tue, Feb 10, 2015 at 5:22 PM, Matteo Beccati p...@beccati.com wrote: On 10/02/2015 01:52, Yasuo Ohgaki wrote: Some of you are tired with this topic, but please take a look the RFC [RFC] Script only includes - this is 3rd version. https://wiki.php.net/rfc/script_only_include Please let me know what you like or dislike. I understand you goal, but ini settings are *bad*. We need less of them, not more. Developing applications or libraries that are resilient to all possible variants in the ini settings is painful. It's a waste of time for both users and developers trying to provide support. I proposed script()/script_once() at first. Considering new names that might break existing apps, I choose INI. The INI may be removed in the future, if include/require has an option. e.g. require string $filename [, bool $embed_mode_flag]; Would you like me to include this change proposal in the RFC? Even if we have embed_mode_flag, we are better to have the INI option for a while for smooth migration. How about remove 2 INIs in the future with this RFC? script_embed=On/Off (New with this RFC) allow_url_include=On/Off I'll prepare patch that require(_once) string $filename [, int $include_type]; include(_once) string $filename [, int $include_type]; Where $include_type are - PHP_INCLUDE_DEFAULT (default: no embed, no URL) - PHP_INCLUDE_EMBED (allow embed) - PHP_INCLUDE_URL (allow URL) These types are combined like PHP_INCLUDE_EMBED | PHP_INCLUDE_URL. Then, above 2 INIs may be deprecated and remove in the future. How about remove them by PHP 7.3. What do you think? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [VOTE] Scalar Type Hints
On 02/10/2015 07:57 PM, Xinchen Hui wrote:
am I wrong?!
seems I am wrong with this, it's a false alarm... it can restore
automatically.
Yeah, declare() doesn't span files so that isn't a problem.
My worry is still the lack of type coercion for internal calls. I tested
it on some apps and it will take quite a bit of tedious and rather
useless effort to fix these to run in strict mode. Some examples of
common things that are fatal errors in strict mode:
ini_set('precision', 14);
ini_set('display_errors', 1);
ini_set('display_errors', true);
ok, not common, but tan(4/2) fatal, tan(5/2) no error
Wordpress has this function, spot the error:
function add_magic_quotes( $array ) {
foreach ( (array) $array as $k = $v ) {
if ( is_array( $v ) ) {
$array[$k] = add_magic_quotes( $v );
} else {
$array[$k] = addslashes( $v );
}
}
return $array;
}
$v may not always be a string (it died with a float for me), so the
fix is to cast:
$array[$k] = addslashes( (string)$v );
Also from Wordpress:
$formatted = number_format( $number, absint( $decimals ),
$wp_locale-number_format['decimal_point'],
$wp_locale-number_format['thousands_sep'] );
Here number_format() is expecting a float but $number is a string. So
again, the only real fix is to cast.
And in Drupal8 *without turning on strict*:
use Drupal\Component\Utility\String;
it dies with: Fatal error: string cannot be used as a class name in
/var/www/drupal/core/includes/bootstrap.inc on line 11
That String class is everywhere in Drupal. They are going to have a
fun time with that. See
https://gist.githubusercontent.com/anonymous/d9252deeeb2aae1a5af5/raw/053155130d22551b1404d0a9b94e27424544b6d1/gistfile1
From Geeklog:
if (strtolower($topic) != strtolower($archivetid)) {
$sql .= AND ta.tid != '{$archivetid}' ;
}
$topic can be null there. Looking at the logic, not really a bug,
just a natural reliance on null being coerced to
Also from Geeklog:
if( empty( $date )) {
// Date is empty, get current date/time
$stamp = time();
} else if( is_numeric( $date )) {
// This is a timestamp
$stamp = $date;
} else {
// This is a string representation of a date/time
$stamp = strtotime( $date );
}
// Format the date
$date = strftime( $dateformat, $stamp );
strftime() expects an integer for the timestamp there, but as the
above logic shows, they are expecting a numeric string to be fine.
No bug, just another forced cast.
And another number_format() instance where arg1 is not necessarily
a float. Obviously not a bug, so we have to cast again:
return number_format( $number, $dc, $ds, $ts );
In Opencart:
$this-image = imagecreatetruecolor($width, $height);
imagecreatetruecolor() expects parameter 1 to be integer, string
given in /var/www/opencart/system/library/image.php on line 89
You could argue this is a bug, I guess, but the width and height are
coming from a database and are integers in the db, but since the db
returns strings. Another cast...
I was genuinely hoping to find some bugs with this exercise. I suppose
it is because I did it on mature projects and at this stage those sorts
of bugs have already been fixed. But I still fear that people are going
to want to be enable strictness everywhere and then they will quickly
learn that they better cast stuff to be safe which makes the whole thing
rather pointless. And I feel pretty sorry for the Drupal folks. That
list of 1000+ instances of their String class is going to suck to fix.
-Rasmus
signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] Design by Contract
D has them:
http://dlang.org/interface.html#interface-contracts
Maybe we could allow pre/post contracts but invariants don't make sense on
interfaces.
The question is, do we want to make them always available when possible, or
do we want to make them available where it seems most useful and or least
complex ?
I prefer the latter, everyone else ?
Cheers
Joe
On Wed, Feb 11, 2015 at 7:02 AM, Dmitry Stogov dmi...@zend.com wrote:
I think we can't support contracts on interfaces and abstract methods.
How D works?
Thanks. Dmitry.
On Wed, Feb 11, 2015 at 1:56 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Dmitry and Joe,
On Wed, Feb 11, 2015 at 6:29 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov dmi...@zend.com wrote:
You are welcome to edit https://wiki.php.net/rfc/dbc2
It looks like we have similar views, so just make it better in a way
you think.
Looks good to me. It's much better than original. Thank you folks.
We have related issue like how internal module incorporate with DbC.
However
these could be future issues.
A little more clarification, following interface definition is allowed
or not?
interface Some {
require($this-last_result 1000); // Force classes to have
$this-result
function bar($a, $b)
require($a $b)
return($ret, $ret 1000);
function getLastResult()
return($ret, $this-last_result === $ret);
}
I suppose it is supported, but it may be better to be explicit.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] Design by Contract
Hi Stas,
I agree, it may look weird at first, but if you familiar with concept it
looks more or less natural. It's implemented in D, Effiel, it was a
proposal for Java, etc
Anyway, we will have at least 3 competing proposals.
1) contracts in doc-commetns https://wiki.php.net/rfc/dbc
/**
* @requires ($a = 0)
*/
function foo($a) {
}
2) contracts as part of the language https://wiki.php.net/rfc/dbc2
function foo($a)
require($a = 0)
{
}
3) contracts in annotations
requires($a = 0)
function foo($a) {
}
The fact that we are working on (2) now, doesn't mean we will select it as
a final solution. (3) is an interesting option as well.
Thanks. Dmitry.
On Wed, Feb 11, 2015 at 9:56 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
Please steer clear of using the assert API, and in so doing avoid BC
concerns with the current assert API.
The operator can be called something other than assert, I'm sure the
thesaurus has a lot of possibilities.
Please avoid adding a magic method and use the suggested syntax for
invariant.
class Some {
require(invariant-expr);
I think reusing syntax for existing operator in completely unrelated
context is a big mistake. Having code outside of functions is probably
not the best idea too.
--
Stas Malyshev
smalys...@gmail.com
Re: [PHP-DEV] Design by Contract
Hi! Hello, internals! DbC is good thing, but the way you want to do this via language changes is really awful. Why do you want to add more custom features into the Agreed here. I still don't see what's wrong with just putting the code at the beginning of the function and whenever you want to check it. Why this need to change the language syntax? OK, you don't like assert because it's limited or performance-costly or whatever. We can fix that. Why we need weird syntax that places function code in three different places, reuses existing syntax constructs for things that have nothing to do with their original use and look like Perl YAPH signature? I understand implementing fashionable concepts is fun, but must they come with weird syntax? Why can't we keep it simple? -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design by Contract
If there is no technical difficulties, I would like to have it.
Okay then, I'll rethink ...
Cheers
Joe
On Wed, Feb 11, 2015 at 7:12 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Dmitry and Joe,
On Wed, Feb 11, 2015 at 4:02 PM, Dmitry Stogov dmi...@zend.com wrote:
I think we can't support contracts on interfaces and abstract methods.
How D works?
D supports contract in structure and interface. Structure is more like
classes in D, though.
interface I
{
int foo(int i)
in { assert(i 7); }
out (result) { assert(result 1); }
void bar();
}
http://dlang.org/interface.html
Eiffel support contracts for interfaces.
class interface DICTIONARY [ELEMENT] feature
put (x: ELEMENT; key: STRING) is
-- Insert x so that it will be retrievable
-- through key.
require
count = capacity
not key.empty
ensure
has (x)
item (key) = x
count = old count + 1
... Interface specifications of other features ...
invariant
0 = count
count = capacity
end -- class interface DICTIONARY
https://archive.eiffel.com/doc/manuals/technology/contract/
If there is no technical difficulties, I would like to have it.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] [RFC][DISCUSSION] Script only includes
Hi! I proposed script()/script_once() at first. Considering new names that might break existing apps, I choose INI. The problem with script_once is not that it may break existing apps. The problem is that somebody careful enough to use special operator would probably be careful enough not to put $_GET['pleasehackme'] there, and somebody not careful enough to do that won't also use special operator because he probably wouldn't even know why it's needed or whether it exists. -- 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][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi Paul, On Wed, February 11, 2015 00:29, Paul Dragoonis wrote: On Tue, Feb 10, 2015 at 11:14 PM, Kalle Sommer Nielsen ka...@php.net mailto:ka...@php.net wrote: Hi Paul 2015-02-10 23:59 GMT+01:00 Paul Dragoonis dragoo...@gmail.com mailto:dragoo...@gmail.com : Did you accidentally miss out mssql? it resultes in significant resistance to leave core, such as mcrypt and ignoring mathematical numbers, from a practical basis I'd like to see mssql kept in core. Who's with me ? I'd like to see mssql kept as well, only makes more sense as we also have pdo_dblib. I wouldn't mind looking into some fixes to it or porting it once I get my FreeTDS or ntwdblib configuration setup here, as there is a fair bit of cleanup I'd like to do with it. It's common sense that if something receives significant resistance then there's usually a good reason for it and it shouldn't be ignored regardless of how mathematically accurate it may seem to exclude it. Let's keep MSSQL in. you've probably seen that some items was removed from the voting short after it was started. People raised their voices telling they're going to maintain those items. As the goal was not just blindly removing something, but getting rid of unmaintained stuff to better concentrate on the end goal. Now, it is probably no use crying after spilt milk, but the PECL doors are always open anyway. But aside - really huge -1 on what you say about significant resistance and pure math. Either we have and respect the voting process or not. Even if you say it about a misleading typo result. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design by Contract
I didn't get what do you mean by internal module Thanks. Dmitry. On Wed, Feb 11, 2015 at 12:29 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Dmitry and Joe, On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov dmi...@zend.com wrote: You are welcome to edit https://wiki.php.net/rfc/dbc2 It looks like we have similar views, so just make it better in a way you think. Looks good to me. It's much better than original. Thank you folks. We have related issue like how internal module incorporate with DbC. However these could be future issues. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Design by Contract
I didn't get what do you mean by internal module He means extension, builtin classes/functions. Cheers Joe On Wed, Feb 11, 2015 at 7:00 AM, Dmitry Stogov dmi...@zend.com wrote: I didn't get what do you mean by internal module Thanks. Dmitry. On Wed, Feb 11, 2015 at 12:29 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Dmitry and Joe, On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov dmi...@zend.com wrote: You are welcome to edit https://wiki.php.net/rfc/dbc2 It looks like we have similar views, so just make it better in a way you think. Looks good to me. It's much better than original. Thank you folks. We have related issue like how internal module incorporate with DbC. However these could be future issues. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Design by Contract
Hi Dmitry and Joe,
On Wed, Feb 11, 2015 at 4:02 PM, Dmitry Stogov dmi...@zend.com wrote:
I think we can't support contracts on interfaces and abstract methods.
How D works?
D supports contract in structure and interface. Structure is more like
classes in D, though.
interface I
{
int foo(int i)
in { assert(i 7); }
out (result) { assert(result 1); }
void bar();
}
http://dlang.org/interface.html
Eiffel support contracts for interfaces.
class interface DICTIONARY [ELEMENT] feature
put (x: ELEMENT; key: STRING) is
-- Insert x so that it will be retrievable
-- through key.
require
count = capacity
not key.empty
ensure
has (x)
item (key) = x
count = old count + 1
... Interface specifications of other features ...
invariant
0 = count
count = capacity
end -- class interface DICTIONARY
https://archive.eiffel.com/doc/manuals/technology/contract/
If there is no technical difficulties, I would like to have it.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] Design by Contract
I think we should just repeat the related D semantic.
I'm not sure it all fits, some decisions were likely taken because of D's
object model.
I'm going to continue research today and will be updating the RFC, I'll aim
for as close to D as possible then.
Cheers
Joe
On Wed, Feb 11, 2015 at 7:26 AM, Dmitry Stogov dmi...@zend.com wrote:
I think we should just repeat the related D semantic.
It must be defined in contracts inheritance rules.
What if we have contracts for prototype method in parent class and
interface?
Should we still validate contracts of parent and interface if we add our
owns?
etc.
Thanks. Dmitry.
On Wed, Feb 11, 2015 at 10:08 AM, Joe Watkins pthre...@pthreads.org
wrote:
D has them:
http://dlang.org/interface.html#interface-contracts
Maybe we could allow pre/post contracts but invariants don't make sense
on interfaces.
The question is, do we want to make them always available when possible,
or do we want to make them available where it seems most useful and or
least complex ?
I prefer the latter, everyone else ?
Cheers
Joe
On Wed, Feb 11, 2015 at 7:02 AM, Dmitry Stogov dmi...@zend.com wrote:
I think we can't support contracts on interfaces and abstract methods.
How D works?
Thanks. Dmitry.
On Wed, Feb 11, 2015 at 1:56 AM, Yasuo Ohgaki yohg...@ohgaki.net
wrote:
Hi Dmitry and Joe,
On Wed, Feb 11, 2015 at 6:29 AM, Yasuo Ohgaki yohg...@ohgaki.net
wrote:
On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov dmi...@zend.com
wrote:
You are welcome to edit https://wiki.php.net/rfc/dbc2
It looks like we have similar views, so just make it better in a way
you think.
Looks good to me. It's much better than original. Thank you folks.
We have related issue like how internal module incorporate with DbC.
However
these could be future issues.
A little more clarification, following interface definition is allowed
or not?
interface Some {
require($this-last_result 1000); // Force classes to have
$this-result
function bar($a, $b)
require($a $b)
return($ret, $ret 1000);
function getLastResult()
return($ret, $this-last_result === $ret);
}
I suppose it is supported, but it may be better to be explicit.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] Design by Contract
So, I think we have to support them as well.
On Wed, Feb 11, 2015 at 10:12 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Dmitry and Joe,
On Wed, Feb 11, 2015 at 4:02 PM, Dmitry Stogov dmi...@zend.com wrote:
I think we can't support contracts on interfaces and abstract methods.
How D works?
D supports contract in structure and interface. Structure is more like
classes in D, though.
interface I
{
int foo(int i)
in { assert(i 7); }
out (result) { assert(result 1); }
void bar();
}
http://dlang.org/interface.html
Eiffel support contracts for interfaces.
class interface DICTIONARY [ELEMENT] feature
put (x: ELEMENT; key: STRING) is
-- Insert x so that it will be retrievable
-- through key.
require
count = capacity
not key.empty
ensure
has (x)
item (key) = x
count = old count + 1
... Interface specifications of other features ...
invariant
0 = count
count = capacity
end -- class interface DICTIONARY
https://archive.eiffel.com/doc/manuals/technology/contract/
If there is no technical difficulties, I would like to have it.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
On 10 February 2015 at 21:38, David Muir davidkm...@gmail.com wrote: Does this mean PHP will be taking on the role of maintaining libmcrypt as well? That's not what it means, no. If a security issue is found, what is the course of action? Well, what happened when there was vulnerabilities in OpenSSL? I've been thinking quite hard about what we should do with regard to mcrypt. We definitely need a plan to sunset it, but we can't really do that without a readily available replacement. It's understandable if people do not want to use OpenSSL as an alternative. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
On Mon, Feb 9, 2015 at 10:29 PM, Anatol Belski anatol@belski.net wrote: Hi, the voting on the removals in PHP7 in hereby finished. The results are item yes:no sapi/aolserver 32:0 sapi/apache32:0 sapi/apache_hooks 31:0 sapi/apache2filter 23:1 sapi/caudium 30:0 sapi/continuity28:0 sapi/isapi 28:0 sapi/milter10:9 sapi/phttpd26:0 sapi/pi3web24:0 sapi/roxen 23:0 sapi/thttpd25:0 sapi/tux 25:0 sapi/webjames 25:0 ext/imap 14:19 ext/mcrypt 15:18 ext/mssql 17:13 ext/pdo_dblib 4:18 ext/sybase_ct 17:1 As most of the items are considered to be removed, the ones to stay untouched by the 50%+1 requirement are ext/imap ext/mcrypt ext/pdo_dblib Did you accidentally miss out mssql? it resultes in significant resistance to leave core, such as mcrypt and ignoring mathematical numbers, from a practical basis I'd like to see mssql kept in core. Who's with me ? I'm going to implement and tag the changes considered ASAP. Regarding the stuff to considered to be removed from the core - if there are some supporters, the sources will be made available in the git tag. They can be anytime ported to PHP7 and possibly resurrected. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design by Contract
Hi Dmitry and Joe,
On Wed, Feb 11, 2015 at 6:29 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov dmi...@zend.com wrote:
You are welcome to edit https://wiki.php.net/rfc/dbc2
It looks like we have similar views, so just make it better in a way you
think.
Looks good to me. It's much better than original. Thank you folks.
We have related issue like how internal module incorporate with DbC.
However
these could be future issues.
A little more clarification, following interface definition is allowed or
not?
interface Some {
require($this-last_result 1000); // Force classes to have $this-result
function bar($a, $b)
require($a $b)
return($ret, $ret 1000);
function getLastResult()
return($ret, $this-last_result === $ret);
}
I suppose it is supported, but it may be better to be explicit.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi Paul 2015-02-10 23:59 GMT+01:00 Paul Dragoonis dragoo...@gmail.com: Did you accidentally miss out mssql? it resultes in significant resistance to leave core, such as mcrypt and ignoring mathematical numbers, from a practical basis I'd like to see mssql kept in core. Who's with me ? I'd like to see mssql kept as well, only makes more sense as we also have pdo_dblib. I wouldn't mind looking into some fixes to it or porting it once I get my FreeTDS or ntwdblib configuration setup here, as there is a fair bit of cleanup I'd like to do with it. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] uWSGI experimental plugin for implementing a WSGI/PSGI/Rack-like interface for PHP
2015-02-10 14:26 GMT+02:00 Rowan Collins rowan.coll...@gmail.com: Rowan Collins wrote on 09/02/2015 18:24: I just realised the double negative in that sentence may not be easy to understand, so just to make sure it's clear: I do quite like the idea, in general, but think it would require a major rethink of large parts of code. We need only look at PHP 6/Unicode for the risks involved in a well-intentioned feature with far-reaching impact on the language. I also think that an application server model without userland threads would be a mistake, because it would still be difficult to share anything meaningful between requests. That said, if someone wants to start collecting a top-level list of what would need to be changed, and suggesting how it might work, I'd be happy to contribute some ideas. Yes, I understand you correctly, thank you. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Script only includes
Hi Pavel, On Tue, Feb 10, 2015 at 7:06 PM, Pavel Kouřil pajou...@gmail.com wrote: IMHO the real solution to this problem is to educate the programmers how to write safer applications, not by ini settings. We have been tried to educate users already and introduced some mitigations e.g. allow_url_include, open_basedir. However, enough time is passed to prove that wasn't enough, isn't it? PHP (many and these are _only_ few of them in the wild) http://www.exploit-db.com/search/?action=searchfilter_page=1filter_description=PHPfilter_author=filter_platform=0filter_type=0filter_lang_id=0filter_exploit_text=inclusionfilter_port=0filter_osvdb=filter_cve= PERL (0 result) http://www.exploit-db.com/search/?action=searchfilter_page=1filter_description=filter_exploit_text=PERLfilter_author=inclusionfilter_platform=0filter_type=0filter_lang_id=0filter_port=filter_osvdb=filter_cve= Rails (0 result) http://www.exploit-db.com/search/?action=searchfilter_page=1filter_description=Railsfilter_exploit_text=inclusionfilter_author=filter_platform=0filter_type=0filter_lang_id=0filter_port=filter_osvdb=filter_cve= Python (0 result) http://www.exploit-db.com/search/?action=searchfilter_page=1filter_description=Pythonfilter_exploit_text=inclusionfilter_author=filter_platform=0filter_type=0filter_lang_id=0filter_port=filter_osvdb=filter_cve= JSP (1 result - This is famous) http://www.exploit-db.com/search/?action=searchfilter_page=1filter_description=JSPfilter_exploit_text=inclusionfilter_author=filter_platform=0filter_type=0filter_lang_id=0filter_port=filter_osvdb=filter_cve= The picture is clear. I value education as one of the most important security measure indeed. However, education is not perfect. If there is effective counter measure, it is better to be adopted. We can write web apps by PHP, not only because it's faster to write, but easier to write secure code. We removed script embedding from regex functions, why not include? My new proposal is simple and does not require performance penalty. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] new json, push generated file?
Hi Anatol, On Tue, Feb 10, 2015 at 12:24 PM, Anatol Belski anatol@belski.net wrote: It's actually so that there is a range of tool versions supported. That means any version within the range should be valid for use. If another range of versions is defined, so it's obviously to follow it. It's good to make thoughts about the new features, but that'll be probably require updating the guidelines and changing the valid versions range. First of all it's great that you are adding the the type and cross platform fixes into json. I understand why you needed to regenerate the file. As you say there is a supported range. The problem is that the range is too high which is very limiting for adding new features at the moment. What I don't want to do is to force all users compile the new tool version from source because distros are still outdated . There also is no need to require the new version for the whole PHP if it's needed just for json generation. As I said in the PR. This change won't affect anyone who doesn't change json scanner and parser which is 99% of all users that build PHP. The 1% is probably just me so it's not really complicated IMHO... I would also like to add all of this to the json README (it's very outdated and I plan to update it anyway) and possibly other build doc if we have any. Yeah, so why don't just push file and have it done? ATM there might be some fixes needed, so regeneration required. Later on it's supposed to be a very rare case - just in case of bugs or new development. Btw also people who don't have a required re2c/bison/etc version for whatever reasons would still be able to compile, test or develop other parts. That's not actually completely true on linux. At least not on my platform. I can recreate this on my system when I do following: 1. install a different version of re2c then the one Zend/zend_language_scanner.c (e.g. 0.13.6) 2. git checkout master 3. ./configure ... make 4. checkout PHP-5.6 5. checkout master 6. make 7. git status ( it shows Zend/zend_language_scanner.c as regenerated using 0.13.6 ) The fact that I checked out the 5.6 [4] (it doesn't have to be just 5.6 but some other branch with more changes) and then back master [5] caused regeneration zend_language_scanner.c in [6]. The point is that as soon as you start changing branches often, it gets regenerated even if you don't change it. And then you need to have the required version because otherwise the build fails. I want to prevent that for json generated files. This would be especially visible for bison where the version differs more between users compare to re2c where the most users are on 0.13.5. That's exactly what the PR (config.m4 changes) does. Cheers Jakub
Re: [PHP-DEV] Design by Contract
2015-02-10 15:10 GMT+03:00 Alexander Lisachenko lisachenko...@gmail.com: I would like to see a language with good extension API. For now, it's almost impossible to extend a parser, even from extension level (however, PHP7 will have a hook for that, thanks God). To understand how it can be implemented, just read about Checker Framework (Java) http://types.cs.washington.edu/checker-framework/ ...The Checker Framework enhances Java’s type system to make it more powerful and useful. This lets software developers detect and prevent errors in their Java programs. The Checker Framework includes compiler plug-ins (checkers) that find bugs or verify their absence. It also permits you to write your own compiler plug-ins... This is built on top of reflection+annotation+parser extension. Why not to implement this for PHP? From my point of view, this is just an additional feature, that can be used by limited number of developers.
Re: [PHP-DEV] uWSGI experimental plugin for implementing a WSGI/PSGI/Rack-like interface for PHP
Rowan Collins wrote on 09/02/2015 18:24: S.A.N wrote on 09/02/2015 17:40: 2015-02-09 12:41 GMT+02:00 Rowan Collins rowan.coll...@gmail.com: Yes, I can see it working well for specialised uses - you can simply not use those aspects of the language that don't make sense. But for it to be a mainstream part of the language, it needs to play nicely with other parts of the language, and that's where I see it being a complex and painful change. The fact that the lack of native application server for PHP is often the reason for leaving the PHP developers to other languages and technologies. Let's see what others have in 2015: Python - WSGI Ruby - Rack Perl - PSGI JavaScript - JSGI Hack - HHVM PHP - No native application server in core. What discusses the PHP community? Remove or not to remove the PHP4 constructors and many other issues that do not add competitive ability PHP... I personally do not blame you :), just expressing his opinion developer who wants to use PHP and can use modern app server in core PHP. The sentence you're replying to there is talking about existing implementations, on top of current PHP, with all the limitations that implies. My view on the general idea of changing the language so that eventually an event-based model could be the norm, is in an earlier reply: Not that I don't like the idea, but it's a huge project, with potential for profoundly affecting the language. I just realised the double negative in that sentence may not be easy to understand, so just to make sure it's clear: I do quite like the idea, in general, but think it would require a major rethink of large parts of code. We need only look at PHP 6/Unicode for the risks involved in a well-intentioned feature with far-reaching impact on the language. I also think that an application server model without userland threads would be a mistake, because it would still be difficult to share anything meaningful between requests. That said, if someone wants to start collecting a top-level list of what would need to be changed, and suggesting how it might work, I'd be happy to contribute some ideas. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design by Contract
2015-02-10 15:20 GMT+03:00 Dmitry Stogov dmi...@zend.com: I thought about this way, and you are welcome to start composing another RFC. it makes sense and has its advantages. Unfortunately, it relays on many unavailable features that has to be designed as well (annotations, AST manipulation, opcode manipulation), but may be this is a right road. Thanks, Dmitry! Your position is clearly highlight my vision, it's not so easy, but maybe it will bring us much more profit at the end. 2015-02-10 15:20 GMT+03:00 Dmitry Stogov dmi...@zend.com: D and Effiel approach may work as well, but if you like another (annotation based) approach - be involved into development. At first we'll need 3-rd RFC that defines all the things that must be implemented. I may help, with RFC, design and implementation. Thanks, your help is really appreciated ) I'l try to start another one RFC about this API, let's have a look what can be done.
Re: [PHP-DEV] Design by Contract
2015-02-10 15:35 GMT+03:00 Pavel Kouřil pajou...@gmail.com: Hello, maybe you could try to consult your ideas with Ivan Enderlin. He mentioned in previous emails (for instance http://news.php.net/php.internals/82245) that he would prefer some AOP/hook-based approach to DbC as well, so it may be compatible with your mindset. Yes, I know about Praspel, it's quite a good implementation, but for specific case. My implementation of DbC is built on top of AOP and can be described with only one (!) aspect and few annotations. If you are interested in it, you could look across wiki https://github.com/lisachenko/php-deal/wiki or even open an aspect class itself https://github.com/lisachenko/php-deal/blob/master/src/PhpDeal/Aspect/ContractCheckerAspect.php to see an advices that will be triggered as custom hooks before/after or around original method invocations. I think, that AOP-based solution is pretty nice: it's only for development mode. Annotations are not parsed for production mode and looks like a good documentation, this can be improved later with BDD (Gherkin) to define a contracts in human-readable format. @Contract\Verify(Given $amount is positive) @Contract\Ensure(Result is changed from $old to $old+$amount) So, it can be a good idea to discuss this topic with Ivan Enderlin. Maybe he can help me with RFC too.
Re: [PHP-DEV] Design by Contract
Hi Alexander,
On Tue, Feb 10, 2015 at 2:44 PM, Alexander Lisachenko
lisachenko...@gmail.com wrote:
Hello, internals!
DbC is good thing, but the way you want to do this via language changes is
really awful. Why do you want to add more custom features into the
language, instead of providing an API to extend it in a more natural way by
framework developers?
First of all, I know that you have something working, so your opinion and
suggestions are important for us.
I already told that currently we are in a brainstorming phase
We already have two drafts:
https://wiki.php.net/rfc/dbc(doc-comment based)
https://wiki.php.net/rfc/dbc2 (inspired by D language)
both have their pros and cons.
Many existing implementation of DbC is just kind of bytecode compilers and
IDE tools. Main idea of DbC is to help developer with writing a better code
without errors. But then, during compiling (production mode) all checks
will be removed.
this should be implemented with zero-cost assert proposed long time ago
https://wiki.php.net/rfc/expectations
Am I one who think that this code is looking weird?
public function destroy($id)
require(strlen($id) 10)
return(is_bool($))
{
@unlink($this-path . $id);
}
For me it's quite readable.
This part of code is breaks block structure of function, adding custom
part of code, which is not related to the function logic itself.
Instead of doing this weird syntax only for personal fun, just think
about more general usages of parser and assertions.
As you know, I'm working with aspect-oriented programming in PHP and
have a library for that. And it wasn't easy to implement it, because
there is no API for that from PHP. This techniques can be also used
for DbC as well.
So, my suggestion is to drop current rfc and start more general one,
called PHP Language Extension API, which will include an API for
defining metadata and API for opcode manipulation. Compare previous
example with another one with plain metadata:
[Require = strlen($id) 10)]
[Return = is_bool($__result))
public function destroy($id)
{
@unlink($this-path . $id);
}
for me it's less readable, but this is a general solution that may be
reused for other features. So, it's interesting.
This code then will be parsed and PHP hooks that were registered by
register_parser_extension() will be called and extension will
produce a valid opcodes for that for method destroy(), by modifying
AST-node.
I thought about this way, and you are welcome to start composing another
RFC. it makes sense and has its advantages.
Unfortunately, it relays on many unavailable features that has to be
designed as well (annotations, AST manipulation, opcode manipulation), but
may be this is a right road.
This way is much elegant and can be reused later for many features,
like Design By Contracts, native SQL support syntax in PHP (LINQ),
Aspect-Oriented Programming, hooks and much more.
Just stop to create custom features in the engine itself and give this
work for framework and PHP-extension developers.
D and Effiel approach may work as well, but if you like another (annotation
based) approach - be involved into development.
At first we'll need 3-rd RFC that defines all the things that must be
implemented.
I may help, with RFC, design and implementation.
Thanks. Dmitry.
2015-02-10 13:32 GMT+03:00 Lester Caine les...@lsces.co.uk:
On 09/02/15 23:47, Yasuo Ohgaki wrote:
The RFC draft is ready.
https://wiki.php.net/rfc/dbc2
These contracts are evaluated development time only. Therefore, there
is
no performance penalty with DbC.
Sorry but that makes no sense to me at all. If this is something only to
use with an IDE then why does it have to have anything that is visible
at 'run time'? This seems to be going down the track of we will be
compiling this eventually and that is just not what PHP *IS* about.
These are more hints, but assume that at runtime what they define is not
relevant?
ALL of this discussion on type hinting how ever it is handled is simply
sidestepping the major plus on PHP with associative arrays. I see no
point expanding every database record read to 'magic access functions'
for multiple variables and it *IS* the scalar values stored in these
arrays that needs the 'hint/constraint' control.
I am getting even more confused about just what all the different
factions are trying to achieve. Yes I know I can totally ignore all of
it, but with my current tools losing traction because of all the 'better
ways of working' what in my opinion IS the best way to allow different
factions to add their own pet style is drowning simple clean solutions
such as docblock.
--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve -
Re: [PHP-DEV] new json, push generated file?
Hi Jakub, On Tue, February 10, 2015 12:56, Jakub Zelenka wrote: Hey On Tue, Feb 10, 2015 at 2:47 AM, Xinchen Hui larue...@php.net wrote: why make this thing in this way complicated? why not just simply include the generated files as others did? First of all the others did exactly what I have already done. :) It means they included re2c generated files and did not include bison generated files. There are few reasons why I would like to do it slightly differently in json and make the re-generation optional. 1. I want to prevent an accidental re-generation of files with the old version of re2c and bison. It happens to me from time to time when I switch branches and build often. Then I see that I have changes (git diff) in the zend_language_scanner.c and other re2c generated files even if I haven't edited them. The reason is because the version that I use is different and the files got regenerated (you won't see that if you use the same version). That could be even bigger problem with bison where the the version differences are much more often. 2. As soon as I start using new features (like utf8 ranges in re2c) that are not available in the old version and someone would try to do some changes in the scanner and regenerate it, then it would fail with error. I believe that it's better if the user gets a warning during the configuration and the compilation exits the build instead of generating an error. 3 It is sort of a signal which version is currently supported and it hopefully prevents things like regenerating files with the old version and pushing it to the repo (as Anatol did yesterday in https://github.com/php/php-src/commit/89893541305594eba373c15156eb54d7a7c b5960 ). It's actually so that there is a range of tool versions supported. That means any version within the range should be valid for use. If another range of versions is defined, so it's obviously to follow it. It's good to make thoughts about the new features, but that'll be probably require updating the guidelines and changing the valid versions range. As I said in the PR. This change won't affect anyone who doesn't change json scanner and parser which is 99% of all users that build PHP. The 1% is probably just me so it's not really complicated IMHO... I would also like to add all of this to the json README (it's very outdated and I plan to update it anyway) and possibly other build doc if we have any. Yeah, so why don't just push file and have it done? ATM there might be some fixes needed, so regeneration required. Later on it's supposed to be a very rare case - just in case of bugs or new development. Btw also people who don't have a required re2c/bison/etc version for whatever reasons would still be able to compile, test or develop other parts. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design by Contract
On Tue, Feb 10, 2015 at 1:30 PM, Alexander Lisachenko lisachenko...@gmail.com wrote: 2015-02-10 15:20 GMT+03:00 Dmitry Stogov dmi...@zend.com: I thought about this way, and you are welcome to start composing another RFC. it makes sense and has its advantages. Unfortunately, it relays on many unavailable features that has to be designed as well (annotations, AST manipulation, opcode manipulation), but may be this is a right road. Thanks, Dmitry! Your position is clearly highlight my vision, it's not so easy, but maybe it will bring us much more profit at the end. 2015-02-10 15:20 GMT+03:00 Dmitry Stogov dmi...@zend.com: D and Effiel approach may work as well, but if you like another (annotation based) approach - be involved into development. At first we'll need 3-rd RFC that defines all the things that must be implemented. I may help, with RFC, design and implementation. Thanks, your help is really appreciated ) I'l try to start another one RFC about this API, let's have a look what can be done. Hello, maybe you could try to consult your ideas with Ivan Enderlin. He mentioned in previous emails (for instance http://news.php.net/php.internals/82245) that he would prefer some AOP/hook-based approach to DbC as well, so it may be compatible with your mindset. Regards Pavel Kouril -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
On 10 February 2015 at 23:29, Paul Dragoonis dragoo...@gmail.com wrote: It's common sense that if something receives significant resistance then there's usually a good reason for it and it shouldn't be ignored regardless of how mathematically accurate it may seem to exclude it. Let's keep MSSQL in. https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts#extmssql Where is the significant resistance? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
On 11 February 2015 at 06:59, Paul Dragoonis dragoo...@gmail.com wrote: On Mon, Feb 9, 2015 at 10:29 PM, Anatol Belski anatol@belski.net wrote: ext/mssql 17:13 Did you accidentally miss out mssql? it resultes in significant resistance to leave core, such as mcrypt and ignoring mathematical numbers, from a practical basis I'd like to see mssql kept in core. Who's with me ? Since it's apparently my week for this, I'll provide the case for the defence (or why I voted for removal, anyway): - The API is awful in the exact same ways the ext/mysql API was awful — it makes it far harder to write secure code than it should be. - Actually, it's worse than that, because there's no charset-aware escaping function at all: the only option is addslashes(), which has interesting security implications if you're using certain charsets. - It's buggy. Some of the bugs are due to the underlying library (which is mostly dead); some are in our code, but there are some fundamental issues — basic data types (nvarchar(128), for example) aren't supported, field names are truncated, stored procedure calls are problematic, and probably many more things that I've forgotten. - The bugs probably aren't going to be fixed. ext/mssql averages about one to two non-whitespace, non-copyright-year-increment commits a year. A cursory look at the bug tracker (or my ##php logs) will tell you that it's not because it's stable and free of bugs. - There are multiple better options: using ODBC is almost always more stable, and while PDO_dblib has some of the same problems due to FreeTDS, at least you're using PDO's better (by which I mostly mean harder to misuse) API. In my mind, this is analogous to removing ext/mysql: it's the right thing to do for our users because it promotes better practices and gets rid of an extension that has even more technical issues than that one did. Finally, Anatol's tally was wrong for this one: it was 17:3 for removal. That's a pretty strong indicator by itself. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Script only includes
Hi Markus, On Tue, Feb 10, 2015 at 5:59 PM, Markus Fischer mar...@fischer.name wrote: What constitutes first token in this context? Would this be detected as a PHP file? -8 root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin bin:x:2:2:bin:/bin:/usr/sbin/nologin ?php phpinfo(); -8 Yes. Since we have custom script loader, file content cannot be used for pure PHP script detection. However, parser can detect if it's a pure PHP script. i.e. Detect ?php token at first, no ? in the file. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
On Tue, Feb 10, 2015 at 11:36 PM, Leigh lei...@gmail.com wrote: On 10 February 2015 at 23:29, Paul Dragoonis dragoo...@gmail.com wrote: It's common sense that if something receives significant resistance then there's usually a good reason for it and it shouldn't be ignored regardless of how mathematically accurate it may seem to exclude it. Let's keep MSSQL in. https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts#extmssql Where is the significant resistance? The original email said 17:13 i.e: I guess the mail was wrong then.
