Re: [PHP-DEV] Re: [RFC] Support internal function return types

merged into master with the proposed changes. Thanks. Dmitry. On Thu, Feb 5, 2015 at 9:37 AM, reeze wrote: > Hi Dmitry, > > On 5 February 2015 at 14:31, Dmitry Stogov wrote: > >> Hi reeze, >> >> The original "return type" patch was designed to support internal >> functions as well. >> So I thi

Re: [PHP-DEV] Re: [RFC] Support internal function return types

Thanks a lot! On 5 February 2015 at 16:03, Dmitry Stogov wrote: > merged into master with the proposed changes. > > Thanks. Dmitry. > > On Thu, Feb 5, 2015 at 9:37 AM, reeze wrote: > >> Hi Dmitry, >> >> On 5 February 2015 at 14:31, Dmitry Stogov wrote: >> >>> Hi reeze, >>> >>> The original "re

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

Hi Stas! On 05/02/15 00:43, Stanislav Malyshev wrote: > Hi! > >> Points explicitely marked for discussion in the RFC itself: >> >> * pecl/propro >> Proxies for properties representing state in internal C structs >> https://wiki.php.net/rfc/pecl_http#peclpropro >> >> * pecl/raphf >> (Persist

Re: [PHP-DEV] Re: [RFC] Support internal function return types

On 05/02/15 09:05, reeze wrote: > Thanks a lot! > > On 5 February 2015 at 16:03, Dmitry Stogov wrote: > >> merged into master with the proposed changes. >> >> Thanks. Dmitry. Awesome, thank you! -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

Hi! > think raphf is far more of practical use. Why should HTTP, or even more > HTTPS or HTTP2, be any different than another service, especially when Which "another service"? > HTTP APIs are so common nowadays. HTTP APIs are common, but almost none of them ever require persistent connections.

Re: [PHP-DEV] Re: [RFC][DISCUSSION] script() and script_once()

On 5 February 2015 at 05:37, Adam Harvey wrote: > I'm not totally clear on what this RFC is proposing, honestly. Is the > new script statement meant to only include files that are entirely > wrapped in tags? Are files included that way assumed to > be PHP and don't require tags? Something else?

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

Hi Stas! On 05/02/15 09:30, Stanislav Malyshev wrote: > Hi! > >> think raphf is far more of practical use. Why should HTTP, or even more >> HTTPS or HTTP2, be any different than another service, especially when > > Which "another service"? Databases (see my pecl/pq example in the RFC), key/valu

Re: [PHP-DEV] What do we need strict scalar type hints for?

On Thu, Feb 5, 2015 at 2:22 PM, Stanislav Malyshev wrote: > Hi! > >> True, but obviously, us who want strict typehints want to be able to do this: > > Obviously, but it doesn't mean whole language should be changed to serve > one use case, especially the one that goes contrary to what happened in

[PHP-DEV] [RFC] [VOTE] Fix "foreach" behavior

Hi, The RFC is turned into voting https://wiki.php.net/rfc/php7_foreach#proposed_voting_choices Thanks. Dmitry.

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

Hi! > Databases (see my pecl/pq example in the RFC), key/value stores, message > queues, whatever you can think of. HTTP and databases are principally different. HTTP protocol is stateless message-oriented protocol, and database connection protocols have very little in common with HTTP. > To dem

Re: [PHP-DEV] [RFC][DISCUSSION] script() and script_once()

> > I do not see any appealing reason to add yet another set of include > function/ops, even less for ini settings. > > My reasoning is simple. Nothing we can do will prevent one or the > other to shoot himself in each knees, many times. > > While trying to protect them to do include $foo where $fo

RE: [PHP-DEV] What do we need strict scalar type hints for?

> De : Stanislav Malyshev [mailto:smalys...@gmail.com] > > Adding another concept, not changing the existing ones. And really, > > it's just simplifying what is already present via is_() > > runtime checks, making our lives a little bit easier. > > There's a very big difference between allowing to

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

Hi Stas! On 05/02/15 09:30, Stanislav Malyshev wrote: >> The sole code change would be removing the check for POST, i.e. >> `!strcasecmp(SG(request_method),"POST")` so that actually any request >> method with a recognized content-type (i.e. application/form-data or >> application/x-www-form-urlen

Re: [PHP-DEV] What do we need strict scalar type hints for?

Hi! > However I feel like the fact that it only affects your app (even if > you use a library relying on strictness) if you want to is not clear > for everyone replying here. Is this point clear for you? I was addressing the idea that every scalar type mention should be strict. If it is a choice,

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

Hi! > Yes, I mean $_POST (and $_FILES). It's been requested multiple times, > but I know it's quite controversial. I think this approach is better > than any other proposed yet (think $_PUT and stuff). You're building an OO next-generation API, why you still need $_PUT or $_FILES or anything like

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

On 05/02/15 09:53, Stanislav Malyshev wrote: > Hi! > >> Databases (see my pecl/pq example in the RFC), key/value stores, message >> queues, whatever you can think of. > > HTTP and databases are principally different. HTTP protocol is stateless > message-oriented protocol, and database connection

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

On 05/02/15 10:03, Stanislav Malyshev wrote: > Hi! > >> Yes, I mean $_POST (and $_FILES). It's been requested multiple times, >> but I know it's quite controversial. I think this approach is better >> than any other proposed yet (think $_PUT and stuff). > > You're building an OO next-generation A

RE: [PHP-DEV] Re: [RFC][DISCUSSION] script() and script_once()

> De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki > How about alternative way that turn 'require' into non embedded mode by INI > switch? A big NO for me, as I am using 'include/require' in a lot of programs to include template files containing mixed text/php content

Re: [PHP-DEV] [RFC][DISCUSSION] script() and script_once()

On 05/02/15 02:53, Yasuo Ohgaki wrote: > Hi all, > > I would like to discuss my "must have it in PHP 7" item. > > PHP RFC: script() and script_once() > https://wiki.php.net/rfc/script_and_script_once > Forget about the INI setting. I think the perfect fit for that feature would be import{,_once

Re: [PHP-DEV] What do we need strict scalar type hints for?

Hi, On Thu, Feb 5, 2015 at 9:22 AM, Stanislav Malyshev wrote: > Hi! > >> True, but obviously, us who want strict typehints want to be able to do this: > > Obviously, but it doesn't mean whole language should be changed to serve > one use case, especially the one that goes contrary to what happene

Re: [PHP-DEV] What do we need strict scalar type hints for?

On Thu, Feb 5, 2015 at 9:59 AM, Stanislav Malyshev wrote: > Hi! > >> However I feel like the fact that it only affects your app (even if >> you use a library relying on strictness) if you want to is not clear >> for everyone replying here. Is this point clear for you? > > I was addressing the idea

Re: [PHP-DEV] [RFC] Big Integer Support

I agree with Andrea's points , also GMP is also used in ruby 2.1 with good results https://bugs.ruby-lang.org/issues/8796 ps: LibTomMath seems to be used in firebird also On Tue, Feb 3, 2015 at 4:03 PM, Andrea Faulds wrote: > Hi Lester, > > > On 3 Feb 2015, at 08:56, Lester Caine wrote: > > >

Re: [PHP-DEV] Re: [RFC][DISCUSSION] script() and script_once()

Hi Leigh, On Thu, Feb 5, 2015 at 5:31 PM, Leigh wrote: > On 5 February 2015 at 05:37, Adam Harvey wrote: > > I'm not totally clear on what this RFC is proposing, honestly. Is the > > new script statement meant to only include files that are entirely > > wrapped in tags? Are files included that

Re: [PHP-DEV] Re: [RFC][DISCUSSION] script() and script_once()

On Thu, Feb 5, 2015 at 5:20 PM, Yasuo Ohgaki wrote: > Hi Leigh, > > On Thu, Feb 5, 2015 at 5:31 PM, Leigh wrote: > >> On 5 February 2015 at 05:37, Adam Harvey wrote: >> > I'm not totally clear on what this RFC is proposing, honestly. Is the >> > new script statement meant to only include files t

Re: [PHP-DEV] Re: [RFC][DISCUSSION] script() and script_once()

Hi Pierre and all, On Thu, Feb 5, 2015 at 7:24 PM, Pierre Joye wrote: > > > > > > I'm proposing *SCRIPT* only inclusion. This can be done by > > > > - allowing " > - not allowing "?>" anywhere (We may allow at the end possibly) > > > > Those who do not understand my point. > > Please search by

Re: [PHP-DEV] Re: [RFC][DISCUSSION] script() and script_once()

On 5 February 2015 at 10:24, Pierre Joye wrote: > I do understand what you try to achieve, from all point of view. > However I strongly disagree with this as a security improvement. I see > this more as yet another attempt to replace what should be done at the > OS level. > I'm inclined to agree,

Re: [PHP-DEV] Re: [RFC][DISCUSSION] script() and script_once()

Hi Pierre, On Thu, Feb 5, 2015 at 7:24 PM, Pierre Joye wrote: > I do understand what you try to achieve, from all point of view. > However I strongly disagree with this as a security improvement. I see > this more as yet another attempt to replace what should be done at the > OS level. > I shou

Re: [PHP-DEV] Re: [RFC][DISCUSSION] script() and script_once()

Hi Leigh, On Thu, Feb 5, 2015 at 7:51 PM, Leigh wrote: > On 5 February 2015 at 10:24, Pierre Joye wrote: > > I do understand what you try to achieve, from all point of view. > > However I strongly disagree with this as a security improvement. I see > > this more as yet another attempt to replac

[PHP-DEV] hints and constraints

Been tied up with a family matter for the last couple of days, so I've not been able to read all 200 posts in my in box for internals. Whilst I've been away from the computer I've had time to contemplate, and I think we need to summarise the discussions in a different way. A number of disjointed t

[PHP-DEV] Design by Contract

Hi Yasuo, Following our conversation, I tried to imagine how DbC should look like in PHP from user perspective. Finally, I was influenced by the semantic proposed in D, and syntax proposed for Java. So, these are my initial thoughts: For php it may look like the following: function foo() req

Re: [PHP-DEV] hints and constraints

Hi Lester, > On 5 Feb 2015, at 10:58, Lester Caine wrote: > > Can I please rename the 'big integer' rfc to 'unconstrained integer' for > two reasons. One BIGINT does have well established definitions in the > last 10+ years of PHP and other code bases. This is not true. The terms ‘arbitrary-pre

Re: [PHP-DEV] Design by Contract

Am 05.02.2015 12:14 schrieb "Dmitry Stogov" : > > For php it may look like the following: > > function foo() > require() > ensure() > { > ... > } > > It would require only one new reserved word "ensure". How would one access the function return value in the output-assert-expression? And

Re: [PHP-DEV] Design by Contract

On Thu, Feb 5, 2015 at 2:38 PM, Patrick Schaaf wrote: > Am 05.02.2015 12:14 schrieb "Dmitry Stogov" : > > > > For php it may look like the following: > > > > function foo() > > require() > > ensure() > > { > > ... > > } > > > > It would require only one new reserved word "ensure". > > H

AW: [PHP-DEV] Design by Contract

Hi Dimitry > -Ursprüngliche Nachricht- > Von: Dmitry Stogov [mailto:dmi...@zend.com] > Gesendet: Donnerstag, 5. Februar 2015 12:14 > An: Yasuo Ohgaki; PHP Internals > Betreff: [PHP-DEV] Design by Contract > > Hi Yasuo, > > Following our conversation, I tried to imagine how DbC should loo

Re: [PHP-DEV] Re: [RFC][DISCUSSION] script() and script_once()

On Thu, Feb 5, 2015 at 5:47 PM, Yasuo Ohgaki wrote: > Hi Pierre and all, > > On Thu, Feb 5, 2015 at 7:24 PM, Pierre Joye wrote: >> >> > >> > >> > I'm proposing *SCRIPT* only inclusion. This can be done by >> > >> > - allowing "> > - not allowing "?>" anywhere (We may allow at the end possibly)

Re: [PHP-DEV] Design by Contract

Hi Robert, This is about "declarative" vs "imperative" programming. Also constraints may be enabled for debugging and completely disabled for production. I'm not the inventor of this approach, I just started to think about it myself :) You opinion makes sense as well. PHP doesn't have to support

Re: [PHP-DEV] Allow dropping typehints during inheritance

On Thu, Feb 5, 2015 at 2:08 AM, Andrea Faulds wrote: > Hi Hannes, > > > On 4 Feb 2015, at 23:58, Hannes Magnusson > wrote: > > > > So what it supports "more inputs"? > > It does constitute an LSP violation. "more inputs" is not what the > > guarantee is at all, if that is what you want you'd typ

Re: [PHP-DEV] Design by Contract

On Thursday 05 February 2015 15:14:04 Dmitry Stogov wrote: > > function foo() > requre() > ensure() > { > ... > } > > It would require only one new reserved word "ensure". Regarding syntax This could be another place where the irrationally- dreaded declare would make sense: functio

Re: [PHP-DEV] Allow dropping typehints during inheritance

On 05/02/15 13:10, Julien Pauli wrote: > On Thu, Feb 5, 2015 at 2:08 AM, Andrea Faulds wrote: > >> Hi Hannes, >> >>> On 4 Feb 2015, at 23:58, Hannes Magnusson >> wrote: >>> >>> So what it supports "more inputs"? >>> It does constitute an LSP violation. "more inputs" is not what the >>> guarantee

Re: [PHP-DEV] Allow dropping typehints during inheritance

Hi Julien, > On 5 Feb 2015, at 12:10, Julien Pauli wrote: > > If we allow larger type, why doesn't such code work ? > > interface A { } > interface B extends A { } > > class C { > public function foo(A $a) { } > } > > class D extends C { > public function foo(B $a) { } // E_STRICT > }

AW: [PHP-DEV] Allow dropping typehints during inheritance

> -Ursprüngliche Nachricht- > Von: julienpa...@gmail.com [mailto:julienpa...@gmail.com] Im Auftrag von > Julien Pauli > Gesendet: Donnerstag, 5. Februar 2015 13:10 > An: Andrea Faulds > Cc: Hannes Magnusson; Nikita Popov; PHP internals > Betreff: Re: [PHP-DEV] Allow dropping typehints dur

Re: [PHP-DEV] Allow dropping typehints during inheritance

Hannes Magnusson wrote on 04/02/2015 23:58: On Wed, Feb 4, 2015 at 10:49 AM, Nikita Popov wrote: Hi internals! Currently we do not allow [1] removing a typehint during inheritance. For example the following code is not valid: interface A { public function method(Typehint $param)

Re: [PHP-DEV] Design by Contract

Hello, internals! >From my point of view, contracts should not affect execution of source code in production env, or can be enabled partially. I have implemented DbC paradigm on top of the AOP layer, so each contract can be defined via annotation and looks pretty nice, for example : use PhpDeal\A

Re: [PHP-DEV] Design by Contract

this way we would able to use in constraints any statements. The require/ensure syntax was limited to expressions (to limit users in making side effects). May be we may reuse delare() a bit differently. function foo() { declare(pre=) declare(post=) { } However. I like require/ensure mor

Re: [PHP-DEV] Design by Contract

So, is it possible to use annotations for defining such metadata on engine-level? This will be a good way to do this and to define custom handlers via AST hooks, that can be able to patch method definition node with concrete opcodes. 2015-02-05 15:24 GMT+03:00 Alexander Lisachenko : > Hello, inte

Re: [PHP-DEV] Design by Contract

Hi Alexander, Defining contracts through doc-comments is also possible, but this way is not native. On the other hand, if you already have this implemented, we may just reuse it. Thanks. Dmitry. On Thu, Feb 5, 2015 at 3:24 PM, Alexander Lisachenko < lisachenko...@gmail.com> wrote: > Hello, inte

Re: [PHP-DEV] Windows builds PECL site integration

Hello Anatol, So thanks for the ping. Actually I'd call anyone interested to not to > hesitate - ping on errors so they get resolved faster. Also, snapshots can > be done manually before release to check everything is fine, please ping > as well for that. > Found a package which seems to be build

Re: AW: [PHP-DEV] Allow dropping typehints during inheritance

Robert Stoll wrote on 05/02/2015 12:16: -Ursprüngliche Nachricht- Von: julienpa...@gmail.com [mailto:julienpa...@gmail.com] Im Auftrag von Julien Pauli Gesendet: Donnerstag, 5. Februar 2015 13:10 An: Andrea Faulds Cc: Hannes Magnusson; Nikita Popov; PHP internals Betreff: Re: [PHP-DEV] A

Re: [PHP-DEV] hints and constraints

On 05/02/15 11:37, Andrea Faulds wrote: > Hi Lester, > >> On 5 Feb 2015, at 10:58, Lester Caine wrote: >> >> Can I please rename the 'big integer' rfc to 'unconstrained integer' for >> two reasons. One BIGINT does have well established definitions in the >> last 10+ years of PHP and other code ba

Re: [PHP-DEV] Design by Contract

For now, we don't have any mechanism for annotations or attributes except for doc-comments. Thanks. Dmitry. On Thu, Feb 5, 2015 at 3:27 PM, Alexander Lisachenko < lisachenko...@gmail.com> wrote: > So, is it possible to use annotations for defining such metadata on > engine-level? This will be a

Re: [PHP-DEV] Design by Contract

2015-02-05 15:32 GMT+03:00 Dmitry Stogov : > Hi Alexander, > > Defining contracts through doc-comments is also possible, but this way is > not native. > On the other hand, if you already have this implemented, we may just reuse > it. > Thanks, Dmitry! This would be a really nice feature on engin

Re: [PHP-DEV] Windows builds PECL site integration

Hi Martin, On Thu, February 5, 2015 13:32, Martin Keckeis wrote: > Hello Anatol, > > > So thanks for the ping. Actually I'd call anyone interested to not to > >> hesitate - ping on errors so they get resolved faster. Also, snapshots >> can be done manually before release to check everything is fin

Re: [PHP-DEV] Design by Contract

At this moment, I don't have any plans related to implementation of hook-able compiler. However the first step was already done, introducing "zend_ast_process" callback. In general it's should be possible to provide PHP API to manipulate with AST and write compiler extensions in PHP. Looks promisin

RE: [PHP-DEV] Design by Contract

Hi Dmitry, > De : Dmitry Stogov [mailto:dmi...@zend.com] > > Following our conversation, I tried to imagine how DbC should look like in > PHP from user perspective. Finally, I was influenced by the semantic > proposed in D, and syntax proposed for Java. So, these are my initial > thoughts: Please

Re: [PHP-DEV] Design by Contract

2015-02-05 16:07 GMT+03:00 Dmitry Stogov : > In general it's should be possible to provide PHP API to manipulate with > AST and write compiler extensions in PHP. > Looks promising.. :) > Anyway, If you are interested - start working on it. Actually, it's almost done by Nikita Popov: https://git

Re: [PHP-DEV] hints and constraints

Lester Caine wrote on 05/02/2015 12:33: On 05/02/15 11:37, Andrea Faulds wrote: The current description isn’t totally inaccurate, but I had considered renaming the RFC since “big integer support” implies we don’t already have support for big integers, though we do in the form of ext/gmp. A bet

Re: [PHP-DEV] Design by Contract

Yeah, this may work. The only problem, that it looks not native and defines additional language for constraints. I don't talk it's wrong. Both approaches may make sense, but of course, we have to select one. Thanks. Dmitry. On Thu, Feb 5, 2015 at 4:19 PM, François Laupretre wrote: > Hi Dmitry,

Re: [PHP-DEV] Design by Contract

php-ast is not almost the same, but it may be extended. Thanks. Dmitry. On Thu, Feb 5, 2015 at 4:34 PM, Alexander Lisachenko < lisachenko...@gmail.com> wrote: > > 2015-02-05 16:07 GMT+03:00 Dmitry Stogov : > >> In general it's should be possible to provide PHP API to manipulate with >> AST and w

RE: [PHP-DEV] Design by Contract

De : Dmitry Stogov [mailto:dmi...@zend.com] > Yeah, this may work. > The only problem, that it looks not native and defines additional language > for constraints. > I don't talk it's wrong. Both approaches may make sense, but of course, we > have to select one. Yes, it makes phpdoc more tied t

Re: [PHP-DEV] hints and constraints

Rowan Collins wrote: > There is nothing new about PHP's userland int type being 64-bit on > 64-bit platforms. For instance, raising 2 to the power of 62 returns > exactly the same thing on every version of PHP back to 4.3.0: > http://3v4l.org/VBMbv Unfortunately, that's not true for Windows, see

[PHP-DEV] Re: Serialize generating corrupted data

No one? On Mon, Feb 2, 2015 at 8:57 PM, Juan Basso wrote: > Hi, > > I was testing few things today and I released one bug in the serialize > function. The serialize function returns a corrupted value when it is > serializing an object that contains a __sleep magic method and this method > return

Re: [PHP-DEV] hints and constraints

Christoph Becker wrote on 05/02/2015 14:01: Rowan Collins wrote: There is nothing new about PHP's userland int type being 64-bit on 64-bit platforms. For instance, raising 2 to the power of 62 returns exactly the same thing on every version of PHP back to 4.3.0: http://3v4l.org/VBMbv Unfortuna

Re: [PHP-DEV] Design by Contract

Hi Internal :-), I just would like to point out some stuff. tl;dr: Contracts can be used to validate code (Design-by-Contract) or generate test data to validate code (Contract-based Testing). There are plenty of contract languages in the wild, each one addresses a specific problem (object, s

[PHP-DEV] Re: Design by Contract

Hi Dmitry, Thank you for your time! On Thu, Feb 5, 2015 at 8:14 PM, Dmitry Stogov wrote: > Following our conversation, I tried to imagine how DbC should look like in > PHP from user perspective. Finally, I was influenced by the semantic > proposed in D, and syntax proposed for Java. So, these a

Re: [PHP-DEV] Re: Serialize generating corrupted data

Juan Basso wrote on 05/02/2015 14:07: No one? On Mon, Feb 2, 2015 at 8:57 PM, Juan Basso wrote: Hi, I was testing few things today and I released one bug in the serialize function. The serialize function returns a corrupted value when it is serializing an object that contains a __sleep magic

RE: [PHP-DEV] Design by Contract

On Feb 5, 2015 8:54 PM, "François Laupretre" wrote: > > De : Dmitry Stogov [mailto:dmi...@zend.com] > > > Yeah, this may work. > > The only problem, that it looks not native and defines additional language for constraints. > > I don't talk it's wrong. Both approaches may make sense, but of course,

Re: [PHP-DEV] Design by Contract

Hi Patrick, On Thu, Feb 5, 2015 at 9:13 PM, Patrick Schaaf wrote: > On Thursday 05 February 2015 15:14:04 Dmitry Stogov wrote: > > > > function foo() > > requre() > > ensure() > > { > > ... > > } > > > > It would require only one new reserved word "ensure". > > Regarding syntax Thi

Re: [PHP-DEV] Re: Serialize generating corrupted data

Rowan, It is happening and giving the same message, but the problem is the generate value is corrupted because it generates N; without the key. Ie, when you have a valid field and an invalid field it generates O:1:"C":2:{s:1:"a";b:1;N;} (note that "a" is the property name, 1 is the boolean value a

Re: [PHP-DEV] Design by Contract

Hi all, On Fri, Feb 6, 2015 at 12:00 AM, Pierre Joye wrote: > On Feb 5, 2015 8:54 PM, "François Laupretre" wrote: > > > > De : Dmitry Stogov [mailto:dmi...@zend.com] > > > > > Yeah, this may work. > > > The only problem, that it looks not native and defines additional > language for constraints

RE: [PHP-DEV] Design by Contract

De : Pierre Joye [mailto:pierre@gmail.com] >> Yes, it makes phpdoc more tied to the engine but is it a problem ? > > And here I have to jump in and say: don't. > And remind about one of the exact purposes of annotations. Sorry, I am not sure I understand. If you're talking about the link be

Re: [PHP-DEV] Re: Serialize generating corrupted data

On Thu, Feb 5, 2015 at 9:57 AM, Rowan Collins > wrote: Playing around with existing behaviour, if you return something other than an array, you get a Notice and a serialized null ('N;') - e.g. http://3v4l.org/rm9rs I think it would be reasonable

Re: [PHP-DEV] Design by Contract

Hi Ivan, On Thu, Feb 5, 2015 at 11:25 PM, Ivan Enderlin @ Hoa < ivan.ender...@hoa-project.net> wrote: > I just would like to point out some stuff. > > > tl;dr: Contracts can be used to validate code (Design-by-Contract) or > generate test data to validate code (Contract-based Testing). There are

RE: [PHP-DEV] Design by Contract

> De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki > We don't have to integrate DbC into phpdoc. phpdoc may have integration of > new DbC syntax. > I think it's helpful even if phpdoc copies post/pre condition as document. > > There are too many possibility for DbC sy

Re: [PHP-DEV] Re: Serialize generating corrupted data

Thanks for changing the top posting. :) About the solution, I like the way HHVM solves that. It is also more consistent with the case where you add the invalid value as string on the __sleep (ie, on http://3v4l.org/kupOg I changed the 1 from integer to string). If you return "N;" is hard to detect

Re: [PHP-DEV] Design by Contract

Hi Francois, On Fri, Feb 6, 2015 at 1:11 AM, François Laupretre wrote: > > De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo > Ohgaki > > > We don't have to integrate DbC into phpdoc. phpdoc may have integration > of new DbC syntax. > > I think it's helpful even if phpdoc cop

Re: [PHP-DEV] hints and constraints

Lester Caine wrote on 05/02/2015 14:51: On 05/02/15 14:24, Rowan Collins wrote: There is nothing new about PHP's userland int type being 64-bit on 64-bit platforms. For instance, raising 2 to the power of 62 returns exactly the same thing on every version of PHP back to 4.3.0: http://3v4l.org/VB

Re: [PHP-DEV] Design by Contract

phpdoc is annotation as well, but to split it into specific attributes we have to write specialized parsers. Other languages support annotation or attributes that may be used more easily. http://docs.hhvm.com/manual/en/hack.attributes.php Thanks. Dmitry. On Thu, Feb 5, 2015 at 6:40 PM, François

Re: [PHP-DEV] Design by Contract

This is just a brainstorming, and we are not going to provide a working solution tomorrow :) You have enough time :) I don't like phpdoc approach because we have to define, parse and compile new syntax for constraints. Would constraint be able to call other functions? include external php files? e

Re: [PHP-DEV] hints and constraints

On 05/02/15 16:24, Rowan Collins wrote: >> The simple answer here is that there is not a 'single' definition of >> integer ... > > True. But the definition of "integer" in PHP is, and has been for many > years, "as big as this build can handle". With Andrea's patch, all > systems can handle really

Re: [PHP-DEV] Re: Serialize generating corrupted data

Hi! >> I can try to make a patch to solve it, but before that I would like how >> the behavior should be. Some options: >> 1) Give the notice saying the field doesn't exist and do not include on >> the serialized response >> 2) Give the notice saying the field doesn't exist and convert the value t

Re: [PHP-DEV] Allow dropping typehints during inheritance

Hi! > If we allow larger type, why doesn't such code work ? > > interface A { } > interface B extends A { } > > class C { > public function foo(A $a) { } > } > > class D extends C { > public function foo(B $a) { } // E_STRICT > } > > This is wrong IMO. This shouldn't work - it means t

RE: [PHP-DEV] Design by Contract

De : Dmitry Stogov [mailto:dmi...@zend.com] > > I don't like phpdoc approach because we have to define, parse and compile new > syntax for constraints. > Would constraint be able to call other functions? include external php files? > etc? There are 2 sort of constraints : - declared types with

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

On Feb 5, 2015 3:17 PM, "Michael Wallner" wrote: > > Hi Stas! > > On 05/02/15 00:43, Stanislav Malyshev wrote: > > Hi! > > > >> Points explicitely marked for discussion in the RFC itself: > >> > >> * pecl/propro > >> Proxies for properties representing state in internal C structs > >> https://

Re: [PHP-DEV] Design by Contract

Hi Francois, On Fri, Feb 6, 2015 at 1:18 AM, Yasuo Ohgaki wrote: > > On Fri, Feb 6, 2015 at 1:11 AM, François Laupretre > wrote: > >> > De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo >> Ohgaki >> >> > We don't have to integrate DbC into phpdoc. phpdoc may have integration

Re: [PHP-DEV] Design by Contract

On Fri, Feb 6, 2015 at 2:54 AM, Yasuo Ohgaki wrote: > Is there is syntax error or assertion error. Error messages look like I mean If there is syntax error... -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] hints and constraints

Lester Caine wrote on 05/02/2015 16:49: On 05/02/15 16:24, Rowan Collins wrote: The simple answer here is that there is not a 'single' definition of integer ... True. But the definition of "integer" in PHP is, and has been for many years, "as big as this build can handle". With Andrea's patch,

Re: [PHP-DEV] Design by Contract

On Fri, Feb 6, 2015 at 2:54 AM, Yasuo Ohgaki wrote: > __invariant() Oops __invariant_before_foo() __invariant_after_foo() There are other bad english. I should spend more time to check. Sorry. -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] What do we need strict scalar type hints for?

Hi, > On 5 Feb 2015, at 06:52, Dmitry Stogov wrote: > > I completely agree. > Strict typing doesn't fit into PHP. It was already told thousand times. Seems to work rather well in practice, so long as it’s optional. > Also, the only really useful case for "strict typing" is the ability to catch

Re: [PHP-DEV] What do we need strict scalar type hints for?

Hi François, > On 5 Feb 2015, at 08:58, François Laupretre wrote: > > +1. Checking IS_ at the C level after implicit conversions and checking > this at the PHP level are very different. > > IMHO, the key point is the concept of 'type'. Strict typing considers a > one-to-one correspondence bet

Re: [PHP-DEV] Design by Contract

If we allow any statements in require/ensure, then we should use {} instead of() function foo($a, $b) reuire { ... } ensure($ret) { ... } { } my idea was to restrict constraint code to expression. in this case () would be enough. it should be possible to use few con

Re: [PHP-DEV] What do we need strict scalar type hints for?

On Thu, Feb 5, 2015 at 9:50 PM, Andrea Faulds wrote: > Hi, > > > On 5 Feb 2015, at 06:52, Dmitry Stogov wrote: > > > > I completely agree. > > Strict typing doesn't fit into PHP. It was already told thousand times. > > Seems to work rather well in practice, so long as it’s optional. > "works" a

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

Hi Pierre! On 05/02/15 18:49, Pierre Joye wrote: > > On Feb 5, 2015 3:17 PM, "Michael Wallner" > wrote: >> >> Compare the timings accessing google 20 times sequentually: >> >> With default of raphf.persistent_handle.limit=-1 (unlimited): >> █ mike@smugmug:~$ time php -r 'for

[PHP-DEV] [VOTE] Scalar Type Hints

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 any

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

Hi! > Does the following kcachegrind screenshot give an idea (I used a minimum > node cost of 10% to simplify the graph)? > > Left is raphf enabled (24M Ir) and on the right raphf disabled (35M Ir): > http://dev.iworks.at/ext-http/raphf.png > > Have a look on the top-most far-right highlighted b

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

Hi Stas! On 05/02/15 21:28, Stanislav Malyshev wrote: > Hi! > >> Does the following kcachegrind screenshot give an idea (I used a minimum >> node cost of 10% to simplify the graph)? >> >> Left is raphf enabled (24M Ir) and on the right raphf disabled (35M Ir): >> http://dev.iworks.at/ext-http/rap

[PHP-DEV] BC break in headers_list

Hi Anatol! Your recent fixes to headers_list() - 55cefb2814bde5815a92e8820fff45e037fa8d4f and b5d3c5ca8dee6303498849448e3574cc3642eeea - broke head.phpt test and also are BC-breaking since previously headers_list() always returned an array (empty one if there are no headers), now it returns false

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

Hi! > Uhm, I'm not sure I understand :-? Weren't I supposed to measure exacly > that? Let me know, if you wanted something else to be compared. I wanted to know why we need persistent resources. You brought comparing persistent resources to reopening connection each time as an argument that we ne

Re: [PHP-DEV] Allow dropping typehints during inheritance

On Thu, Feb 5, 2015 at 5:14 AM, Andrea Faulds wrote: > Hi Julien, > >> On 5 Feb 2015, at 12:10, Julien Pauli wrote: >> >> If we allow larger type, why doesn't such code work ? >> >> interface A { } >> interface B extends A { } >> >> class C { >> public function foo(A $a) { } >> } >> >> class

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

We have had quite a number of changes to the extension API and it worries me a little bit how long it will take everyone to get their extensions ported. We have UPGRADING.INTERNALS which still needs some love, but even if that covered everything it is sometimes hard to match a bullet point in a lon

Re: [PHP-DEV] Allow dropping typehints during inheritance

On 5 February 2015 at 21:52, Levi Morrison wrote: > To chime in regarding allowing contravariant parameter types: I > struggle to find use cases for it. Theoretically it would allow a class to implement two separate interfaces that would otherwise be incompatible: interface A { function foo(

  1   2   >