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 th
Am 28.02.2015 um 20:08 schrieb Patrick Schaaf:
Am 28.02.2015 19:32 schrieb "Crypto Compress"
mailto:cryptocompr...@googlemail.com>>:
>
> class BankAccount {
> function Add($amount) {
> assert($amount > 0);
> // ... code block ...
> }
> }
>
> Now the programmer implemen
Am 28.02.2015 19:32 schrieb "Crypto Compress" :
>
> 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 no way to (Unit)
Am 21.02.2015 um 04:10 schrieb Yasuo Ohgaki:
Hi Crypto,
On Fri, Feb 20, 2015 at 11:02 PM, Crypto Compress
mailto:cryptocompr...@googlemail.com>>
wrote:
AssertionExceptions are not intended to be caught, they are
intended to be seen, in a specific environment.
Joe, your
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 c
On Thu, Feb 19, 2015 at 2:09 AM, Joe Watkins 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 Internals - PHP Runtime
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 discus
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, w
On Feb 21, 2015 1:54 PM, "Yasuo Ohgaki" wrote:
>
> Hi Pierre,
>
> On Sun, Feb 22, 2015 at 2:53 AM, Pierre Joye wrote:
>>
>> > Assertion is only for development and testing.
>> > We need errors or exceptions during development and testing, but
>> > not in production. Therefore, errors/exception sh
Hi Pierre,
On Sun, Feb 22, 2015 at 2:53 AM, Pierre Joye 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. Isn't assertion
On Fri, Feb 20, 2015 at 7:10 PM, Yasuo Ohgaki 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
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
> y
On 19 February 2015 at 01:09, Joe Watkins 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 awesome, particularly the
On Fri, Feb 20, 2015 at 8:36 AM, Joe Watkins wrote:
>> No, we did not
>
> Yes, we did, which you could have found out, if you were really bothered:
>
> https://marc.info/?l=php-internals&m=138213285708117&w=2
You are kidding me here and I already answered to that:
2013-10-18 21:46:45
So no, it
> No, we did not
Yes, we did, which you could have found out, if you were really bothered:
https://marc.info/?l=php-internals&m=138213285708117&w=2
Cheers
Joe
On Fri, Feb 20, 2015 at 4:31 PM, Pierre Joye wrote:
> On Fri, Feb 20, 2015 at 8:24 AM, Joe Watkins
> wrote:
> >> So it is fine to h
On Fri, Feb 20, 2015 at 8:24 AM, Joe Watkins 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 to be focused
> 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 wha
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 wron
On Fri, Feb 20, 2015 at 7:29 AM, Joe Watkins 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 questions in this t
> 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 lik
Am 20.02.2015 um 15:09 schrieb Nikita Popov:
On Fri, Feb 20, 2015 at 3:02 PM, Crypto Compress
mailto:cryptocompr...@googlemail.com>>
wrote:
AssertionExceptions are not intended to be caught, they are
intended to be seen, in a specific environment.
Joe, your argumentation
On Thu, Feb 19, 2015 at 7:00 AM, Pierre Joye wrote:
> On Thu, Feb 19, 2015 at 1:09 AM, Joe Watkins 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 w
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
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 intende
> 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 actual
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
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 especially
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
On 20 February 2015 at 08:47, Markus Fischer 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 Development Mailin
Am 20.02.2015 09:47 schrieb "Joe Watkins" :
>
> 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 then my ordinary syn
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.asser
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 wrote:
> The custom exception must derive from AssertionException, so the same
> optimization is possi
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 wrote:
> Hey:
>
>
>
> On Thu, Feb 19, 2015 at 5:09 PM, Joe Watkins
> wrote:
> > Morning internals,
> >
> > The expectations RFC is now in
Hey:
On Thu, Feb 19, 2015 at 5:09 PM, Joe Watkins 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 before..
I voted without
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, Fe
On Thu, Feb 19, 2015 at 9:13 AM, Leigh wrote:
> On 19 February 2015 at 15:45, Pierre Joye 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
On 19 February 2015 at 15:45, Pierre Joye 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 3 days is a short
On Thu, Feb 19, 2015 at 7:45 AM, Pierre Joye wrote:
> On Thu, Feb 19, 2015 at 7:16 AM, Dmitry Stogov wrote:
>>
>>
>> On Thu, Feb 19, 2015 at 6:00 PM, Pierre Joye wrote:
>>>
>>> On Thu, Feb 19, 2015 at 1:09 AM, Joe Watkins
>>> wrote:
>>> > Morning internals,
>>> >
>>> > The expectations RFC
On Thu, Feb 19, 2015 at 7:16 AM, Dmitry Stogov wrote:
>
>
> On Thu, Feb 19, 2015 at 6:00 PM, Pierre Joye wrote:
>>
>> On Thu, Feb 19, 2015 at 1:09 AM, Joe Watkins
>> wrote:
>> > Morning internals,
>> >
>> > The expectations RFC is now in voting phase:
>> > https://wiki.php.net/rfc/expectatio
On Thu, Feb 19, 2015 at 5:47 PM, Markus Fischer 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 are to
On Thu, Feb 19, 2015 at 6:00 PM, Pierre Joye wrote:
> On Thu, Feb 19, 2015 at 1:09 AM, Joe Watkins
> 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 th
On Thu, Feb 19, 2015 at 1:09 AM, Joe Watkins 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 have been following u
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 zend
Morning internals,
The expectations RFC is now in voting phase:
https://wiki.php.net/rfc/expectations#vote
Cheers
Joe
44 matches
Mail list logo
