Hi Joe,
I think, we may just add additional vote question.
- If we like to custom exceptons as second argument?
but I don't care about it, so do as you like.
According to AssertException: add a note into Open Issues section.
e.g. we may introduce new abstract class BaseException
then make Except
Morning,
I hear the concern regarding custom exceptions. Things will be used badly
whatever. It's easy to imagine that in a simple application you just don't
need to specify custom exceptions. But in a large codebase, being able to
structure exceptions is invaluable, it gives documentation referen
On Wed, Feb 18, 2015 at 5:44 PM, Nikita Popov wrote:
> On Tue, Feb 17, 2015 at 10:50 PM, Dmitry Stogov wrote:
>
>> Hi Joe
>>
>> The patch is ready https://github.com/php/php-src/pull/1088/files
>>
>> 1) I implemented AST pretty-printer to reconstruct the source. It may be
>> reused in Reflection
On Tue, Feb 17, 2015 at 10:50 PM, Dmitry Stogov wrote:
> Hi Joe
>
> The patch is ready https://github.com/php/php-src/pull/1088/files
>
> 1) I implemented AST pretty-printer to reconstruct the source. It may be
> reused in Reflection and other places through
>
> ZEND_API zend_string *zend_ast_exp
OK thanks.
I'm switching to another task :)
Thanks. Dmitry.
On Wed, Feb 18, 2015 at 10:16 AM, Joe Watkins wrote:
> Updated RFC as requested.
>
> I'm just going to wait to hear what Nikita says, especially about
> optimizing away unqualified calls to assert.
> I guess this could be viewed as
Updated RFC as requested.
I'm just going to wait to hear what Nikita says, especially about
optimizing away unqualified calls to assert.
I guess this could be viewed as a BC break, it seems like quite a nice
break but not sure.
Will open voting when we hear from Nikita.
Cheers
Joe
On Wed, Feb 1
Will update RFC today, thanks for working on it Dmitry :)
Cheers
Joe
On Tue, Feb 17, 2015 at 9:50 PM, Dmitry Stogov wrote:
> Hi Joe
>
> The patch is ready https://github.com/php/php-src/pull/1088/files
>
> 1) I implemented AST pretty-printer to reconstruct the source. It may be
> reused in Refl
Hi Joe
The patch is ready https://github.com/php/php-src/pull/1088/files
1) I implemented AST pretty-printer to reconstruct the source. It may be
reused in Reflection and other places through
ZEND_API zend_string *zend_ast_export(const char *prefix, zend_ast *ast,
const char *suffix);
2) zend.a
On Tue, Feb 17, 2015 at 5:11 PM, Nikita Popov wrote:
> On Mon, Feb 16, 2015 at 4:47 PM, Dmitry Stogov wrote:
>
>> Hi Nikita,
>>
>> it looks like a part of old implementation is not trivial with new AST
>> compiler.
>>
>> previously we translated assert(condition) into assert(condition,
>> "asser
On Mon, Feb 16, 2015 at 4:47 PM, Dmitry Stogov wrote:
> Hi Nikita,
>
> it looks like a part of old implementation is not trivial with new AST
> compiler.
>
> previously we translated assert(condition) into assert(condition,
> "assert(condition)").
> actually we just captured a part of input buffe
Hi Nikita,
it looks like a part of old implementation is not trivial with new AST
compiler.
previously we translated assert(condition) into assert(condition,
"assert(condition)").
actually we just captured a part of input buffer and added missing string
argument.
Is there a simple way to do the
> is there any penalty of catch-AssertionException-blocks? Are those
eliminated in production code?
Assertions should never be enabled in production code, the ability to catch
(and enable by configuration) the exception serves the developer of the
code during development only.
The example code is
On Mon, Feb 16, 2015 at 10:37 AM, Joe Watkins wrote:
> Morning internals,
>
> I've had mostly negative feedback on the design-by-contract idea, maybe
> it's a step too far.
>
> The expectations RFC in its current form proposes that we introduce
> zero-cost assertions, which are compatible
Hi Joe,
is there any penalty of catch-AssertionException-blocks? Are those
eliminated in production code?
Thanks
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Martin,
On Mon, Feb 16, 2015 at 6:59 PM, Martin Jansen wrote:
> On 16.02.15 10:37, Joe Watkins wrote:
> > Please review the RFC, and provide feedback, if there are no strong
> > objections we will go ahead with a vote when the patch is ready, in the
> > coming days.
> >
> > https://wi
On 16.02.15 10:37, Joe Watkins wrote:
> Please review the RFC, and provide feedback, if there are no strong
> objections we will go ahead with a vote when the patch is ready, in the
> coming days.
>
> https://wiki.php.net/rfc/expectations
I like it. But why do those two INI settings use d
> -Original Message-
> From: yohg...@gmail.com [mailto:yohg...@gmail.com] On Behalf Of Yasuo
> Ohgaki
> Sent: Monday, February 16, 2015 11:45 AM
> To: Joe Watkins
> Cc: PHP internals
> Subject: Re: [PHP-DEV] RFC: Expectations
>
> Hi Joe,
>
> On Mon, Feb
Hi Joe,
On Mon, Feb 16, 2015 at 6:37 PM, Joe Watkins wrote:
> I've had mostly negative feedback on the design-by-contract idea, maybe
> it's a step too far.
>
I think introducing strict type safety for DbC like static/compiled
languages
is too far. I agree.
The expectations RFC in its
Morning internals,
I've had mostly negative feedback on the design-by-contract idea, maybe
it's a step too far.
The expectations RFC in its current form proposes that we introduce
zero-cost assertions, which are compatible with the current assertion API.
Since this has been in discus
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
On 10/22/2013 07:32 PM, Patrick Schaaf wrote:
Am 22.10.2013 20:07 schrieb "Joe Watkins" :
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 scr
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_EXCE
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 somethi
On 10/21/2013 09:42 PM, Andrea Faulds wrote:
On 21/10/2013 21:36, rpar...@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
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 op
On 21/10/2013 21:36, rpar...@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 as
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 abs
-1 to "expect is a problem". expect is not a problem.
> Le 21 octobre 2013 à 10:42, Joe Watkins 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.201
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 do
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 tha
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" :
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
On 21 October 2013 10:13, Patrick Schaaf wrote:
> Am 21.10.2013 03:52 schrieb "Joe Watkins" :
>>
>> 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-b
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 summ
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" :
> >>
> >> So looks like we need a new name ?? Ideas ??
> >
> > abstract EXPRESSION
>
> wat?
>
>
> > abstract is already a keyword, so no BC.
>
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 "Ex
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
36 matches
Mail list logo
