Am 28.02.2015 um 20:08 schrieb Patrick Schaaf:
Am 28.02.2015 19:32 schrieb Crypto Compress
cryptocompr...@googlemail.com mailto:cryptocompr...@googlemail.com:
class BankAccount {
function Add($amount) {
assert($amount 0);
// ... code block ...
}
}
Now the
Am 28.02.2015 19:32 schrieb Crypto Compress cryptocompr...@googlemail.com
:
class BankAccount {
function Add($amount) {
assert($amount 0);
// ... code block ...
}
}
Now the programmer implementing code block to gracefully handle $amount
0 has a problem. There is
Am 21.02.2015 um 04:10 schrieb Yasuo Ohgaki:
Hi Crypto,
On Fri, Feb 20, 2015 at 11:02 PM, Crypto Compress
cryptocompr...@googlemail.com mailto:cryptocompr...@googlemail.com
wrote:
AssertionExceptions are not intended to be caught, they are
intended to be seen, in a specific
Hi Crypto,
On Sun, Mar 1, 2015 at 3:32 AM, Crypto Compress
cryptocompr...@googlemail.com wrote:
sorry for the late answer. My point is about throwing exceptions
(assert.exceptions=1). I think it is wrong to allow to change code-flow by
ini-setting and in current context it is wrong to throw
Morning Internals,
As mentioned on the RFC, voting finished last night at midnight.
The vote passed with a majority (50%+) in favour of custom exceptions,
however ...
When the patch was originally written assert (expect) was a language
construct, and so the exception message wasn't
On Thu, Feb 19, 2015 at 2:09 AM, Joe Watkins pthre...@pthreads.org wrote:
The expectations RFC is now in voting phase:
https://wiki.php.net/rfc/expectations#vote
This announcement doesn't say when voting will close and the RFC
doesn't either. When do you expect voting to close?
--
PHP
Le 19/02/2015 10:09, Joe Watkins a écrit :
The expectations RFC is now in voting phase:
https://wiki.php.net/rfc/expectations#vote
Hi,
While talking about this RFC with other people of AFUP, we discussed
about assert()... And mostly ended up against it.
Still, note we probably
Hi!
I do not see much gain today to improve them while I do not see why we
should not. It does not hurt.
The gain is simple - today, assertions have costs so people that are
performance-conscious (rightly or wrongly) use them less than they
could. We can make them cost-less in production,
Hi Pierre,
On Sun, Feb 22, 2015 at 2:53 AM, Pierre Joye pierre@gmail.com wrote:
Assertion is only for development and testing.
We need errors or exceptions during development and testing, but
not in production. Therefore, errors/exception should not be catched
by code in general.
On Feb 21, 2015 1:54 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Pierre,
On Sun, Feb 22, 2015 at 2:53 AM, Pierre Joye pierre@gmail.com wrote:
Assertion is only for development and testing.
We need errors or exceptions during development and testing, but
not in production.
On Fri, Feb 20, 2015 at 7:10 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Crypto,
On Fri, Feb 20, 2015 at 11:02 PM, Crypto Compress
cryptocompr...@googlemail.com wrote:
AssertionExceptions are not intended to be caught, they are intended to be
seen, in a specific environment.
Joe, your
On 20 February 2015 at 08:47, Markus Fischer mar...@fischer.name wrote:
This sounds two-folded to me: very cool (albeit I can't see a use-case
right now) on one hand and utter magic on the other.
Inclined to agree.
@Joe what use-case prompted this feature?
--
PHP Internals - PHP Runtime
I work on a massive codebase, 3m loc, the ability to document that we throw
SomeAssertionException in *insert circumstance* is extremely appealing. It
would allow us to structure the documentation and the code in a way that
really makes sense especially for new developers. The alternatives are not
Also, we don't optimize those away, it would not be sensible, because it's
not sensible to deploy those catch blocks in the first place.
Cheers
Joe
On Fri, Feb 20, 2015 at 8:38 AM, Joe Watkins pthre...@pthreads.org wrote:
The custom exception must derive from AssertionException, so the same
On 19.02.15 16:23, Dmitry Stogov wrote:
- how does zend.assertions and assert.exceptions work with
assert_options() , i.e. isn't the exception behavior meant to be an
addition to assert_options() too ?
zend.assertions control assert() compilation and execution
zend.assertions=-1
The custom exception must derive from AssertionException, so the same
optimization is possible.
Cheers
Joe
On Fri, Feb 20, 2015 at 8:28 AM, Xinchen Hui larue...@php.net wrote:
Hey:
On Thu, Feb 19, 2015 at 5:09 PM, Joe Watkins pthre...@pthreads.org
wrote:
Morning internals,
The
Hey:
On Thu, Feb 19, 2015 at 5:09 PM, Joe Watkins pthre...@pthreads.org wrote:
Morning internals,
The expectations RFC is now in voting phase:
https://wiki.php.net/rfc/expectations#vote
sorry, the thread is too long to read.. I am not sure whether there
was some similar opinion
Am 20.02.2015 09:47 schrieb Joe Watkins pthre...@pthreads.org:
Also, we don't optimize those away, it would not be sensible, because it's
not sensible to deploy those catch blocks in the first place.
So, do they become FATAL with production settings? Ideally a parse error
(ideally, because
The alternatives are not nice, in my opinion.
What are this alternatives? What are the drawbacks of warning in
production code?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
can you please explain a bit more how you would achieve this in 3m loc?
AssertionExceptions are not intended to be caught, they are intended to be
seen, in a specific environment.
It doesn't really make sense to commit/deploy code that catches
AssertionExceptions knowing that the code is
Am 20.02.2015 um 12:27 schrieb Joe Watkins:
I work on a massive codebase, 3m loc, the ability to document that we throw
SomeAssertionException in *insert circumstance* is extremely appealing. It
would allow us to structure the documentation and the code in a way that
really makes sense
AssertionExceptions are not intended to be caught, they are intended
to be seen, in a specific environment.
Joe, your argumentation is around how (not) to use exceptions. I can see
your point and it's valid.
My point is about not to implement exceptions at all.
If exceptions are not
On Fri, Feb 20, 2015 at 3:02 PM, Crypto Compress
cryptocompr...@googlemail.com wrote:
AssertionExceptions are not intended to be caught, they are intended to
be seen, in a specific environment.
Joe, your argumentation is around how (not) to use exceptions. I can see
your point and it's
On Thu, Feb 19, 2015 at 7:00 AM, Pierre Joye pierre@gmail.com wrote:
On Thu, Feb 19, 2015 at 1:09 AM, Joe Watkins pthre...@pthreads.org wrote:
Morning internals,
The expectations RFC is now in voting phase:
https://wiki.php.net/rfc/expectations#vote
I totally miss the Expectation
Am 20.02.2015 um 15:09 schrieb Nikita Popov:
On Fri, Feb 20, 2015 at 3:02 PM, Crypto Compress
cryptocompr...@googlemail.com mailto:cryptocompr...@googlemail.com
wrote:
AssertionExceptions are not intended to be caught, they are
intended to be seen, in a specific environment.
Hi Crypto,
On Fri, Feb 20, 2015 at 11:02 PM, Crypto Compress
cryptocompr...@googlemail.com wrote:
AssertionExceptions are not intended to be caught, they are intended to be
seen, in a specific environment.
Joe, your argumentation is around how (not) to use exceptions. I can see
your point
To be harsh: All comments in favour of throwing exceptions here,
substantiate theirs needs with dead, never reached and potentially buggy
code.
The *changed code flow in production* is the big pitfall of this RFC and
an absolute no-go. I like zero-cost assertions but throwing exceptions
is
However I think it is pre
mature to vote on as there was (sorry) not explicit discussions about
it.
I haven't heard that from anyone else, the RFC is plenty old.
A couple of things are unclear. See the numerous questions in this thread.
I also do not like other things.
These don't seem like
On Fri, Feb 20, 2015 at 7:29 AM, Joe Watkins pthre...@pthreads.org wrote:
However I think it is pre
mature to vote on as there was (sorry) not explicit discussions about
it.
I haven't heard that from anyone else, the RFC is plenty old.
A couple of things are unclear. See the numerous
So it is fine to have one setting doing the exact same thing? Sorry, I
disagree. We know we need that in other areas. Like other recent RFCs,
we have solved them bottom-up. This one is no different.
It's fine for an RFC to be focused on one thing. This is another subject.
So basically what
On Fri, Feb 20, 2015 at 8:36 AM, Joe Watkins pthre...@pthreads.org wrote:
No, we did not
Yes, we did, which you could have found out, if you were really bothered:
https://marc.info/?l=php-internalsm=138213285708117w=2
You are kidding me here and I already answered to that:
2013-10-18
On Fri, Feb 20, 2015 at 8:24 AM, Joe Watkins pthre...@pthreads.org wrote:
So it is fine to have one setting doing the exact same thing? Sorry, I
disagree. We know we need that in other areas. Like other recent RFCs,
we have solved them bottom-up. This one is no different.
It's fine for an RFC
No, we did not
Yes, we did, which you could have found out, if you were really bothered:
https://marc.info/?l=php-internalsm=138213285708117w=2
Cheers
Joe
On Fri, Feb 20, 2015 at 4:31 PM, Pierre Joye pierre@gmail.com wrote:
On Fri, Feb 20, 2015 at 8:24 AM, Joe Watkins
On 19 February 2015 at 01:09, Joe Watkins pthre...@pthreads.org wrote:
The expectations RFC is now in voting phase:
https://wiki.php.net/rfc/expectations#vote
Sorry, I had an e-mail backlog while this was in discussion, so I'm
only getting around to this now. Two thoughts:
1. This is
Morning internals,
The expectations RFC is now in voting phase:
https://wiki.php.net/rfc/expectations#vote
Cheers
Joe
There isn't legitimate technical justification for or against using custom
exceptions.
Since it's entirely based on preference, and the kind of utilitarian
argument you can make for their use,
it's acceptable that this is resolved as part of the vote.
It's not a huge deal.
Cheers
Joe
On Thu,
On Thu, Feb 19, 2015 at 5:47 PM, Markus Fischer mar...@fischer.name wrote:
Hi,
On 19.02.15 10:09, Joe Watkins wrote:
Morning internals,
The expectations RFC is now in voting phase:
https://wiki.php.net/rfc/expectations#vote
- I somehow miss information what the exact differences
On Thu, Feb 19, 2015 at 7:16 AM, Dmitry Stogov dmi...@zend.com wrote:
On Thu, Feb 19, 2015 at 6:00 PM, Pierre Joye pierre@gmail.com wrote:
On Thu, Feb 19, 2015 at 1:09 AM, Joe Watkins pthre...@pthreads.org
wrote:
Morning internals,
The expectations RFC is now in voting phase:
On Thu, Feb 19, 2015 at 7:45 AM, Pierre Joye pierre@gmail.com wrote:
On Thu, Feb 19, 2015 at 7:16 AM, Dmitry Stogov dmi...@zend.com wrote:
On Thu, Feb 19, 2015 at 6:00 PM, Pierre Joye pierre@gmail.com wrote:
On Thu, Feb 19, 2015 at 1:09 AM, Joe Watkins pthre...@pthreads.org
wrote:
On 19 February 2015 at 15:45, Pierre Joye pierre@gmail.com wrote:
Still, no announce for a discussion about this specific RFC. And
really, the content of the RFC is almost empty, pointing to the ML
archive is really not the right way :)
There was an RFC announce thread 3 days ago. I agree
Hi,
On 19.02.15 10:09, Joe Watkins wrote:
Morning internals,
The expectations RFC is now in voting phase:
https://wiki.php.net/rfc/expectations#vote
- I somehow miss information what the exact differences are to the
current implementation, to better judge the impact.
- how does
On Thu, Feb 19, 2015 at 1:09 AM, Joe Watkins pthre...@pthreads.org wrote:
Morning internals,
The expectations RFC is now in voting phase:
https://wiki.php.net/rfc/expectations#vote
I totally miss the Expectation RFC announcement. Where the RFC was
actually proposed for discussions.
I
On Thu, Feb 19, 2015 at 9:13 AM, Leigh lei...@gmail.com wrote:
On 19 February 2015 at 15:45, Pierre Joye pierre@gmail.com wrote:
Still, no announce for a discussion about this specific RFC. And
really, the content of the RFC is almost empty, pointing to the ML
archive is really not the
43 matches
Mail list logo
