FAQ
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

Search Discussions

  • Andrea Faulds at Oct 19, 2013 at 12:18 am

    On 18/10/2013 22:46, Joe Watkins wrote:
    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/
  • Joe Watkins at Oct 19, 2013 at 7:41 am

    On 10/19/2013 01:17 AM, Andrea Faulds wrote:
    On 18/10/2013 22:46, Joe Watkins wrote:
    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.
    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
  • Robert Stoll at Oct 19, 2013 at 12:34 am
    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
    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



    --
    PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
    http://www.php.net/unsub.php
  • Madara Uchiha at Oct 19, 2013 at 7:28 am
    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.
    On Sat, Oct 19, 2013 at 3:33 AM, Robert Stoll wrote:
    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
    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



    --
    PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
    http://www.php.net/unsub.php


    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Joe Watkins at Oct 19, 2013 at 8:05 am

    On 10/19/2013 01:33 AM, Robert Stoll wrote:
    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
    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



    --
    PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
    http://www.php.net/unsub.php
    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
  • Eli at Oct 19, 2013 at 1:42 pm

    On 10/19/13 4:05 AM, Joe Watkins wrote:
    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
  • Joe Watkins at Oct 19, 2013 at 2:12 pm

    On 10/19/2013 02:42 PM, Eli wrote:
    On 10/19/13 4:05 AM, Joe Watkins wrote:

    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

    Have updated the note with clarity ...

    Cheers
    Joe
  • Joe Watkins at Oct 19, 2013 at 8:32 am

    On 10/18/2013 10:46 PM, Joe Watkins wrote:
    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
  • Joe Watkins at Oct 19, 2013 at 8:58 am

    On 10/19/2013 09:49 AM, Remi Collet wrote:
    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
  • Jakub Zelenka at Oct 19, 2013 at 2:43 pm
    Hi,
    On Fri, Oct 18, 2013 at 10:46 PM, Joe Watkins wrote:

    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<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
  • Joe Watkins at Oct 19, 2013 at 2:46 pm

    On 10/19/2013 03:43 PM, Jakub Zelenka wrote:
    Hi,
    On Fri, Oct 18, 2013 at 10:46 PM, Joe Watkins wrote:

    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<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
    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
  • Joe Watkins at Oct 19, 2013 at 5:03 pm

    On 10/19/2013 03:43 PM, Jakub Zelenka wrote:
    Hi,
    On Fri, Oct 18, 2013 at 10:46 PM, Joe Watkins wrote:

    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<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
    Removed dependency on php_trim ...

    Cheers
    Joe
  • Robert Stoll at Oct 19, 2013 at 10:36 pm
    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
    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



    --
    PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
    http://www.php.net/unsub.php
  • Ferenc Kovacs at Oct 19, 2013 at 11:15 pm

    On Sun, Oct 20, 2013 at 12:36 AM, Robert Stoll wrote:

    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
  • Joe Watkins at Oct 20, 2013 at 7:54 am

    On 10/20/2013 12:15 AM, Ferenc Kovacs wrote:
    On Sun, Oct 20, 2013 at 12:36 AM, Robert Stoll wrote:

    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.
    Yeah, just to confirm, that's correct.

    Cheers
    Joe
  • Joe Watkins at Oct 21, 2013 at 1:52 am

    On 10/20/2013 12:15 AM, Ferenc Kovacs wrote:
    On Sun, Oct 20, 2013 at 12:36 AM, Robert Stoll wrote:

    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.
    Rasmus has pointed out that there is an expect:// stream wrapper.

    So looks like we need a new name ?? Ideas ??

    Cheers
    Joe
  • Robert Williams at Oct 21, 2013 at 2:26 am

    On Oct 20, 2013, at 18:53, "Joe Watkins" wrote:

    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).
  • Matthew Leverton at Oct 21, 2013 at 4:57 am
    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
    On Sun, Oct 20, 2013 at 8:52 PM, Joe Watkins wrote:
    On 10/20/2013 12:15 AM, Ferenc Kovacs wrote:
    On Sun, Oct 20, 2013 at 12:36 AM, Robert Stoll wrote:

    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.
    Rasmus has pointed out that there is an expect:// stream wrapper.

    So looks like we need a new name ?? Ideas ??


    Cheers
    Joe

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Rowan Collins at Oct 21, 2013 at 8:29 am

    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]
  • Julien Pauli at Oct 21, 2013 at 8:01 am

    On Mon, Oct 21, 2013 at 3:52 AM, Joe Watkins wrote:
    On 10/20/2013 12:15 AM, Ferenc Kovacs wrote:

    On Sun, Oct 20, 2013 at 12:36 AM, Robert Stoll wrote:

    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<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.
    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
  • Joe Watkins at Oct 21, 2013 at 8:06 am

    On 10/21/2013 09:01 AM, Julien Pauli wrote:
    On Mon, Oct 21, 2013 at 3:52 AM, Joe Watkins wrote:
    On 10/20/2013 12:15 AM, Ferenc Kovacs wrote:

    On Sun, Oct 20, 2013 at 12:36 AM, Robert Stoll wrote:

    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<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.
    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
    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
  • Patrick Schaaf at Oct 21, 2013 at 8:14 am

    Am 21.10.2013 03:52 schrieb "Joe Watkins" <krakjoe@php.net>:
    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
  • Michael Wallner at Oct 21, 2013 at 8:16 am

    On 21 October 2013 10:13, Patrick Schaaf wrote:
    Am 21.10.2013 03:52 schrieb "Joe Watkins" <krakjoe@php.net>:
    So looks like we need a new name ?? Ideas ??
    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
  • Joe Watkins at Oct 21, 2013 at 8:20 am

    On 10/21/2013 09:16 AM, Michael Wallner wrote:
    On 21 October 2013 10:13, Patrick Schaaf wrote:
    Am 21.10.2013 03:52 schrieb "Joe Watkins" <krakjoe@php.net>:
    So looks like we need a new name ?? Ideas ??
    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...
    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
  • Rparker at Oct 21, 2013 at 8:36 pm

    On 2013-10-21 01:20, Joe Watkins wrote:
    On 10/21/2013 09:16 AM, Michael Wallner wrote:
    On 21 October 2013 10:13, Patrick Schaaf wrote:
    Am 21.10.2013 03:52 schrieb "Joe Watkins" <krakjoe@php.net>:
    So looks like we need a new name ?? Ideas ??
    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...
    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
    This proposal sounds a lot like exceptions to me or am I missing
    something :/
    Could we do something like throw new expectation($expects, $message);
  • Andrea Faulds at Oct 21, 2013 at 8:42 pm

    On 21/10/2013 21:36, rparker@yamiko.org wrote:
    This proposal sounds a lot like exceptions to me or am I missing
    something :/
    Could we do something like throw new expectation($expects, $message);
    Er, T_EXPECT will be essentially a clone of Java and Python's assert
    statement, but not called assert because of the existing assert()
    function (and backwards-compatibility is PHP's middle name).

    Unless you mean the similar name. Well, I don't think "exception" and
    "expect" can be confused (though as someone who used to use Python, I
    keep reading this as "except", Python's equivalent to "catch"), though
    "ExpectationException" might be confusing. I think we should name it
    "AssertionException".

    --
    Andrea Faulds
    http://ajf.me/
  • Joe Watkins at Oct 22, 2013 at 7:23 am

    On 10/21/2013 09:42 PM, Andrea Faulds wrote:
    On 21/10/2013 21:36, rparker@yamiko.org wrote:

    This proposal sounds a lot like exceptions to me or am I missing
    something :/
    Could we do something like throw new expectation($expects, $message);
    Er, T_EXPECT will be essentially a clone of Java and Python's assert
    statement, but not called assert because of the existing assert()
    function (and backwards-compatibility is PHP's middle name).

    Unless you mean the similar name. Well, I don't think "exception" and
    "expect" can be confused (though as someone who used to use Python, I
    keep reading this as "except", Python's equivalent to "catch"), though
    "ExpectationException" might be confusing. I think we should name it
    "AssertionException".
    I think it would be more confusing for expect to throw an
    AssertionException.

    Cheers
    Joe
  • Joe Watkins at Oct 22, 2013 at 6:57 am

    On 10/21/2013 09:36 PM, rparker@yamiko.org wrote:
    On 2013-10-21 01:20, Joe Watkins wrote:
    On 10/21/2013 09:16 AM, Michael Wallner wrote:
    On 21 October 2013 10:13, Patrick Schaaf wrote:
    Am 21.10.2013 03:52 schrieb "Joe Watkins" <krakjoe@php.net>:
    So looks like we need a new name ?? Ideas ??
    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...
    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
    This proposal sounds a lot like exceptions to me or am I missing
    something :/
    Could we do something like throw new expectation($expects, $message);
    Yes, you are missing something.
  • Tjerk Meesters at Oct 21, 2013 at 8:57 am

    On Mon, Oct 21, 2013 at 4:16 PM, Michael Wallner wrote:
    On 21 October 2013 10:13, Patrick Schaaf wrote:
    Am 21.10.2013 03:52 schrieb "Joe Watkins" <krakjoe@php.net>:
    So looks like we need a new name ?? Ideas ??
    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...
    Since we're throwing around terms, here's another one:

    predicate <expr>;

    It should be understood by most programmers what it means (though,
    admittedly, it doesn't carry an obvious severity) and isn't used anywhere
    in the language (afaik).


    --
    Regards,
    Mike

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php

    --
    --
    Tjerk
  • Joe Watkins at Oct 21, 2013 at 9:42 am

    On 10/21/2013 09:57 AM, Tjerk Meesters wrote:
    On Mon, Oct 21, 2013 at 4:16 PM, Michael Wallner wrote:
    On 21 October 2013 10:13, Patrick Schaaf wrote:
    Am 21.10.2013 03:52 schrieb "Joe Watkins" <krakjoe@php.net>:
    So looks like we need a new name ?? Ideas ??
    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...
    Since we're throwing around terms, here's another one:

    predicate <expr>;

    It should be understood by most programmers what it means (though,
    admittedly, it doesn't carry an obvious severity) and isn't used anywhere
    in the language (afaik).


    --
    Regards,
    Mike

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    I suggest we process thusly:

      We need some consensus as to whether this is actually a problem or not
    before we get lost in suggestions ...
      Should we decide it's a problem then we need to decide if using the
    keyword "expected" solves the problem ...
      Should there still be a problem we should compile a short list and get
    a consensus on it before proceeding to make necessary changes.

    So first of all, can we get a quick +|-1 on:

      Using "expect" is a problem
      Using "expected" solves the problem

    We can proceed from there I think ...

    Cheers
    Joe
  • Derick Rethans at Oct 21, 2013 at 9:57 am

    On Fri, 18 Oct 2013, Joe Watkins wrote:

    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 ?
    This is again an RFC that does not even attempt to argue for its
    usefulness. "This functionality was meant to replace the assert() API
    that currently exists in PHP, because of problems replacing it in a
    compatible manner". This doesn't say what is wrong with assert() or
    whether we *need* expect.

    Besides that, why support execptions here. asserts are for testing
    things in development in order not to cock things up. Using exceptions
    for this makes very little sense. All of your examples even promote to
    handle exceptions and continue with excecution. If you want that, just
    use normal if()s with exceptions. I don't see the point of yet another
    syntax extension to do things you can already do just fine.

    cheers,
    Derick
  • Joe Watkins at Oct 21, 2013 at 10:14 am

    On 10/21/2013 10:57 AM, Derick Rethans wrote:
    On Fri, 18 Oct 2013, Joe Watkins wrote:

    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 ?
    This is again an RFC that does not even attempt to argue for its
    usefulness. "This functionality was meant to replace the assert() API
    that currently exists in PHP, because of problems replacing it in a
    compatible manner". This doesn't say what is wrong with assert() or
    whether we *need* expect.

    Besides that, why support execptions here. asserts are for testing
    things in development in order not to cock things up. Using exceptions
    for this makes very little sense. All of your examples even promote to
    handle exceptions and continue with excecution. If you want that, just
    use normal if()s with exceptions. I don't see the point of yet another
    syntax extension to do things you can already do just fine.

    cheers,
    Derick
    The performance of the current assert API is unacceptable during
    development due to the fact it is a function that utilizes strings and
    eval, and cannot be disabled completely during production because it's a
    function not a language construct. This makes it quite devastating to
    deploy, it seems obvious we should seek to replace it.

    We should support exceptions here because it gives a reasonable way to
    manage the error without impacting anything else, without requiring
    module globals, ini settings, or supporting functions in userland.
    By manage I do not necessarily mean continue executing, I mean that it
    is never really acceptable or useful for a web application to quit,
    writing a single exception to standard error. It is useful to be able to
    manage the error to collect more information about the state of the
    application, gain access to a stack trace, and do something actually useful.

    Not all of the examples promote continuing execution, at all, I think
    only one actually does. I mention once that continuing execution is an
    option, just like it is when you catch any other exception.

    Cheers
    Joe
  • Derick Rethans at Oct 22, 2013 at 9:09 am

    On Mon, 21 Oct 2013, Joe Watkins wrote:
    On 10/21/2013 10:57 AM, Derick Rethans wrote:
    On Fri, 18 Oct 2013, Joe Watkins wrote:

    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 ?
    This is again an RFC that does not even attempt to argue for its
    usefulness. "This functionality was meant to replace the assert() API
    that currently exists in PHP, because of problems replacing it in a
    compatible manner". This doesn't say what is wrong with assert() or
    whether we *need* expect.

    Besides that, why support execptions here. asserts are for testing
    things in development in order not to cock things up. Using exceptions
    for this makes very little sense. All of your examples even promote to
    handle exceptions and continue with excecution. If you want that, just
    use normal if()s with exceptions. I don't see the point of yet another
    syntax extension to do things you can already do just fine.
    The performance of the current assert API is unacceptable during
    development due to the fact it is a function that utilizes strings and
    eval, and cannot be disabled completely during production because it's
    a function not a language construct. This makes it quite devastating
    to deploy, it seems obvious we should seek to replace it.
    I wasn't arguing about its merits, only that the RFC should contain the
    whole story of *why* we want to change the language. IMO RFCs often only
    including weak reasons and there needs to be a really strong case (not
    like "I don't like how it works" or "I'd like this to thrown
    exceptions") for changing the *language*. Don't take changing the
    language and/or syntax to lightly.
    We should support exceptions here because it gives a reasonable way to manage
    the error without impacting anything else, without requiring module globals,
    ini settings, or supporting functions in userland.
    Not part of my original email, but I disagree here. An
    assertion/expectation is a last moment resort which should abort an
    application as to prevent harm being done, just like the C library's
    "assert":

    ASSERT(3) Linux Programmer's Manual
    ASSERT(3)

    NAME
            assert - abort the program if assertion is false
    By manage I do not necessarily mean continue executing, I mean that it
    is never really acceptable or useful for a web application to quit,
    writing a single exception to standard error. It is useful to be able
    to manage the error to collect more information about the state of the
    application, gain access to a stack trace, and do something actually
    useful.
    You're contradicting yourself here. You say that you don't necessarily
    want to continue executing, but that's exactly what handling exception
    handling does. You're now changing "assertions" to something that has
    parts that are always available (the exception handling) and things that
    are compiled out (the "expectations") - which doesn't make a lot of
    sense to me. You don't need "expectations" for this as you can already
    do this just fine (by throwing exceptions).

    I'm pretty convinced that expectations *without* exceptions are a good
    idea, as using assert (which is really eval) is a nasty thing that
    should be replaced, but IMO exception throwing should not be part of
    this feature.

    cheers,
    Derick

    --
    http://derickrethans.nl | http://xdebug.org
    Like Xdebug? Consider a donation: http://xdebug.org/donate.php
    twitter: @derickr and @xdebug
    Posted with an email client that doesn't mangle email: alpine
  • Joe Watkins at Oct 22, 2013 at 9:55 am

    On 10/22/2013 10:08 AM, Derick Rethans wrote:
    On Mon, 21 Oct 2013, Joe Watkins wrote:
    On 10/21/2013 10:57 AM, Derick Rethans wrote:
    On Fri, 18 Oct 2013, Joe Watkins wrote:

    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 ?
    This is again an RFC that does not even attempt to argue for its
    usefulness. "This functionality was meant to replace the assert() API
    that currently exists in PHP, because of problems replacing it in a
    compatible manner". This doesn't say what is wrong with assert() or
    whether we *need* expect.

    Besides that, why support execptions here. asserts are for testing
    things in development in order not to cock things up. Using exceptions
    for this makes very little sense. All of your examples even promote to
    handle exceptions and continue with excecution. If you want that, just
    use normal if()s with exceptions. I don't see the point of yet another
    syntax extension to do things you can already do just fine.
    The performance of the current assert API is unacceptable during
    development due to the fact it is a function that utilizes strings and
    eval, and cannot be disabled completely during production because it's
    a function not a language construct. This makes it quite devastating
    to deploy, it seems obvious we should seek to replace it.
    I wasn't arguing about its merits, only that the RFC should contain the
    whole story of *why* we want to change the language. IMO RFCs often only
    including weak reasons and there needs to be a really strong case (not
    like "I don't like how it works" or "I'd like this to thrown
    exceptions") for changing the *language*. Don't take changing the
    language and/or syntax to lightly.
    We should support exceptions here because it gives a reasonable way to manage
    the error without impacting anything else, without requiring module globals,
    ini settings, or supporting functions in userland.
    Not part of my original email, but I disagree here. An
    assertion/expectation is a last moment resort which should abort an
    application as to prevent harm being done, just like the C library's
    "assert":

    ASSERT(3) Linux Programmer's Manual
    ASSERT(3)

    NAME
    assert - abort the program if assertion is false
    By manage I do not necessarily mean continue executing, I mean that it
    is never really acceptable or useful for a web application to quit,
    writing a single exception to standard error. It is useful to be able
    to manage the error to collect more information about the state of the
    application, gain access to a stack trace, and do something actually
    useful.
    You're contradicting yourself here. You say that you don't necessarily
    want to continue executing, but that's exactly what handling exception
    handling does. You're now changing "assertions" to something that has
    parts that are always available (the exception handling) and things that
    are compiled out (the "expectations") - which doesn't make a lot of
    sense to me. You don't need "expectations" for this as you can already
    do this just fine (by throwing exceptions).

    I'm pretty convinced that expectations *without* exceptions are a good
    idea, as using assert (which is really eval) is a nasty thing that
    should be replaced, but IMO exception throwing should not be part of
    this feature.

    cheers,
    Derick
    Morning Derick,

    I'd like to say that, I thought this must be the case, there is no way
    Derick is asking me to justify assertion ... @internals can be a bit
    heated, I dunno why, we are all reasonable chaps :)

    I think C is the wrong direction to look for inspiration here, there are
    plenty of implementations of assertion that do throw exceptions, I've
    linked to them in the RFC yesterday. The reasons should be palatable; an
    exception provides a stack trace, it allows the failure to be graceful.

    It does not promote continuing execution, and if you look with a cool
    head on you can see I done that once, only to show that:
          I have not changed what an exception is,
          that an ExpectationException does change what Zend does,
          that it will not intrude on the expected behaviour of any aspect in
    any case

    The reasons C should immediately abort do not stand here, when an
    assertion fails in C it can do useful things; generate a core dump and
    quit. We cannot do that, we must allow the programmer to collect state
    and other information to help them avoid the same exception again. All
    of the modern implementations of assertion do exactly the same thing,
    even our old implementation takes a callback (requiring module globals
    and all that junk) for what I can only imagine are the same reasons.

    So with the fact established that errors should be manageable, and is it
    a fact; we can do one of two things, we can accept a callback, which
    requires module globals, ini settings, userland functions .. or it we
    can support it where the feature actually is, at the level of Zend, in
    the language.
    It seems elegant and obvious to allow failed assertions to throw
    exceptions and for them to be managed as any other exception in PHP, or
    not - which DOES result in abortion, lets not forget that fact. I'm not
    sure the examples show this, but the majority of them are copied
    verbatim from the Java documentation of the same feature, we appear to
    disagree on the ones I thought I would drop in.

    Perhaps my mistake, I don't know ... to be clear: This is implemented as
    it is in Java and a few other modern implementations besides, I am not
    changing what assertions are, where they should and shouldn't be used
    and what for, it is _exactly_ the same as Java, intended to be used just
    as it is in Java, another high level programming language. Ruby is the
    same, and three independent implementations for various Javascript
    engines, all high level implementations ...

    So certainly, I'm not alone in my assertion; we should definitely use
    exceptions.

    About the lacking info in the RFC, the information you seek to have
    included is actually there, the original thread is referenced, I'm not
    sure it is necessary to reproduce the essence of the conversation in the
    RFC, by the time it was written certain facts seemed all but
    established, so I thought I would start from where we were then, rather
    than from the beginning of the original thread.

    It's all very well to say lets not take implementation or change too
    lightly, but then, we do have an absolutely terrible implementation of
    assertion, that pernicious decision was allowed to pass without anyone
    pointing out that certain things are absolutely required from an
    implementation of assertion for it to be considered useful, it was short
    sighted and unnecessary to include an implementation of something that
    requires support by the engine for it to be usable the way it is
    intended to be used.

    I'm not taking anything lightly, I'm solving an actual problem here, not
    introducing something new, but properly supporting something we are
    documented to support.

    Cheers
    Joe
  • Adam Harvey at Oct 22, 2013 at 5:21 pm

    On 22 October 2013 02:08, Derick Rethans wrote:
    I'm pretty convinced that expectations *without* exceptions are a good
    idea, as using assert (which is really eval) is a nasty thing that
    should be replaced, but IMO exception throwing should not be part of
    this feature.
    I agree that something to replace the eval-based assert() would be
    good. What if the new syntax simply respected assert_options(), and
    assert_options() was extended to support an explicit ASSERT_EXCEPTION
    control option (that presumably took an exception class name as its
    option value)? That seems like it would provide the exception based
    possibilities that some posters want while maintaining the same
    assertion behaviour that users are already used to by default.

    Adam, who apologises if this has been suggested before — this was a
    long set of threads and I've been busy.
  • Joe Watkins at Oct 22, 2013 at 5:32 pm

    On 10/22/2013 06:20 PM, Adam Harvey wrote:
    On 22 October 2013 02:08, Derick Rethans wrote:
    I'm pretty convinced that expectations *without* exceptions are a good
    idea, as using assert (which is really eval) is a nasty thing that
    should be replaced, but IMO exception throwing should not be part of
    this feature.
    I agree that something to replace the eval-based assert() would be
    good. What if the new syntax simply respected assert_options(), and
    assert_options() was extended to support an explicit ASSERT_EXCEPTION
    control option (that presumably took an exception class name as its
    option value)? That seems like it would provide the exception based
    possibilities that some posters want while maintaining the same
    assertion behaviour that users are already used to by default.

    Adam, who apologises if this has been suggested before — this was a
    long set of threads and I've been busy.
    I'm a bit perplexed at the need to retain any compatibility with what is
    a poor implementation ?

    I've mentioned that retaining compatibility is a restriction on this
    implementation, I guess assuming the reasons were obvious. I've brushed
    over them, but to be explicit, backwards compatible means multiple ini
    settings, at least one userland function, module globals, and confusion.
    It means being able to disable and enable assertions at _runtime_,
    impacting the implementation and every op array that uses it in
    _production environments_. All these things make the implementation less
    suitable as an implementation of assertion and I do not see a need to
    restrict it in this way.

    Cheers
    Joe
  • Adam Harvey at Oct 22, 2013 at 5:57 pm

    On 22 October 2013 10:32, Joe Watkins wrote:
    On 10/22/2013 06:20 PM, Adam Harvey wrote:
    I agree that something to replace the eval-based assert() would be
    good. What if the new syntax simply respected assert_options(), and
    assert_options() was extended to support an explicit ASSERT_EXCEPTION
    control option (that presumably took an exception class name as its
    option value)? That seems like it would provide the exception based
    possibilities that some posters want while maintaining the same
    assertion behaviour that users are already used to by default.
    I'm a bit perplexed at the need to retain any compatibility with what is a
    poor implementation ?
    To be fair, I think part of the disconnect here is that I don't feel
    like the current implementation is particularly poor besides the
    eval-based API. I don't really want an assertion failure to throw an
    exception — if I did, I'd use an assert callback or ErrorException to
    do that. I want it logged so I can look at it later, and that's easily
    configured with the current assertion setup.

    I guess I'm wondering if there's a middle ground here, rather than
    throwing the assertion baby out with the bathwater in favour of an
    entirely new thing that could simply be syntax sugar sprinkled over an
    existing, working implementation.

    Adam
  • Joe Watkins at Oct 22, 2013 at 6:07 pm

    On 10/22/2013 06:56 PM, Adam Harvey wrote:
    On 22 October 2013 10:32, Joe Watkins wrote:
    On 10/22/2013 06:20 PM, Adam Harvey wrote:
    I agree that something to replace the eval-based assert() would be
    good. What if the new syntax simply respected assert_options(), and
    assert_options() was extended to support an explicit ASSERT_EXCEPTION
    control option (that presumably took an exception class name as its
    option value)? That seems like it would provide the exception based
    possibilities that some posters want while maintaining the same
    assertion behaviour that users are already used to by default.
    I'm a bit perplexed at the need to retain any compatibility with what is a
    poor implementation ?
    To be fair, I think part of the disconnect here is that I don't feel
    like the current implementation is particularly poor besides the
    eval-based API. I don't really want an assertion failure to throw an
    exception — if I did, I'd use an assert callback or ErrorException to
    do that. I want it logged so I can look at it later, and that's easily
    configured with the current assertion setup.

    I guess I'm wondering if there's a middle ground here, rather than
    throwing the assertion baby out with the bathwater in favour of an
    entirely new thing that could simply be syntax sugar sprinkled over an
    existing, working implementation.

    Adam
    You can catch exceptions, and log them.
    You can do that without impacting everything around you, you can do
    that, or whatever else you like.

    There is one camp saying we want to catch exceptions and have access to
    stack traces and the current scope, others who say that there is no need
    and the application can quit, now some who say they want to log ...

    There is no need for any of this to go on at the level of the
    implementation, it is a restriction on the implementation to do so.

    I can't stress enough how important it is that, used correctly, the
    impact of assertion during development is completely removed at runtime
    in production, completely removed, not by any voodoo, but by core
    software o+. That is of paramount importance for the ideal
    implementation, and we have that right now, there is no convincing
    reason to let it go.

    Cheers
    Joe
  • Patrick Schaaf at Oct 22, 2013 at 6:32 pm

    Am 22.10.2013 20:07 schrieb "Joe Watkins" <krakjoe@php.net>:
    You can catch exceptions, and log them.
    You can do that without impacting everything around you, you can do that,
    or whatever else you like.

    You can do that handling when you have only a few toplevel scripts, like
    when you have a setup with a small number of toplevel controllers and
    almost no CLI stuff around. But due to the scoped nature of try/catch you
    cannot reasonably / painlessly do that when you have 270 toplevel web and
    CLI entry points that then each need such a try/catch block.

    Also, there is the problem with catch (Exception) blocks, which you might
    easily dismiss as bad form, but which I'm sure are widespread in the field
    - I certainly know they are in our codebase...

    On the other hand, setup of an assertion-failed callback can easily go into
    an auto_prepend file, or into any other standard include (autoloader or
    something) you might have - exactly because it is something done on the
    global level instead of the scoped try/catch requirement. And IF you like
    the exception thing you can make that callback throw whatever you like -
    but you do not force that model on everybody.

    Furthermore such an assertion-failed callback has exactly the same change
    of looking at backtraces, so touting that as a singular feature of the
    exception approach is not valid.

    Finally, with the exception approach it is simply not true that it will
    completely go away in production - because these try/catch blocks will be
    present for any code that wants to handle the issue, and you cannot make
    those go away.

    I'm all for an assert alternative that works with expressions instead of
    eval, and that completely goes away in the opcode (cache) when disabled in
    production.

    best regards
       Patrick
  • Nikita Popov at Oct 22, 2013 at 6:41 pm

    On Tue, Oct 22, 2013 at 8:32 PM, Patrick Schaaf wrote:

    Am 22.10.2013 20:07 schrieb "Joe Watkins" <krakjoe@php.net>:
    You can catch exceptions, and log them.
    You can do that without impacting everything around you, you can do that,
    or whatever else you like.

    You can do that handling when you have only a few toplevel scripts, like
    when you have a setup with a small number of toplevel controllers and
    almost no CLI stuff around. But due to the scoped nature of try/catch you
    cannot reasonably / painlessly do that when you have 270 toplevel web and
    CLI entry points that then each need such a try/catch block.

    Also, there is the problem with catch (Exception) blocks, which you might
    easily dismiss as bad form, but which I'm sure are widespread in the field
    - I certainly know they are in our codebase...

    On the other hand, setup of an assertion-failed callback can easily go into
    an auto_prepend file, or into any other standard include (autoloader or
    something) you might have - exactly because it is something done on the
    global level instead of the scoped try/catch requirement.
    If you want to handle uncaught exceptions via auto_prepend_file you can use
    set_exception_handler(). It will register a global handler that is invoked
    on an uncaught exception. So you can have your functionality, if that's how
    you like to handle things, but you also have the option of fine-grained
    control of assertion failures by use of catch-blocks. One use case that I
    have repeatedly mentioned in the previous thread is that PHPUnit will want
    to catch the assertion failure but still continue running other tests.

    Generally anything that uses a global handler (e.g. for assertion
    failures...) turns out to be a PITA when you try to combine multiple
    libraries which want different handlers. In the end you can't really use
    any such handlers in a portable library. I'd like assertions to be usable
    in libraries.

    Thanks,
    Nikita
  • Patrick Schaaf at Oct 22, 2013 at 6:47 pm

    Am 22.10.2013 20:41 schrieb "Nikita Popov" <nikita.ppv@gmail.com>:
    If you want to handle uncaught exceptions via auto_prepend_file you can
    use set_exception_handler(). It will register a global handler that is
    invoked on an uncaught exception.

    Fair enough, thanks.
    Generally anything that uses a global handler (e.g. for assertion
    failures...) turns out to be a PITA when you try to combine multiple
    libraries which want different handlers. In the end you can't really use
    any such handlers in a portable library. I'd like assertions to be usable
    in libraries.

    How do you envision that to work in practise with the exception approach?
    Make every externally visible function and method in the library contain a
    suitable try/catch block?

    best regards
       Patrick
  • Joe Watkins at Oct 22, 2013 at 6:47 pm

    On 10/22/2013 07:32 PM, Patrick Schaaf wrote:
    Am 22.10.2013 20:07 schrieb "Joe Watkins" <krakjoe@php.net>:
    You can catch exceptions, and log them.
    You can do that without impacting everything around you, you can do that,
    or whatever else you like.

    You can do that handling when you have only a few toplevel scripts, like
    when you have a setup with a small number of toplevel controllers and
    almost no CLI stuff around. But due to the scoped nature of try/catch you
    cannot reasonably / painlessly do that when you have 270 toplevel web and
    CLI entry points that then each need such a try/catch block.

    Also, there is the problem with catch (Exception) blocks, which you might
    easily dismiss as bad form, but which I'm sure are widespread in the field
    - I certainly know they are in our codebase...

    On the other hand, setup of an assertion-failed callback can easily go into
    an auto_prepend file, or into any other standard include (autoloader or
    something) you might have - exactly because it is something done on the
    global level instead of the scoped try/catch requirement. And IF you like
    the exception thing you can make that callback throw whatever you like -
    but you do not force that model on everybody.

    Furthermore such an assertion-failed callback has exactly the same change
    of looking at backtraces, so touting that as a singular feature of the
    exception approach is not valid.

    Finally, with the exception approach it is simply not true that it will
    completely go away in production - because these try/catch blocks will be
    present for any code that wants to handle the issue, and you cannot make
    those go away.

    I'm all for an assert alternative that works with expressions instead of
    eval, and that completely goes away in the opcode (cache) when disabled in
    production.

    best regards
    Patrick
    I was pretty explicit: used properly.

    We are going round in circles, discussing what assertion should be used
    for, again.

    Production code should _NOT_ have catch blocks everywhere to manage
    exceptions that will NEVER be thrown, obviously.

    assertion is a debug and development feature, if you take code to
    production that catches exceptions that your configuration does not
    allow to be thrown then that's pretty silly.

    assertion should be used during development, in development environments
    where it is enabled, by the time your code goes to production it should
    not suffer ExpectationExceptions and cannot anyway.

    I think this thread and the RFC now contains enough information
    regarding exceptions, it is now covered ground.

    Cheers
    Joe
  • Joe Watkins at Oct 22, 2013 at 7:13 pm

    On 10/22/2013 07:59 PM, Patrick Schaaf wrote:
    Production code should _NOT_ have catch blocks everywhere to manage
    exceptions that will NEVER be thrown, obviously.
    assertion is a debug and development feature, if you take code to
    production that catches exceptions that your configuration does not
    allow to be thrown then that's pretty silly.

    Ah so you would only add such catch blocks during development, after
    you've seen an assertion. Similar to how I'm used to add logging
    (printf style debugging for C programmers) in suitable places.

    ...

    best regards
    Patrick
    Yes, definitely.

    I assumed this was clear; it's not a replacement for normal logic, it's
    a debugging and development aid, just like everywhere else.

    catch() here is no added fat, we don't need to do anything, especially
    anything that affects production in order to provide a decent way of
    debugging the failure, using the stack trace, accessing the scope, all
    on a designated code path.

    Failed assertions are a sign of broken programming, not a sign to take a
    different code path during execution, but a sign that development must
    go on a little longer :)

    Cheers
    Joe
  • Joe Watkins at Oct 22, 2013 at 7:59 pm

    On 10/22/2013 08:37 PM, Patrick Schaaf wrote:
    Failed assertions are a sign of broken programming, not a sign to
    take a different code path during execution, but a sign that
    development must go on a little longer :)

    Definitely, that's not something I ever wanted to imply would be
    otherwise.
    I have updated the RFC, there is a misleading example that I regret
    putting in, I have cleaned it up.

    I have put in a section about production time too, to clarify a few things.

    I hope everything is clear now ... and I hope too that I'm changing
    minds ...

    Patrick mentioned something I think is worth bringing up, that's core
    dumps. We can't do core dumps from Zend, there's no infrastructure to
    support it, and while it wouldn't require much to get a minimal one
    going, there is already a platform used to actually debug PHP, and it
    comes with well tested infrastructure. If certain people were a bit more
    on board, we could entertain the idea of overriding the opcode handler
    with xdebug and generating that coredump, or something like a coredump,
    I'd certainly be willing to put some effort into that and don't know how
    much of it is already possible with xdebug ... but no pressure, whatever
    ....

    Cheers
    Joe
  • Joe Watkins at Oct 21, 2013 at 2:33 pm

    On 10/21/2013 02:27 PM, Hochstrasser Christoph wrote:
    Hi Derick,
    This is again an RFC that does not even attempt to argue for its
    usefulness. "This functionality was meant to replace the assert() API
    that currently exists in PHP, because of problems replacing it in a
    compatible manner". This doesn't say what is wrong with assert() or
    whether we *need* expect.
    The RFC was first proposed as a RFC to replace the "assert()" function with a "assert" keyword (which produces an opcode) in order to fix the unacceptable performance of the current "assert()" implementation. See also https://wiki.php.net/rfc/expectations#performance

    Later it was renamed to "expect" because the overall opinion was that changing "assert()" can't be done in 5.x.

    Yes, this RFC could state more clearly what its purpose is, but it certainly has usefulness. It's a lot faster than "assert()", when turned off "expect" becomes a NOOP, and it doesn't rely on "eval()".
    Morning,

          I'm not so good at conveying ideas; the explanation you have there
    is a summarized version of the java documentation of the same idea, the
    implementations are so similar they could be called identical.

          So everyone has a clear idea of how this works, here's some detail
    about the op array for the statement "expect false;":

          Optimizations=On Expectations=On (DEVELOPMENT):

              opcodes[2]

                  opcodes[0] -> ZEND_EXPCT expression
                  opcodes[1] -> ZEND_RETURN

           Optimizations=Off Expectations=On:

              opcodes[9]

                   opcodes[0]-opcodes[6] -> ZEND_NOP
                   opcodes[7] -> ZEND_EXPCT expression
                   opcodes[8] -> ZEND_RETURN

          Optimizations=On Expectations=Off (PRODUCTION)

              opcodes[1]

                    opcodes[0] -> ZEND_RETURN

           Optimizations=Off Expectations=Off:

              opcodes[8]

                     opcodes[0] -> ZEND_JMP opcodes[7]
                     opcodes[1]-opcodes[6] -> ZEND_NOP
                     opcodes[7] -> ZEND_RETURN

           The same opcodes for "assert("false")":

            Optimizations=Either Assertions=Either (LEGACY):

              opcodes[3]

                      opcodes[0] -> ZEND_SEND_VAL string
                      opcodes[1] -> ZEND_DO_FCALL assert
                      opcodes[2] -> ZEND_RETURN

             When Assertions=Off opcodes[1] does not result in a call to
    eval, but the actual call to assert cannot be optimized, dragging down
    production considerably.

    Cheers
    Joe
  • Nicolas Grekas at Oct 21, 2013 at 2:49 pm
    Just an idea: rather than looking for a new keyword, would it be possible
    to create a new syntax that uses assert in a non conflicting way for BC?

    Like :


    T_ASSERT '?' expression ':' message ';'

    T_ASSERT ':' expression ';'


    Or anything else with this characteristics.
  • Joe Watkins at Oct 21, 2013 at 3:06 pm

    On 10/21/2013 03:49 PM, Nicolas Grekas wrote:
    Just an idea: rather than looking for a new keyword, would it be possible
    to create a new syntax that uses assert in a non conflicting way for BC?

    Like :


    T_ASSERT '?' expression ':' message ';'

    T_ASSERT ':' expression ';'


    Or anything else with this characteristics.
    Syntax isn't the only thing in conflict, I think that the syntax problem
    is not worth working around, because it would still leave unsolved the
    matter of incompatible API's and approaches to assertion/errors ... just
    provide a better solution and deprecate the old API at sometime in the
    future ...

    Cheers
    Joe
  • Joe Watkins at Oct 22, 2013 at 1:18 pm

    On 10/21/2013 03:33 PM, Joe Watkins wrote:
    On 10/21/2013 02:27 PM, Hochstrasser Christoph wrote:
    Hi Derick,
    This is again an RFC that does not even attempt to argue for its
    usefulness. "This functionality was meant to replace the assert() API
    that currently exists in PHP, because of problems replacing it in a
    compatible manner". This doesn't say what is wrong with assert() or
    whether we *need* expect.
    The RFC was first proposed as a RFC to replace the "assert()" function
    with a "assert" keyword (which produces an opcode) in order to fix the
    unacceptable performance of the current "assert()" implementation. See
    also https://wiki.php.net/rfc/expectations#performance

    Later it was renamed to "expect" because the overall opinion was that
    changing "assert()" can't be done in 5.x.

    Yes, this RFC could state more clearly what its purpose is, but it
    certainly has usefulness. It's a lot faster than "assert()", when
    turned off "expect" becomes a NOOP, and it doesn't rely on "eval()".
    Morning,

    I'm not so good at conveying ideas; the explanation you have there
    is a summarized version of the java documentation of the same idea, the
    implementations are so similar they could be called identical.

    So everyone has a clear idea of how this works, here's some detail
    about the op array for the statement "expect false;":

    Optimizations=On Expectations=On (DEVELOPMENT):

    opcodes[2]

    opcodes[0] -> ZEND_EXPCT expression
    opcodes[1] -> ZEND_RETURN

    Optimizations=Off Expectations=On:

    opcodes[9]

    opcodes[0]-opcodes[6] -> ZEND_NOP
    opcodes[7] -> ZEND_EXPCT expression
    opcodes[8] -> ZEND_RETURN

    Optimizations=On Expectations=Off (PRODUCTION)

    opcodes[1]

    opcodes[0] -> ZEND_RETURN

    Optimizations=Off Expectations=Off:

    opcodes[8]

    opcodes[0] -> ZEND_JMP opcodes[7]
    opcodes[1]-opcodes[6] -> ZEND_NOP
    opcodes[7] -> ZEND_RETURN

    The same opcodes for "assert("false")":

    Optimizations=Either Assertions=Either (LEGACY):

    opcodes[3]

    opcodes[0] -> ZEND_SEND_VAL string
    opcodes[1] -> ZEND_DO_FCALL assert
    opcodes[2] -> ZEND_RETURN

    When Assertions=Off opcodes[1] does not result in a call to
    eval, but the actual call to assert cannot be optimized, dragging down
    production considerably.

    Cheers
    Joe
    When I wrote this it seemed wrong that there was padding ... and it was
    wrong, and it's since removed ...

    Below is corrected information which I shall include in the RFC.

    So everyone has a clear idea of how this works, here's some detail about
    the op array for the statement "expect false;":

            Optimizations=On Expectations=On (DEVELOPMENT):

                opcodes[2]

                    opcodes[0] -> ZEND_EXPCT expression
                    opcodes[1] -> ZEND_RETURN

             Optimizations=Off Expectations=On:

                opcodes[3]

                     opcodes[0] -> ZEND_NOP
                     opcodes[1] -> ZEND_EXPCT expression
                     opcodes[2] -> ZEND_RETURN

            Optimizations=On Expectations=Off (PRODUCTION)

                opcodes[1]

                      opcodes[0] -> ZEND_RETURN

             Optimizations=Off Expectations=Off:

                opcodes[2]

                       opcodes[0] -> ZEND_JMP opcodes[1]
                       opcodes[1] -> ZEND_RETURN

             The same opcodes for "assert("false")":

              Optimizations=Either Assertions=Either (LEGACY):

                opcodes[3]

                        opcodes[0] -> ZEND_SEND_VAL string
                        opcodes[1] -> ZEND_DO_FCALL assert
                        opcodes[2] -> ZEND_RETURN

               When Assertions=Off opcodes[1] does not result in a call to
       eval, but the actual call to assert cannot be optimized, dragging down
       production considerably.

    Cheers
    Joe
  • Andrea Faulds at Oct 21, 2013 at 10:33 am
    -1 to "expect is a problem". expect is not a problem.
    Le 21 octobre 2013 à 10:42, Joe Watkins <krakjoe@php.net> a écrit :

    On 10/21/2013 09:57 AM, Tjerk Meesters wrote:
    On Mon, Oct 21, 2013 at 4:16 PM, Michael Wallner wrote:
    On 21 October 2013 10:13, Patrick Schaaf wrote:
    Am 21.10.2013 03:52 schrieb "Joe Watkins" <krakjoe@php.net>:
    So looks like we need a new name ?? Ideas ??
    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...
    Since we're throwing around terms, here's another one:

    predicate <expr>;

    It should be understood by most programmers what it means (though,
    admittedly, it doesn't carry an obvious severity) and isn't used anywhere
    in the language (afaik).


    --
    Regards,
    Mike

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    I suggest we process thusly:

    We need some consensus as to whether this is actually a problem or not
    before we get lost in suggestions ...
    Should we decide it's a problem then we need to decide if using the
    keyword "expected" solves the problem ...
    Should there still be a problem we should compile a short list and get
    a consensus on it before proceeding to make necessary changes.

    So first of all, can we get a quick +|-1 on:

    Using "expect" is a problem
    Using "expected" solves the problem

    We can proceed from there I think ...

    Cheers
    Joe





    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Joe Watkins at Nov 1, 2013 at 2:37 am

    On 10/18/2013 10:46 PM, Joe Watkins wrote:
    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
    Evening,

      Wanted to bring this up for vote, any objections ?

    Cheers

Related Discussions

People

Translate

site design / logo © 2022 Grokbase