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

Hi Stas! On 05/02/15 21:46, Stanislav Malyshev wrote: > 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 re

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

Hi Rasmus, Rasmus Lerdorf writes: > It looks like this: > > https://gist.github.com/anonymous/15cbc9947edb4f0a71fd > > Any suggestions for how to handle annotating it? We could turn it into a > fake PR and mark it up using github's PR comments. But is there > something more suited for this out

Re: [PHP-DEV] Design by Contract

On 06/02/15 05:00, Pierre Joye wrote: On Thu, Feb 5, 2015 at 11:36 PM, Dmitry Stogov wrote: 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.h

Re: [PHP-DEV] Design by Contract

On 05/02/15 17:09, Yasuo Ohgaki wrote: Hi Ivan, Hi Yasuo :-), On Thu, Feb 5, 2015 at 11:25 PM, Ivan Enderlin @ Hoa mailto: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 ge

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

+1 > -Message d'origine- > De : a...@adamharvey.name [mailto:a...@adamharvey.name] De la part > de Adam Harvey > Envoyé : vendredi 6 février 2015 02:23 > À : Andrea Faulds > Cc : PHP Internals > Objet : Re: [PHP-DEV] [VOTE] Scalar Type Hints > > On 6 February 2015 at 04:14, Andrea Faulds

RE: [PHP-DEV] Design by Contract

> De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki > > Thank you for your time. It's based on annotation approach. This kind of > implementation requires a lot of work... I have an idea of a way to do it with limited work. Most important, everything would be in an ext

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

+1 > On Feb 5, 2015, at 5:23 PM, Adam Harvey wrote: > > On 6 February 2015 at 04:14, Andrea Faulds wrote: >> 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. > > True, and I probably won't respon

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

Hi Pierre, On Fri, Feb 6, 2015 at 1:52 PM, Pierre Joye wrote: > But it is the key point. It is not PHP role to do it. PHP is not > alone. It is a server configuration job. But I have said that already > many times, we got our points :) > I understand your point. We need both OS and PHP feature

[PHP-DEV] Re: Design by Contract

On 2015-02-05, Dmitry Stogov wrote: > --001a11c20e52da1ee0050e556679 > Content-Type: text/plain; charset=UTF-8 > > 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 sy

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

On Fri, Feb 6, 2015 at 11:35 AM, Yasuo Ohgaki wrote: > Hi Pierre, > > On Fri, Feb 6, 2015 at 1:16 PM, Pierre Joye wrote: >> >> > With SElinux, we can restrict access. However, PHP should be able to >> > read/write >> > uploaded files. PHP just read and execute them with include. >> >> Again, I am

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

Hi all, On Fri, Feb 6, 2015 at 1:35 PM, Yasuo Ohgaki wrote: > > I have similar idea for PHP to have data only dirs. >> >> We have that already, not for php, but for web servers. This is their >> job to deal with that. > > > Yes, indeed. > engine=off > per dirs. This is what I suggest people. It

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

Hi, Thanks for the feedback. I opened the pull request (https://github.com/php/php-src/pull/1057). Is that correct? On Thu, Feb 5, 2015 at 12:30 PM, Stanislav Malyshev wrote: > Hi! > > >> I can try to make a patch to solve it, but before that I would like how > >> the behavior should be. Some

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

Hi Pierre, On Fri, Feb 6, 2015 at 1:16 PM, Pierre Joye wrote: > > With SElinux, we can restrict access. However, PHP should be able to > > read/write > > uploaded files. PHP just read and execute them with include. > > Again, I am talking about executing files. You can exclude a file, > path, fo

Re: [PHP-DEV] Design by Contract

On Fri, Feb 6, 2015 at 11:14 AM, guilhermebla...@gmail.com wrote: > Hi Pierre, > > Sorry, but you don't. Proposing a simple syntax is the same as not proposing > it. > We can do whatever syntax is proposed, but we need to discuss on how to > handle inheritance, overriding, etc. > None ever discuss

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

On Fri, Feb 6, 2015 at 11:08 AM, Yasuo Ohgaki wrote: > > On Fri, Feb 6, 2015 at 12:40 PM, Pierre Joye wrote: >> >> > Even if uploaded files are stored under non web root dir, attackers can >> > use >> > path >> > traversal or even full path with bad code. As long as PHP can access, >> > attacker

Re: [PHP-DEV] Design by Contract

Hi Pierre, Sorry, but you don't. Proposing a simple syntax is the same as not proposing it. We can do whatever syntax is proposed, but we need to discuss on how to handle inheritance, overriding, etc. None ever discussed that. 2010's patch handled all that nicely. I do remember however Dmitry had

Re: [PHP-DEV] Design by Contract

On Fri, Feb 6, 2015 at 11:08 AM, guilhermebla...@gmail.com wrote: > Hi all, > > I already said before and I'm happy to say it again... > Whenever you feel ready to get true, complete Annotations into core, just > tell me and I'll be ready to work on previously suggested Annotations in > sync with

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

Hi Pierre, On Fri, Feb 6, 2015 at 12:40 PM, Pierre Joye wrote: > > Even if uploaded files are stored under non web root dir, attackers can > use > > path > > traversal or even full path with bad code. As long as PHP can access, > > attacker > > can access to files for inclusion attacks. Compress

Re: [PHP-DEV] Design by Contract

Hi all, I already said before and I'm happy to say it again... Whenever you feel ready to get true, complete Annotations into core, just tell me and I'll be ready to work on previously suggested Annotations in sync with current internals. Cheers, On Thu, Feb 5, 2015 at 11:00 PM, Pierre Joye wro

Re: [PHP-DEV] Design by Contract

On Thu, Feb 5, 2015 at 11:44 PM, Dmitry Stogov wrote: > 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 const

Re: [PHP-DEV] Design by Contract

On Thu, Feb 5, 2015 at 11:36 PM, Dmitry Stogov wrote: > 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.attribut

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

On Fri, Feb 6, 2015 at 10:33 AM, Yasuo Ohgaki wrote: > Hi Pierre, > > On Fri, Feb 6, 2015 at 11:13 AM, Pierre Joye wrote: >> >> > I am :) Almost all of my clients are ISMS or similar certified. >> >> Marketing ;) >> >> >> However, back to this exact feature. I am not convinced it is the >> >> ri

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

Hi Pierre, On Fri, Feb 6, 2015 at 11:13 AM, Pierre Joye wrote: > > I am :) Almost all of my clients are ISMS or similar certified. > > Marketing ;) > > >> However, back to this exact feature. I am not convinced it is the > >> right way, there are many cases required more than just checking vali

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

Sent from my iPhone > On Feb 6, 2015, at 9:38 AM, Yasuo Ohgaki wrote: > > Hi Rasmus, > >> On Fri, Feb 6, 2015 at 7:28 AM, Rasmus Lerdorf wrote: >> >> Having just finished porting php-memcached (with help from Xinchen) to >> PHP7 I was wondering if it wouldn't be worthwhile to annotate the d

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

On Feb 6, 2015 9:08 AM, "Yasuo Ohgaki" wrote: > > Hi Pierre, > > On Fri, Feb 6, 2015 at 10:39 AM, Pierre Joye wrote: >> >> I do not put high value in this ISO ;-) > > > I am :) Almost all of my clients are ISMS or similar certified. Marketing ;) >> However, back to this exact feature. I am not

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

Hi Pierre, On Fri, Feb 6, 2015 at 10:39 AM, Pierre Joye wrote: > I do not put high value in this ISO ;-) > I am :) Almost all of my clients are ISMS or similar certified. However, back to this exact feature. I am not convinced it is the > right way, there are many cases required more than jus

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

Hi Rasmus, On Fri, Feb 6, 2015 at 7:28 AM, Rasmus Lerdorf wrote: > Having just finished porting php-memcached (with help from Xinchen) to > PHP7 I was wondering if it wouldn't be worthwhile to annotate the diff > and explain why each change was made. The extension is complicated > enough to cove

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

On Fri, Feb 6, 2015 at 8:25 AM, Yasuo Ohgaki wrote: > Hi Pierre, > > On Thu, Feb 5, 2015 at 8:49 PM, Pierre Joye wrote: >> >> PHP is just as safe than the other languages. PHP applicatons maybe >> less, maybe more. I tend to see the amount of attacks as a proof of >> success of a tool instead of

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

Hi Pierre, On Thu, Feb 5, 2015 at 8:49 PM, Pierre Joye wrote: > PHP is just as safe than the other languages. PHP applicatons maybe > less, maybe more. I tend to see the amount of attacks as a proof of > success of a tool instead of a proof of the tool being unsafe (not > worth attacking 0.01% o

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

On 6 February 2015 at 04:14, Andrea Faulds wrote: > 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. True, and I probably won't respond to any replies to this because we don't need more noise, but I

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

Hi Pierre, > On 6 Feb 2015, at 00:50, Pierre Joye wrote: > > I have to agree here while I like the declare option, it should have > been an option as we clearly do not have a consensus during the > discussions (and will never have). Jeopardize the whole because of > that sounds dangerous to me.

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

On Fri, Feb 6, 2015 at 6:22 AM, Andi Gutmans wrote: > I have to say I’m pretty disappointed at the opening of the vote. > We had a pretty good RFC (thank you) for weak type hinting which was aligned > with the spirit of PHP and everyone was able to rally around it. > This has now been morphed int

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

Hi, > On 6 Feb 2015, at 00:24, Andi Gutmans wrote: > > Oh come on... You're taking me a bit too literally. Your proposal isn't > Java-like strict typing... I even said that. I still disagree with the sentiment, but never mind. I realise it was just a joke. >> No, I don’t think that’s fair. I’

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

On Thu, Feb 5, 2015 at 4:05 PM, Andrea Faulds wrote: > Hi Andi, > > > On 5 Feb 2015, at 23:57, Andi Gutmans wrote: > > > > The folks who really want all this great strict typing should head over > to Oracle.com and download free open-source Java? I hear it's got a lot of > strict typing features

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

Hi Andi, > On 5 Feb 2015, at 23:57, Andi Gutmans wrote: > > The folks who really want all this great strict typing should head over to > Oracle.com and download free open-source Java? I hear it's got a lot of > strict typing features in it. Only downside is that it'll take them 10x > longer t

[PHP-DEV] filter_var doesn't support international email addresses

Please let me know which mailing list address to use if I have sent this to the wrong list. filter_var does not properly validate emails with international characters. For example, this returns FALSE: var_dump(filter_var("Pelé@example.com", FILTER_VALIDATE_EMAIL)); Are there any plans to impleme

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

On Thu, Feb 5, 2015 at 3:53 PM, Andrea Faulds wrote: > Hi Andi, > > > On 5 Feb 2015, at 23:50, Andi Gutmans wrote: > > > > I am not sure. > > > > I think we need to explicitly vote on a weak type hinting option. > > Andrea, I think this should be an option in any vote. Right now it feels > like

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

Hi Andrea, On Fri, Feb 6, 2015 at 1:51 AM, Andrea Faulds wrote: > Hi Dan, > >> On 5 Feb 2015, at 23:41, Dan Ackroyd wrote: >> >> ... >> >> Additionally Andrea, I am disappointed that you opened voting without >> a option with the 'declare' stuff removed. This is despite myself >> having asked yo

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

OK. But maybe that's why PHP is better than those languages :) On Thu, Feb 5, 2015 at 3:49 PM, Rowan Collins wrote: > On 5 February 2015 23:22:26 GMT, Andi Gutmans wrote: > > >having such a declare(…) syntax will be ridiculed by the broader app > >dev community until the end of time… > > I thin

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

The folks who really want all this great strict typing should head over to Oracle.com and download free open-source Java? I hear it's got a lot of strict typing features in it. Only downside is that it'll take them 10x longer to complete their projects. OK sorry. Had to say that :) I realize it's n

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

Hi Andi, > On 5 Feb 2015, at 23:50, Andi Gutmans wrote: > > I am not sure. > > I think we need to explicitly vote on a weak type hinting option. > Andrea, I think this should be an option in any vote. Right now it feels like > the only option to people is the very challenging, non-consensus dr

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

Hi Dan, > On 5 Feb 2015, at 23:41, Dan Ackroyd wrote: > > As much as I want scalar types I'm voting no as: > > i) Having this code: > > function foo(int $numberOfRightTurns) { >$x = $numberOfRightTurns * 90; >return sin(deg2rad($x)) > } > > work or blow up depending on a setting at th

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

I am not sure. I think we need to explicitly vote on a weak type hinting option. Andrea, I think this should be an option in any vote. Right now it feels like the only option to people is the very challenging, non-consensus driving RFC or nothing. I think we have plenty of key folks who would supp

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

On 5 February 2015 23:22:26 GMT, Andi Gutmans wrote: >having such a declare(…) syntax will be ridiculed by the broader app >dev community until the end of time… I think that's laying it on a bit thick. It's no worse than Python's "from __future__ import", or JS's 'use strict;' (quotes included

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

Hi Andi, > On 5 Feb 2015, at 23:22, Andi Gutmans wrote: > > I have to say I’m pretty disappointed at the opening of the vote. > We had a pretty good RFC (thank you) for weak type hinting which was aligned > with the spirit of PHP and everyone was able to rally around it. This is far from true

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

On Feb 5, 2015, at 17:41, "guilhermebla...@gmail.com" wrote: > > Hi Rasmus, > > Thanks for the highlight. > My biggest concern about all this breakage done for NG could somehow be > minimized by providing possible alternate implementations that could work > both backwards compatible and forwa

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

I think the consensus is not so far away. As far as I understand the rules, it is possible to vote yes and put up a new RFC to remove strict-declare after the voting ends? Regards Thomas Andi Gutmans wrote on 06.02.2015 00:22: > I have to say I’m pretty disappointed at the opening of the vote.

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

As much as I want scalar types I'm voting no as: i) Having this code: function foo(int $numberOfRightTurns) { $x = $numberOfRightTurns * 90; return sin(deg2rad($x)) } work or blow up depending on a setting at the top of the file is horrible. ii) Having the code that I write in userland

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

I have to say I’m pretty disappointed at the opening of the vote. We had a pretty good RFC (thank you) for weak type hinting which was aligned with the spirit of PHP and everyone was able to rally around it. This has now been morphed into something very hard to swallow and IMO having such a decl

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

On 05/02/15 22:28, Rasmus Lerdorf wrote: > https://gist.github.com/anonymous/15cbc9947edb4f0a71fd > > Any suggestions for how to handle annotating it? We could turn it into a > fake PR and mark it up using github's PR comments. But is there > something more suited for this out there? A few extr

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

Hi, > On 5 Feb 2015, at 19:15, Dmitry Stogov wrote: > > "works" and "fits" are different. Fair point. > Strict type hinting may help catching problems only at run-time. > > In PHP you almost never can do something ahead of time, because of run-time > binding. > You may only guess, analyzing

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

On 5 February 2015 21:52:06 GMT, Levi Morrison wrote: >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 { } >>> >>

Re: [PHP-DEV] Design by Contract

Hi Dmitry, On Fri, Feb 6, 2015 at 3:58 AM, Dmitry Stogov wrote: > I don't think we should chose "right" approach right now. > It's better to collect few possible solutions e.g. statements, > expressions, doc-comments, attributes... > then describe their pros and cons to select the best one > I

Re: [PHP-DEV] hints and constraints

Rowan Collins wrote: > The point is that writing code in PHP and assuming integers will > overflow after 32 bits has been a bad idea for a long time, outside of > really unusual cases like COM integration [1], where there's a valid > reason to assume you'll never want to run it on Linux. I fully

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

Hi Rasmus, Thanks for the highlight. My biggest concern about all this breakage done for NG could somehow be minimized by providing possible alternate implementations that could work both backwards compatible and forwards compatible? I just don't want to work on extensions I support that would nev

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(

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

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

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

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

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

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

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

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

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

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

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

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

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

[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

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

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

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

  1   2   >