Hello @Stephen Reay,
yes I have that in my, I was thinking about reusing the `throw` keyword and
re-contextualizing it à la use
function handle(int $cmd, ...$args) : int throw(legit, error) /*
Throws only those else triggers runtime error */
{ return -1; }
function handle(int $
> On 4 Apr 2019, at 03:29, M. W. Moe wrote:
>
> Thanks!
>
>> On Wed, Apr 3, 2019 at 1:24 PM G. P. B. wrote:
>>
>> Hello,
>>
>> I don't really see the point of it as you self said this wouldn't add a
>> runtime check, so in what is it different to a comment?
>> More so reusing ! for this wi
Nikita Popov wrote:
I'm always a fan of making things stricter, but think that in this
particular case there are some additional considerations we should keep in
mind.
1. What is more important to me here than strictness is consistency. Either
both " 123" and "123 " are numeric, or neither a
Thanks!
On Wed, Apr 3, 2019 at 1:24 PM G. P. B. wrote:
> Hello,
>
> I don't really see the point of it as you self said this wouldn't add a
> runtime check, so in what is it different to a comment?
> More so reusing ! for this will, in my opinion, just lead to confusion as
> people will think it
Hello,
I don't really see the point of it as you self said this wouldn't add a
runtime check, so in what is it different to a comment?
More so reusing ! for this will, in my opinion, just lead to confusion as
people will think it negates the function, this is what
I would expect it to do at first
On 03/04/2019 20:31, M. W. Moe wrote:
the commenting section suggestion was some kind of decoy or trap;
it does not address the original request and its scope
Perhaps you could clarify what that scope is, then. As I say, I'm not
clear what the difference is between the proposed syntax and a c
Hello,
you are very kind and trying hard but that's not the topic; the commenting
section suggestion was some kind of decoy or trap;
it does not address the original request and its scope; what's behind is
more fundamental; I may have a polite discussion and
argument with people; not bulls, they b
On 03/04/2019 18:13, M. W. Moe wrote:
> The argument sits there.
>
> function handle(int $cmd, ...$arg) : int /* throw */
> function !handle(int $cmd, ...$arg) : int
The first example is unambiguous, easy to understand by anyone with a
basic knowledge of the language, easy to spot when reading
Hello,
quick commenting usually ends up in a `circus`; either you enforce extra
qualifiers in term of signature or you don't encourage it
you seems not having the experience of working on the same code base with
basically literally dozen of people which can at
some point intervene; this is reality
On Wed, 3 Apr 2019 at 17:52, M. W. Moe wrote:
> not documenting at first is not really a question of laziness or so, as
> things are still moving around
> you absolutely need this agility; a good design layout between theory and
> stable state will refactored
> discussed a thousand times; that w
The argument sits there.
function handle(int $cmd, ...$arg) : int /* throw */
function !handle(int $cmd, ...$arg) : int
On Wed, Apr 3, 2019 at 10:10 AM M. W. Moe wrote:
> Hello,
>
> yes this is very true, but still foreign to the language construct; empty
> contextual indicators it's what
> we
Hello,
yes this is very true, but still foreign to the language construct; empty
contextual indicators it's what
we usually do in C and assembly (it has no cost) especially on extra
sensitive code to make it short.
On Wed, Apr 3, 2019 at 10:00 AM Claude Pache wrote:
>
>
> > Le 3 avr. 2019 à 18:
> Le 3 avr. 2019 à 18:52, M. W. Moe a écrit :
>
> Hello,
>
> not documenting at first is not really a question of laziness or so, as
> things are still moving around
> you absolutely need this agility; a good design layout between theory and
> stable state will refactored
> discussed a thous
I think the issue here is that there is no functional difference between an
exclamation mark prefix and a docblock attribute, and the latter has the
advantage of being more explicit, not requiring changes to the language syntax
itself, and being an already-existing standard.
Of course things m
Hello,
not documenting at first is not really a question of laziness or so, as
things are still moving around
you absolutely need this agility; a good design layout between theory and
stable state will refactored
discussed a thousand times; that what I expect from engineers; filling the
gaps betw
On Wed, 3 Apr 2019 at 17:27, M. W. Moe wrote:
> yes this is very true; but usually on complex design with a lot of folks
> working on it you start coding before documenting;
>
If it's just syntax that doesn't change behaviour, it's really just
documentation anyway, and if people are so desperat
Hello,
yes this is very true; but usually on complex design with a lot of folks
working on it you start coding before documenting;
I was thinking like c++ `nothrow` identifie (I do know does more than
informal), I am the kind of people who like languages
which are explicit before any documentation
On Wed, Apr 3, 2019 at 11:07 AM M. W. Moe wrote:
> I have a quick question before any formal proposal; would it be complex to
> add an exclamation mark indicatorin front a function identifier to indicate
> that function throws; like the nullable question mark for types however
> without any runt
On Wed, Apr 3, 2019 at 4:52 AM Benjamin Morel
wrote:
> I just used PHP_FLOAT_MIN for the first time, and was surprised that it is
> the smallest **positive** number representable. Is this expected?
>
> This is unlike PHP_INT_MIN, which is the absolute smallest representable
> integer, and as such
Hello people,
I have a quick question before any formal proposal; would it be complex to
add an exclamation mark indicatorin front a function identifier to indicate
that function throws; like the nullable question mark for types however
without any runtime check something like a pure syntax indic
Thanks for explain.
Cheers
Joe
On Wed, 3 Apr 2019 at 14:40, Rowan Collins wrote:
> On Wed, 3 Apr 2019 at 13:33, Benjamin Morel
> wrote:
>
> > PHP_FLOAT_MIN (float)
> > > Smallest representable POSITIVE floating point number. If you need the
> > > smallest representable floating point number, u
Hi dmitry, internals,
As I wrote somewhere else, I've finally been able to find time to update
the Bamboo instance I've been using during the past few years to run
daily PHP builds, run their test suites and use them to run test suites
of few popular open source projects as I've been doing sin
On Wed, 3 Apr 2019 at 13:33, Benjamin Morel
wrote:
> PHP_FLOAT_MIN (float)
> > Smallest representable POSITIVE floating point number. If you need the
> > smallest representable floating point number, use - PHP_FLOAT_MAX.
> > Available as of PHP 7.2.0.
>
I'd avoid the word "smallest". PHP_FLOAT_
> Le 3 avr. 2019 à 11:51, Benjamin Morel a écrit :
>
> Hi internals,
>
> I just used PHP_FLOAT_MIN for the first time, and was surprised that it is
> the smallest **positive** number representable. Is this expected?
>
> This is unlike PHP_INT_MIN, which is the absolute smallest representable
>
> It really don't make much sense:
> var_dump( PHP_FLOAT_MIN < 0 );
> var_dump( PHP_INT_MIN < 0 );
I quite agree that this is an inconsistency, but I guess that it's here to
stay now for BC reasons. What we can do is fix the doc.
> 2.2250738585072E-308
> This is negative.
It isn't, it is a
Le mercredi 3 avril 2019, 13:47:55 CEST Joe Watkins a écrit :
> 2.2250738585072E-308
>
> This is negative.
>
> Cheers
> Joe
No it’s not.
It’s positive and close to 0.
Côme
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Tue, Apr 2, 2019, 7:40 PM Kalle Sommer Nielsen wrote:
> Den fre. 22. mar. 2019 kl. 15.26 skrev Kalle Sommer Nielsen >:
> > https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase
>
> Given the feedback, the RFC only targets the ext/interbase extension
> to be bundled and moved to PECL.
>
On 03/04/2019 12:27, Diogo Neves wrote:
> It really don't make much sense:
>
>
> var_dump( PHP_FLOAT_MIN < 0 );
> var_dump( PHP_INT_MIN < 0 );
>
> On Wed, Apr 3, 2019 at 10:52 AM Benjamin Morel
> wrote:
>
>> Hi internals,
>>
>> I just used PHP_FLOAT_MIN for the first time, and was surprised t
2.2250738585072E-308
This is negative.
Cheers
Joe
On Wed, 3 Apr 2019 at 12:27, Diogo Neves wrote:
> It really don't make much sense:
>
>
> var_dump( PHP_FLOAT_MIN < 0 );
> var_dump( PHP_INT_MIN < 0 );
>
> On Wed, Apr 3, 2019 at 10:52 AM Benjamin Morel
> wrote:
>
> > Hi internals,
> >
> > I j
It really don't make much sense:
wrote:
> Hi internals,
>
> I just used PHP_FLOAT_MIN for the first time, and was surprised that it is
> the smallest **positive** number representable. Is this expected?
>
> This is unlike PHP_INT_MIN, which is the absolute smallest representable
> integer, and a
Hi internals,
I just used PHP_FLOAT_MIN for the first time, and was surprised that it is
the smallest **positive** number representable. Is this expected?
This is unlike PHP_INT_MIN, which is the absolute smallest representable
integer, and as such is negative:
echo PHP_INT_MIN; // -922337203685
31 matches
Mail list logo
