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

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 A

Re: [PHP-DEV] Design by Contract

Hi Dmitry, On Wed, Feb 11, 2015 at 4:26 PM, Dmitry Stogov 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 o

Re: [PHP-DEV] [VOTE] Scalar Type Hints

On Wed, Feb 11, 2015 at 7:36 AM, Rasmus Lerdorf 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 lac

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 > wrote: > > > > Hi Paul > > > 2015-02-10 23:59 GMT+01:00 Paul Dragoonis >: > >> >> Did you accidentally miss out mssq

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

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 wrote: > Hi Dmitry and Joe, > > On Wed, Feb 11, 2015 at 4:02 PM, Dmitry Stogov wrote: > >> I think we can't support contracts on interfaces and abstract methods. >> How D works? > > > D supports contract

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 prote

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 wrote: > Hi! > > > Hello, internals!

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 1

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 Maili

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 t

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" >> > wrote: > >> >> Hi, >> >> >> the voting on the removals in PHP7 in hereby finished. The results are >> >> >> item yes:no >> >> sapi/aolserver 32:0 sapi/apac

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" >> > wrote: > >> >> Hi, >> >> >> the voting on the removals in PHP7 in hereby finished. The results are >> >> >> item yes:no >> >> sapi/aolserver 32:0 sapi/apac

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 /** * @req

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 wrote: > Hi Dmitry and Joe, > > On Wed, Feb 11, 2015 at 4:02 PM, Dmitry Stogov wrote: > >> I think we can't support contracts on interfaces an

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 exte

Re: [PHP-DEV] Design by Contract

Hi Dmitry and Joe, On Wed, Feb 11, 2015 at 4:02 PM, Dmitry Stogov 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

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,

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 l

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 relate

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 wan

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 wrote: > Hi Dmitry and Joe, > > On Wed, Feb 11, 2015 at 6:29 AM, Yasuo Ohgaki wrote: > >> On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov wrote: >>

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 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 wr

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 wrote: > Hi Dmitry and Joe, > > On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov wrote: > >> You are welcome to edit https://wiki.php.net/rfc/dbc2 >> It looks like we have similar v

Re: [PHP-DEV] Design by Contract

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 >

Re: [PHP-DEV] Annotated PHP 5->7 extension diff

Hi Xinchen, On Wed, Feb 11, 2015 at 3:27 PM, Xinchen Hui wrote: > 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, > I think so. I'll start working :) Regards, -- Yasuo Ohgaki yohg.

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

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

Re: [PHP-DEV] Annotated PHP 5->7 extension diff

Hey: On Wed, Feb 11, 2015 at 2:07 PM, Yasuo Ohgaki wrote: > Hi all, > > On Fri, Feb 6, 2015 at 10:38 AM, Yasuo Ohgaki wrote: > >> It looks like this: >>> >>> https://gist.github.com/anonymous/15cbc9947edb4f0a71fd >>> >> >> It uses session save handler uses PS_MOD() which is legacy. >> I may he

Re: [PHP-DEV] Annotated PHP 5->7 extension diff

Hi all, On Fri, Feb 6, 2015 at 10:38 AM, Yasuo Ohgaki 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

Re: [PHP-DEV] [RFC][DISCUSSION] Script only includes

Hi Matteo, On Wed, Feb 11, 2015 at 12:48 PM, Yasuo Ohgaki wrote: > On Tue, Feb 10, 2015 at 5:22 PM, Matteo Beccati 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 v

Re: [PHP-DEV] [RFC][DISCUSSION] Script only includes

Hi Pierre, On Tue, Feb 10, 2015 at 6:19 PM, Pierre Joye wrote: > On Tue, Feb 10, 2015 at 7:52 AM, Yasuo Ohgaki 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/

Re: [PHP-DEV] [VOTE] Scalar Type Hints

Hey: On Wed, Feb 11, 2015 at 11:45 AM, Xinchen Hui wrote: > Hey: > > On Wed, Feb 11, 2015 at 11:36 AM, Xinchen Hui wrote: >> Hey: >> >> >> On Fri, Feb 6, 2015 at 4:14 AM, Andrea Faulds wrote: >>> Good evening, >>> >>> At long last, I’m going to put the RFC to a vote. It’s been long enough - I

Re: [PHP-DEV] [RFC][DISCUSSION] Script only includes

Hi Matteo, On Tue, Feb 10, 2015 at 5:22 PM, Matteo Beccati 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 >> >> Pl

Re: [PHP-DEV] [VOTE] Scalar Type Hints

Hey: On Wed, Feb 11, 2015 at 11:36 AM, Xinchen Hui wrote: > Hey: > > > On Fri, Feb 6, 2015 at 4:14 AM, Andrea Faulds 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. >

Re: [PHP-DEV] [VOTE] Scalar Type Hints

Hey: On Fri, Feb 6, 2015 at 4:14 AM, Andrea Faulds 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 full

Re: [PHP-DEV] Design by Contract

Hi Dmitry and Joe, On Wed, Feb 11, 2015 at 6:29 AM, Yasuo Ohgaki wrote: > On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov 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 m

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 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 wrote: > >> https://wiki.php.net/phpng-upgrading > [sni

Re: [PHP-DEV] [RFC][DISCUSSION] Script only includes

Hi Christoph, On Wed, Feb 11, 2015 at 10:45 AM, Christoph Becker 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 th

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.

Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions

Hi Adam, On Wed, Feb 11, 2015 at 8:53 AM, Adam Harvey wrote: > - 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. > I suppose you know ver

Re: [PHP-DEV] [RFC][DISCUSSION] Script only includes

Hi Pavel, On Tue, Feb 10, 2015 at 7:06 PM, Pavel Kouřil 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, ope

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 wrote: > On 10 February 2015 at 23:29, Paul Dragoonis 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 i

Re: [PHP-DEV] [RFC][DISCUSSION] Script only includes

Hi Markus, On Tue, Feb 10, 2015 at 5:59 PM, Markus Fischer 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

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 wrote: > On Mon, Feb 9, 2015 at 10:29 PM, Anatol Belski > 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 >

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 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://w

Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions

On Tue, Feb 10, 2015 at 11:14 PM, Kalle Sommer Nielsen wrote: > Hi Paul > > 2015-02-10 23:59 GMT+01:00 Paul Dragoonis : > > > > Did you accidentally miss out mssql? it resultes in significant > resistance > > to leave core, such as mcrypt and ignoring mathematical numbers, from a > > practical ba

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 : > > 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

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 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 > sa

Re: [PHP-DEV] Design by Contract

Hi Dmitry and Joe, On Wed, Feb 11, 2015 at 6:29 AM, Yasuo Ohgaki wrote: > On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov 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 m

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 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 b

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 wrote: > >> On 10 Feb 2015, at 9:29 am, "Anatol Belski" >wrote: >> >> Hi, >> >> the voting on the removals in PHP7 in hereby finished. The results >are >> >> >> item yes:no >> >> sapi/aolserver 32:0 >> sapi/apache

Re: [PHP-DEV] Design by Contract

Hi Dmitry and Joe, On Wed, Feb 11, 2015 at 6:29 AM, Yasuo Ohgaki wrote: > On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov 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 m

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" 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:

Re: [PHP-DEV] Design by Contract

Hi Dmitry and Joe, On Tue, Feb 10, 2015 at 8:53 PM, Dmitry Stogov 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 relat

Re: [PHP-DEV] Design by Contract

Hi Yasuo, Le Tue, 10 Feb 2015 07:25:00 +0100, Yasuo Ohgaki 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

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 o

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 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 a

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 lik

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 u

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 wrote: >> Hey, >> >>> On 4 Feb 2015, at 17:10, Crypto Compress >>> wrote: >>> I would go with Http\ >>> >>> Why not the reserved Php\Http\? >> >> This sounds good to me. php\ is already reserved, and i

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 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

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 php

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 > 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

[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_RESOURC

Re: [PHP-DEV] new json, push generated file?

Hi Anatol, On Tue, Feb 10, 2015 at 12:24 PM, Anatol Belski 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 > mak

Re: [PHP-DEV] Design by Contract

2015-02-10 15:35 GMT+03:00 Pavel Kouřil : > 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 compatibl

Re: [PHP-DEV] Design by Contract

On Tue, Feb 10, 2015 at 1:30 PM, Alexander Lisachenko wrote: > 2015-02-10 15:20 GMT+03:00 Dmitry Stogov : > >> 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 t

Re: [PHP-DEV] Design by Contract

2015-02-10 15:20 GMT+03:00 Dmitry Stogov : > 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 manip

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 : 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 langu

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 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 h

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 prov

Re: [PHP-DEV] Design by Contract

2015-02-10 15:10 GMT+03:00 Alexander Lisachenko : > 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

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors Update

On Sat, Feb 7, 2015 at 2:32 PM, Matteo Beccati 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 en

Re: [PHP-DEV] Design by Contract

2015-02-10 14:56 GMT+03:00 Patrick Schaaf : > 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

Re: [PHP-DEV] new json, push generated file?

Hey On Tue, Feb 10, 2015 at 2:47 AM, Xinchen Hui 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 incl

Re: [PHP-DEV] Design by Contract

Am 10.02.2015 12:45 schrieb "Alexander Lisachenko" : > > 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 develope

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 wrote: > I'm happy to clean up the RFC after Dmitry's changes are merged. > > Happy to aut

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

Re: [PHP-DEV] Design by Contract

Hi Joe, On Tue, Feb 10, 2015 at 4:40 PM, Joe Watkins 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

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

Re: [PHP-DEV] Design by Contract

> may be something similar to Smaltalk block syntax: return(, [, ]) 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 wrote: > D uses block syntax: > > ensure(ret) { > } > > In this case, passing 'ret' as a 'parame

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 d

Re: [PHP-DEV] [VOTE] Scalar Type Hints

On Tue, Feb 10, 2015 at 4:56 PM, Dmitry Stogov 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% differen

Re: [PHP-DEV] [RFC][DISCUSSION] Script only includes

On Tue, Feb 10, 2015 at 1:52 AM, Yasuo Ohgaki 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 y

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 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 sup

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

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 a

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 c

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 wrote: > Am 10.02.2015 09:29 schrieb "Dmitry Stogov" : > > > > I cnahged $> into $ret, because $> just won't work. Some better solution > is welcome. > > Also think $> would be awful. Don't like $re

Re: [PHP-DEV] Design by Contract

Am 10.02.2015 09:29 schrieb "Dmitry Stogov" : > > 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 exp

Re: [PHP-DEV] [RFC][DISCUSSION] Script only includes

On Tue, Feb 10, 2015 at 7:52 AM, Yasuo Ohgaki 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 bef

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 wor

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 wrote: > A bit updated version of RFC is attached. > As I removed more than added, I decided not to pu

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

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 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

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