# RFC: Expectations - Thread: https://externals.io/message/69693 - Original archive: https://news-web.php.net/php.internals/69693 - Started by Joe Watkins on 2013-10-18T21:46:45+00:00 - Messages: 50 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/69693.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #69693 — Joe Watkins — 2013-10-18T21:46:45+00:00 URL: https://externals.io/message/69693#69693 Evening Chaps, Following on from discussion regarding assertion API in PHP, the following RFC is now up for discussion: https://wiki.php.net/rfc/expectations Please do point out any missing sections or information, so that it can be clarified as quickly as possible. I hope this conveys the idea a bit clearer to everyone ? Cheers Joe --- ## #69694 — Andrea Faulds — 2013-10-19T00:17:49+00:00 URL: https://externals.io/message/69693#69694 · In reply to: #69693 > Evening Chaps, > > Following on from discussion regarding assertion API in PHP, the > following RFC is now up for discussion: > > https://wiki.php.net/rfc/expectations > > Please do point out any missing sections or information, so that it > can be clarified as quickly as possible. > > I hope this conveys the idea a bit clearer to everyone ? > > Cheers > Joe > I like it, but I'd rather we just called them what they are and use AssertionException, because expect is really just a new assert statement, with a different name to avoid conflicting with `assert()` for backwards-compatibility :) Otherwise, I have no objections. Thanks. -- Andrea Faulds http://ajf.me/ --- ## #69695 — Robert Stoll — 2013-10-19T00:33:56+00:00 URL: https://externals.io/message/69693#69695 · In reply to: #69693 Hi Joe I like your RFC and how it is explained. You might want to add to your explanations that ExpectationException is a subclass of ErrorException (as mentioned in the other thread). And I was just wondering what the default value will be for the ini property zend.expectations, maybe you could add this as well. Cheers, Robert > -----Original Message----- > From: Joe Watkins [mailto:krakjoe@php.net] > Sent: Friday, October 18, 2013 11:47 PM > To: internals@lists.php.net > Subject: [PHP-DEV] RFC: Expectations > > Evening Chaps, > > Following on from discussion regarding assertion API in PHP, the > following RFC is now up for discussion: > > https://wiki.php.net/rfc/expectations > > Please do point out any missing sections or information, so that it can > be clarified as quickly as possible. > > I hope this conveys the idea a bit clearer to everyone ? > > Cheers > Joe > > > > -- > To unsubscribe, visit: > http://www.php.net/unsub.php --- ## #69697 — Madara Uchiha — 2013-10-19T07:28:14+00:00 URL: https://externals.io/message/69693#69697 · In reply to: #69695 I like it a lot. Let's face the truth. Assertions is a huge mess. We have two options: 1. Set it aside for now, and implement a better replacement 2. Jump right in, clean up the mess, and not have a functional alternative until PHP 7. +1 for expect. > Hi Joe > > I like your RFC and how it is explained. > You might want to add to your explanations that ExpectationException is a > subclass of ErrorException (as mentioned in the other thread). > And I was just wondering what the default value will be for the ini property > zend.expectations, maybe you could add this as well. > > Cheers, > Robert > > > […] > can > > […] > visit: > > […] --- ## #69698 — Joe Watkins — 2013-10-19T07:41:42+00:00 URL: https://externals.io/message/69693#69698 · In reply to: #69694 > > > […] > > I like it, but I'd rather we just called them what they are and use > AssertionException, because expect is really just a new assert > statement, with a different name to avoid conflicting with `assert()` for > backwards-compatibility :) > > Otherwise, I have no objections. > > Thanks. I thought about it ... For the sake of making the concept as simple as possible to convey in documentation, it is probably better to have a uniform name: Expect throwing ExpectationException is intuitive to some degree, Expect throwing an AssertionException seems less so ... Cheers Joe --- ## #69699 — Joe Watkins — 2013-10-19T08:05:51+00:00 URL: https://externals.io/message/69693#69699 · In reply to: #69695 > Hi Joe > > I like your RFC and how it is explained. > You might want to add to your explanations that ExpectationException is a > subclass of ErrorException (as mentioned in the other thread). > And I was just wondering what the default value will be for the ini property > zend.expectations, maybe you could add this as well. > > Cheers, > Robert > > > […] > can > > […] > visit: > > […] > > I have added the ErrorException info. It does say zend.expectations=1 in the config section, I'm not able to say what production/dev default settings will be. Cheers Joe --- ## #69700 — Joe Watkins — 2013-10-19T08:32:47+00:00 URL: https://externals.io/message/69693#69700 · In reply to: #69693 > Evening Chaps, > > Following on from discussion regarding assertion API in PHP, the > following RFC is now up for discussion: > > https://wiki.php.net/rfc/expectations > > Please do point out any missing sections or information, so that it > can be clarified as quickly as possible. > > I hope this conveys the idea a bit clearer to everyone ? > > Cheers > Joe > > I have added some performance information in comparison to the legacy assertion API, because I'm not sure it's obvious ... It is definitely worth looking at ... definitely ... Cheers Joe --- ## #69701 — Joe Watkins — 2013-10-19T08:58:00+00:00 URL: https://externals.io/message/69693#69701 > Le 18/10/2013 23:46, Joe Watkins a écrit : > > > […] > Really nice. > > Just a quick note about the provided tests, all "skip" message must > contain the "skip" word. > > Remi. > Fixed that .. thanks for the heads up ... Cheers Joe --- ## #69703 — eli@eliw.com — 2013-10-19T13:42:35+00:00 URL: https://externals.io/message/69693#69703 · In reply to: #69699 > > It does say zend.expectations=1 in the config section, I'm not able to > say what production/dev default settings will be. > I would assume that you'd want to state in the RFC that it would be default '1' in development, and default '0' in production. Based upon the so far discussed use cases. Eli --- ## #69704 — Joe Watkins — 2013-10-19T14:11:59+00:00 URL: https://externals.io/message/69693#69704 · In reply to: #69703 > > > […] > > I would assume that you'd want to state in the RFC that it would be > default '1' in development, and default '0' in production. Based upon > the so far discussed use cases. > > Eli > > > Have updated the note with clarity ... Cheers Joe --- ## #69705 — Jakub Zelenka — 2013-10-19T14:43:13+00:00 URL: https://externals.io/message/69693#69705 · In reply to: #69693 Hi, > Evening Chaps, > > Following on from discussion regarding assertion API in PHP, the > following RFC is now up for discussion: > > https://wiki.php.net/rfc/**expectations > > Please do point out any missing sections or information, so that > it can be clarified as quickly as possible. > > I hope this conveys the idea a bit clearer to everyone ? > > Cheers > Joe I think it's a nice idea. However I am not so sure if it's worthy introducing a new keyword 'except' which will break all existing code where except is used as a function name, class name... Could it be actually mentioned in the RFC that there is a new keyword? It's quite clear from the examples but it would be nice if it could be specified as it's quite important IMHO. In addition I have got more technical question about using ext functions in engine. I saw that you used php_trim in zend_compile.c. Is it a good idea to do that? Wouldn't be better to create a new function (for example zend_str_trim) in the engine (zend_operator.c comes to my mind as it contains zend_str_tolower and other similar function) and then use this function by php_trim? Jakub --- ## #69706 — Joe Watkins — 2013-10-19T14:46:43+00:00 URL: https://externals.io/message/69693#69706 · In reply to: #69705 > Hi, > > > > > […] > > > I think it's a nice idea. However I am not so sure if it's worthy > introducing a new keyword 'except' which will break all existing code where > except is used as a function name, class name... Could it be actually > mentioned in the RFC that there is a new keyword? It's quite clear from the > examples but it would be nice if it could be specified as it's quite > important IMHO. > > In addition I have got more technical question about using ext functions in > engine. I saw that you used php_trim in zend_compile.c. Is it a good idea > to do that? Wouldn't be better to create a new function (for example > zend_str_trim) in the engine (zend_operator.c comes to my mind as it > contains zend_str_tolower and other similar function) and then use this > function by php_trim? > > Jakub > It would appear a new keyword is required. I wasn't sure about php_trim either, I'll see what can be done there ... Cheers Joe --- ## #69707 — Joe Watkins — 2013-10-19T17:03:51+00:00 URL: https://externals.io/message/69693#69707 · In reply to: #69705 > Hi, > > > > > […] > > > I think it's a nice idea. However I am not so sure if it's worthy > introducing a new keyword 'except' which will break all existing code where > except is used as a function name, class name... Could it be actually > mentioned in the RFC that there is a new keyword? It's quite clear from the > examples but it would be nice if it could be specified as it's quite > important IMHO. > > In addition I have got more technical question about using ext functions in > engine. I saw that you used php_trim in zend_compile.c. Is it a good idea > to do that? Wouldn't be better to create a new function (for example > zend_str_trim) in the engine (zend_operator.c comes to my mind as it > contains zend_str_tolower and other similar function) and then use this > function by php_trim? > > Jakub > Removed dependency on php_trim ... Cheers Joe --- ## #69708 — Robert Stoll — 2013-10-19T22:36:07+00:00 URL: https://externals.io/message/69693#69708 · In reply to: #69693 Heya, I do not know how much it concerns this RFC but I came across the following page about an extension named "Expect" when I was searching for RFC Expect with google. http://php.net/manual/en/book.expect.php I suppose there would be a name clash between the extension and the new expect keyword. I do not know how internals usually deal with such problems, especially if it is within an extension, but I am sure someone will know it. Cheers, Robert > -----Original Message----- > From: Joe Watkins [mailto:krakjoe@php.net] > Sent: Friday, October 18, 2013 11:47 PM > To: internals@lists.php.net > Subject: [PHP-DEV] RFC: Expectations > > Evening Chaps, > > Following on from discussion regarding assertion API in PHP, the > following RFC is now up for discussion: > > https://wiki.php.net/rfc/expectations > > Please do point out any missing sections or information, so that it can > be clarified as quickly as possible. > > I hope this conveys the idea a bit clearer to everyone ? > > Cheers > Joe > > > > -- > To unsubscribe, visit: > http://www.php.net/unsub.php --- ## #69709 — Ferenc Kovacs — 2013-10-19T23:15:36+00:00 URL: https://externals.io/message/69693#69709 · In reply to: #69708 > Heya, > > I do not know how much it concerns this RFC but I came across the following > page about an extension named "Expect" when I was searching for RFC Expect > with google. > http://php.net/manual/en/book.expect.php > > I suppose there would be a name clash between the extension and the new > expect keyword. I do not know how internals usually deal with such > problems, > especially if it is within an extension, but I am sure someone will know > it. > > Cheers, > Robert > > it was discussed on irc, there is not problem here, because the ext name and the function name can't clash, and the ext doesn't have a function with the name of expect, so everything is fine afaik. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #69712 — Joe Watkins — 2013-10-20T07:54:03+00:00 URL: https://externals.io/message/69693#69712 · In reply to: #69709 > > > > […] > it was discussed on irc, there is not problem here, because the ext name > and the function name can't clash, and the ext doesn't have a function with > the name of expect, so everything is fine afaik. > Yeah, just to confirm, that's correct. Cheers Joe --- ## #69714 — Joe Watkins — 2013-10-21T01:52:01+00:00 URL: https://externals.io/message/69693#69714 · In reply to: #69709 > > > > […] > it was discussed on irc, there is not problem here, because the ext name > and the function name can't clash, and the ext doesn't have a function with > the name of expect, so everything is fine afaik. > Rasmus has pointed out that there is an expect:// stream wrapper. So looks like we need a new name ?? Ideas ?? Cheers Joe --- ## #69715 — Robert Williams — 2013-10-21T02:26:12+00:00 URL: https://externals.io/message/69693#69715 · In reply to: #69714 > > > So looks like we need a new name ?? Ideas ?? Hmm... posit, assume, demand, presume. I rather like demand; it has that air of be-true-or-else that fits the occasion. -- Bob Williams Notice: This communication, including attachments, may contain information that is confidential. It constitutes non-public information intended to be conveyed only to the designated recipient(s). If the reader or recipient of this communication is not the intended recipient, an employee or agent of the intended recipient who is responsible for delivering it to the intended recipient, or if you believe that you have received this communication in error, please notify the sender immediately by return e-mail and promptly delete this e-mail, including attachments without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is prohibited and may be unlawful. If you have received this email in error, please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if any). --- ## #69716 — Matthew Leverton — 2013-10-21T04:57:51+00:00 URL: https://externals.io/message/69693#69716 · In reply to: #69714 Since this would throw exceptions, could it look like (or be) a final/abstract (although PHP doesn't allow that combo for some reason) class with static methods? Assert::isTrue($expr, $msg); That syntax is already valid (so of course there are BC issues) and I don't know how practical it is to optimize that away to nothing, but it would be more consistent with regard to throwing exceptions and would allow for a variety of different class methods. -- Matthew Leverton > > > […] > > Rasmus has pointed out that there is an expect:// stream wrapper. > > So looks like we need a new name ?? Ideas ?? > > > Cheers > Joe --- ## #69717 — Julien Pauli — 2013-10-21T08:01:14+00:00 URL: https://externals.io/message/69693#69717 · In reply to: #69714 > > > > […] > Rasmus has pointed out that there is an expect:// stream wrapper. > > So looks like we need a new name ?? Ideas ?? Why ? The stream wrapper is always used in a string, so there is no parsing problem about the "expect" keyword. Am I missing something ? Julien.Pauli --- ## #69718 — Joe Watkins — 2013-10-21T08:06:33+00:00 URL: https://externals.io/message/69693#69718 · In reply to: #69717 > > > > […] > > > Why ? > > The stream wrapper is always used in a string, so there is no parsing > problem about the "expect" keyword. > Am I missing something ? > > Julien.Pauli > Morning Julien, I don't think you're missing anything, there's still no clash introduced in code ... there might be in minds though, I can see that ... Would be nice to get others' opinion, should we work to avoid this clash or will we be okay, is the difference obvious ? Cheers Joe --- ## #69719 — Patrick Schaaf — 2013-10-21T08:13:54+00:00 URL: https://externals.io/message/69693#69719 · In reply to: #69714 Am 21.10.2013 03:52 schrieb "Joe Watkins" : > > So looks like we need a new name ?? Ideas ?? abstract EXPRESSION abstract is already a keyword, so no BC. abstract is not concrete so alludes a bit to the might-be-or-might-not-be-checked nature of the test abstract is the name for the "short summary" intro part of scientific papers, and these conditions are kind of a summary of what is known (preconditions) and concluded (postconditions). best regards Patrick --- ## #69720 — Michael Wallner — 2013-10-21T08:16:28+00:00 URL: https://externals.io/message/69693#69720 · In reply to: #69719 > Am 21.10.2013 03:52 schrieb "Joe Watkins" : > > […] > > abstract EXPRESSION wat? > abstract is already a keyword, so no BC. > > abstract is not concrete so alludes a bit to the > might-be-or-might-not-be-checked nature of the test > > abstract is the name for the "short summary" intro part of scientific > papers, and these conditions are kind of a summary of what is known > (preconditions) and concluded (postconditions). Ah, ok well. I'd rather go for expected() or except() then... -- Regards, Mike --- ## #69721 — Joe Watkins — 2013-10-21T08:20:44+00:00 URL: https://externals.io/message/69693#69721 · In reply to: #69720 > > > […] > > wat? > > > > […] > > Ah, ok well. I'd rather go for expected() or except() then... > > Expected appears to be the most suitable solution suggested so far ... I was following along with the abstract suggestion, I thought that was pretty well thought out, but a bit hard to explain why we are re-using the abstract keyword for something that is completely unrelated to abstract classes all the same ... So for those that see the problem does Expected work around it ?? Cheers Joe --- ## #69722 — Rowan Collins — 2013-10-21T08:29:17+00:00 URL: https://externals.io/message/69693#69722 · In reply to: #69716 Matthew Leverton wrote (on 21/10/2013): > final/abstract (although PHP doesn't allow that combo for some reason) Final means "cannot be sub-classed", abstract means "must be sub-classed"; the combination would make no sense. Specifically, it would allow completely illogical code like "final abstract class Foo { abstract public function some_method(); }" Incidentally, Java doesn't allow this combination either; this isn't PHP being picky. The logical declaration for a class that can only be used statically would be "static class Foo { ... }". The combination "abstract static" also makes sense (for a static class with missing method bodies). There's an ancient RFC proposing that here, but it seems it didn't get anywhere much: https://wiki.php.net/rfc/static-classes Regards, -- Rowan Collins [IMSoP] --- Next page: https://externals.io/message/69693.md?page=2