On Sat, Dec 27, 2014 at 4:45 AM, Pierre Joye wrote:
> On Dec 26, 2014 7:42 PM, "Xinchen Hui" wrote:
> >
> > Hey:
> >
> > On Fri, Dec 26, 2014 at 7:54 PM, Andrea Faulds wrote:
> > >
> > >> On 26 Dec 2014, at 05:57, Levi Morrison wrote:
> > >>
> > >>> On Thu, Dec 25, 2014 at 2:33 PM, Michael Wal
On Dec 26, 2014 7:42 PM, "Xinchen Hui" wrote:
>
> Hey:
>
> On Fri, Dec 26, 2014 at 7:54 PM, Andrea Faulds wrote:
> >
> >> On 26 Dec 2014, at 05:57, Levi Morrison wrote:
> >>
> >>> On Thu, Dec 25, 2014 at 2:33 PM, Michael Wallner wrote:
> >>> There's already ZEND_RESULT_CODE, or did I miss anyth
On Fri, Dec 26, 2014 at 5:42 AM, Xinchen Hui wrote:
> Hey:
>
> On Fri, Dec 26, 2014 at 7:54 PM, Andrea Faulds wrote:
>>
>>> On 26 Dec 2014, at 05:57, Levi Morrison wrote:
>>>
On Thu, Dec 25, 2014 at 2:33 PM, Michael Wallner wrote:
There's already ZEND_RESULT_CODE, or did I miss anythi
Hey:
On Fri, Dec 26, 2014 at 7:54 PM, Andrea Faulds wrote:
>
>> On 26 Dec 2014, at 05:57, Levi Morrison wrote:
>>
>>> On Thu, Dec 25, 2014 at 2:33 PM, Michael Wallner wrote:
>>> There's already ZEND_RESULT_CODE, or did I miss anything?
>>
>> According to lxr.php.net, this symbol ZEND_RESULT_COD
> On 26 Dec 2014, at 05:57, Levi Morrison wrote:
>
>> On Thu, Dec 25, 2014 at 2:33 PM, Michael Wallner wrote:
>> There's already ZEND_RESULT_CODE, or did I miss anything?
>
> According to lxr.php.net, this symbol ZEND_RESULT_CODE is not
> referenced in any place except its definition. We can b
Hey:
On Fri, Dec 26, 2014 at 5:33 AM, Michael Wallner wrote:
> There's already ZEND_RESULT_CODE, or did I miss anything?
yes,
we were talking about use ZEND_RESULT_CODE as return type hinting for
those functions use SUCCSS/FAILURE ..
furthermore, maybe we could use it as all ZEND_API's return
On Thu, Dec 25, 2014 at 2:33 PM, Michael Wallner wrote:
> There's already ZEND_RESULT_CODE, or did I miss anything?
According to lxr.php.net, this symbol ZEND_RESULT_CODE is not
referenced in any place except its definition. We can begin using it
if we like, or even rename it. Theoretically renam
On Fri, Dec 26, 2014 at 8:33 AM, Michael Wallner wrote:
> There's already ZEND_RESULT_CODE, or did I miss anything?
Yes, to read the thread :)
We are not talking about the lack of a status typedef but about the
inconsistencies across PHP internal APIs. And what Xinchen suggests
below is to begin
There's already ZEND_RESULT_CODE, or did I miss anything?
On 25 Dec 2014 06:45, "Xinchen Hui" wrote:
> Hey:
>
> On Thu, Dec 25, 2014 at 12:38 PM, Pierre Joye
> wrote:
> > On Thu, Dec 25, 2014 at 3:06 PM, Andrea Faulds wrote:
> >>
> >>> On 24 Dec 2014, at 23:53, Levi Morrison wrote:
> >>>
> >>
Hey:
On Thu, Dec 25, 2014 at 12:38 PM, Pierre Joye wrote:
> On Thu, Dec 25, 2014 at 3:06 PM, Andrea Faulds wrote:
>>
>>> On 24 Dec 2014, at 23:53, Levi Morrison wrote:
>>>
>>> On Wed, Dec 24, 2014 at 4:27 PM, Johannes Schlüter
>>> wrote:
On Wed, 2014-12-24 at 11:13 -0700, Levi Morrison wr
On Thu, Dec 25, 2014 at 3:34 PM, Xinchen Hui wrote:
> Hey:
>
> On Thu, Dec 25, 2014 at 12:06 PM, Andrea Faulds wrote:
>>
>>> On 24 Dec 2014, at 23:53, Levi Morrison wrote:
>>>
>>> On Wed, Dec 24, 2014 at 4:27 PM, Johannes Schlüter
>>> wrote:
On Wed, 2014-12-24 at 11:13 -0700, Levi Morrison
On Thu, Dec 25, 2014 at 3:06 PM, Andrea Faulds wrote:
>
>> On 24 Dec 2014, at 23:53, Levi Morrison wrote:
>>
>> On Wed, Dec 24, 2014 at 4:27 PM, Johannes Schlüter
>> wrote:
>>> On Wed, 2014-12-24 at 11:13 -0700, Levi Morrison wrote:
>>>
I'm asking for specific things. The reason is that som
Hey:
On Thu, Dec 25, 2014 at 12:06 PM, Andrea Faulds wrote:
>
>> On 24 Dec 2014, at 23:53, Levi Morrison wrote:
>>
>> On Wed, Dec 24, 2014 at 4:27 PM, Johannes Schlüter
>> wrote:
>>> On Wed, 2014-12-24 at 11:13 -0700, Levi Morrison wrote:
>>>
I'm asking for specific things. The reason is t
> On 24 Dec 2014, at 23:53, Levi Morrison wrote:
>
> On Wed, Dec 24, 2014 at 4:27 PM, Johannes Schlüter
> wrote:
>> On Wed, 2014-12-24 at 11:13 -0700, Levi Morrison wrote:
>>
>>> I'm asking for specific things. The reason is that some API's do a
>>> non-zero error code; the fact that they are
On Wed, Dec 24, 2014 at 4:27 PM, Johannes Schlüter
wrote:
> On Wed, 2014-12-24 at 11:13 -0700, Levi Morrison wrote:
>
>> I'm asking for specific things. The reason is that some API's do a
>> non-zero error code; the fact that they are negative is a detail that
>> we should not need to care about.
On Wed, 2014-12-24 at 11:13 -0700, Levi Morrison wrote:
> I'm asking for specific things. The reason is that some API's do a
> non-zero error code; the fact that they are negative is a detail that
> we should not need to care about.
My guess is that positive values more often might have a meaning
> On 24 Dec 2014, at 18:13, Levi Morrison wrote:
>
> On Wed, Dec 24, 2014 at 10:34 AM, Andrea Faulds wrote:
>>
>>> On 24 Dec 2014, at 17:22, Levi Morrison wrote:
>>>
>>> Hmm. This thread doesn't seem to mention it, but why must failure be
>>> negative? I understand the non-zero part but not
On Dec 25, 2014 1:13 AM, "Levi Morrison" wrote:
>
> On Wed, Dec 24, 2014 at 10:34 AM, Andrea Faulds wrote:
> >
> >> On 24 Dec 2014, at 17:22, Levi Morrison wrote:
> >>
> >> Hmm. This thread doesn't seem to mention it, but why must failure be
> >> negative? I understand the non-zero part but not
On Wed, Dec 24, 2014 at 10:34 AM, Andrea Faulds wrote:
>
>> On 24 Dec 2014, at 17:22, Levi Morrison wrote:
>>
>> Hmm. This thread doesn't seem to mention it, but why must failure be
>> negative? I understand the non-zero part but not negative. Aside from
>> the fact we probably have code relying
> On 24 Dec 2014, at 17:22, Levi Morrison wrote:
>
> Hmm. This thread doesn't seem to mention it, but why must failure be
> negative? I understand the non-zero part but not negative. Aside from
> the fact we probably have code relying on it to be negative at this
> point is there some other reas
Hmm. This thread doesn't seem to mention it, but why must failure be
negative? I understand the non-zero part but not negative. Aside from
the fact we probably have code relying on it to be negative at this
point is there some other reason?
--
PHP Internals - PHP Runtime Development Mailing List
On Dec 24, 2014 8:41 PM, "Johannes Schlüter" wrote:
>
> On Wed, 2014-12-24 at 05:06 +, Andrea Faulds wrote:
> > typedef enum _zend_success {
> > FAILURE = 0,
> > SUCCESS = 1
> > } zend_success;
>
> mysqlnd uses a enum for that already. See
> http://lxr.php.net/xref/PHP_TRUNK/ext/mysqln
On Wed, 2014-12-24 at 05:06 +, Andrea Faulds wrote:
> typedef enum _zend_success {
> FAILURE = 0,
> SUCCESS = 1
> } zend_success;
mysqlnd uses a enum for that already. See
http://lxr.php.net/xref/PHP_TRUNK/ext/mysqlnd/mysqlnd_enum_n_def.h#139
If a PHP-wide thing is introduced this sho
On Wed, Dec 24, 2014 at 7:53 PM, Xinchen Hui wrote:
> On Wed, Dec 24, 2014 at 3:57 PM, Pierre Joye wrote:
>>
>> On Dec 24, 2014 2:38 PM, "Stanislav Malyshev" wrote:
>>>
>>> Hi!
>>>
>>> > But: return 0 and return FAILURE... which is simpler?
>>>
>>> It's equally simple to write, but FAILURE of c
On Wed, Dec 24, 2014 at 3:57 PM, Pierre Joye wrote:
>
> On Dec 24, 2014 2:38 PM, "Stanislav Malyshev" wrote:
>>
>> Hi!
>>
>> > But: return 0 and return FAILURE... which is simpler?
>>
>> It's equally simple to write, but FAILURE of course is way simpler to
>> understand when read.
>
> I totally
Hey:
On Wed, Dec 24, 2014 at 3:38 PM, Stanislav Malyshev wrote:
> Hi!
>
>> But: return 0 and return FAILURE... which is simpler?
>
> It's equally simple to write, but FAILURE of course is way simpler to
> understand when read.
I can not agree with that since nowdays, false === 0, true === 1 is
On Dec 24, 2014 2:38 PM, "Stanislav Malyshev" wrote:
>
> Hi!
>
> > But: return 0 and return FAILURE... which is simpler?
>
> It's equally simple to write, but FAILURE of course is way simpler to
> understand when read.
I totally agree.
I do not care much about the value of failure or success bu
Hi!
> But: return 0 and return FAILURE... which is simpler?
It's equally simple to write, but FAILURE of course is way simpler to
understand when read.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub
Hey:
thanks, that is the first thought of mine too.
On Wed, Dec 24, 2014 at 1:06 PM, Andrea Faulds wrote:
>
>> On 24 Dec 2014, at 03:25, Xinchen Hui wrote:
>>
>> Hey:
>>
>> We use SUCCESS/FAILURE as return value in some APIs, but use
>> 0/1(false/true) in others.
>>
>> I'd like to remove
> On 24 Dec 2014, at 03:25, Xinchen Hui wrote:
>
> Hey:
>
> We use SUCCESS/FAILURE as return value in some APIs, but use
> 0/1(false/true) in others.
>
> I'd like to remove SUCCESS/FAILURE at all, use 0/1 instead..
>
> what do you think?
>
> thanks
Hi,
Honestly, I don’t think SUCCES
> On Dec 24, 2014, at 12:55 PM, Xinchen Hui wrote:
>
> Hey
>
>
>> On Dec 24, 2014, at 12:49 PM, Stanislav Malyshev wrote:
>>
>> Hi!
>>
>>> Hey:
>>>
>>> We use SUCCESS/FAILURE as return value in some APIs, but use
>>> 0/1(false/true) in others.
>>>
>>> I'd like to remove SUCCESS/FAILU
Hi!
> I think if(func()) is better, more readeable than if(func() == success)
Not really, especially given the fact that for major part of libc
if(func()) means checking for error, not for success, as success value is 0.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Deve
Hey
> On Dec 24, 2014, at 12:49 PM, Stanislav Malyshev wrote:
>
> Hi!
>
>> Hey:
>>
>> We use SUCCESS/FAILURE as return value in some APIs, but use
>> 0/1(false/true) in others.
>>
>> I'd like to remove SUCCESS/FAILURE at all, use 0/1 instead..
>>
>> what do you think?
>
> I think it
Hi!
> Hey:
>
>We use SUCCESS/FAILURE as return value in some APIs, but use
> 0/1(false/true) in others.
>
>I'd like to remove SUCCESS/FAILURE at all, use 0/1 instead..
>
>what do you think?
I think it would make reading code harder. Why do it - is there any
benefit in it? SUCCESS/
Hey:
We use SUCCESS/FAILURE as return value in some APIs, but use
0/1(false/true) in others.
I'd like to remove SUCCESS/FAILURE at all, use 0/1 instead..
what do you think?
thanks
--
Xinchen Hui
@Laruence
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing
35 matches
Mail list logo
