[PHP-DEV] Question about adding !function_identifier

[M. W. Moe]

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 $cmd, ...$args) : int throw(true) /* Throws any */
  { return -1; }

  function handle(int $cmd, ...$args) : int throw(false) /* Triggers
warning, auto-catch */
  { return -1; }

but unfortunately better forking php4.3 than actual and only re-introducing
what's is usable and discarding the rest mostly all the php5 impurities;
hence you can conceive; I would have to face the clerics of this false
religion; I have something else to do in life!

Best.

Re: [PHP-DEV] Question about adding !function_identifier

[Stephen Reay]

> 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 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 glance.
>> Also comparing it to the nullable question mark is quite bizarre I find,
>> why not choose the ampersand for references instead?
>> At least it would cover the same "scope", as types have nothing to do with
>> how a function behaves.
>> 
>> Best regards
>> 
>> George P. Banyard
>> 

Quite honestly knowing that a function “throws” but not *what* it throws, is 
useless. 

Now if it were a proposal to add *runtime checked* `throws FooException, 
BarTypeError` or similar, I could get behind.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings

[Andrea Faulds]

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 are. Making "123"
numeric is a change we can easily do, because it makes the numeric string
definition more permissive and is thus mostly backwards compatible. Doing
the reverse change is certainly not compatible and will be a much harder
sell.

2. I believe that a large part of the motivation here is that by making the
numeric string definition slightly more lax (in a consistent manner), we
can make *other* things more strict, because this essentially eliminates
the only "somewhat reasonable" case of trailing characters. The RFC already
mentions two of them:

a) We can hard reject "123foo" inputs to "int" arguments (and some other
places). Currently this is allowed with a notice. I think if we resolve the
trailing whitespace question, then there cannot be any reasonable
opposition to this change.
b) My own RFC on number to string comparisons would benefit from this. From
initial testing it has surprisingly little impact, but one of the few cases
that turned up was this comparison with a string that had trailing
whitespace.

Personally I think both of those changes are a lot more valuable than a
stricter numeric string definition without leading/trailing whitespace.


I'm kinda unsure how to go forward because of these points. I would like 
to see improved comparisons, and I would like to see the end of the 
“non-well-formed” numeric string, and I think this whitespace RFC could 
be helpful to both. But I can't see the future, I don't know whether 
people will vote for removing leading or permitting traiing whitespace 
and whether or not they will be influenced by or this will influence 
opinion on the further improvements. ¯\_(ツ)_/¯


I'm torn between:

* Vote on allowing trailing whitespace
* Vote on disallowing leading whitespace
* Vote on which of those two approaches to go for
* Trying to bundle everything together and voting on it as a package.

I'm probably thinking too strategically.

Andrea

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question about adding !function_identifier

[M. W. Moe]

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 negates the function, this is what
> I would expect it to do at first glance.
> Also comparing it to the nullable question mark is quite bizarre I find,
> why not choose the ampersand for references instead?
> At least it would cover the same "scope", as types have nothing to do with
> how a function behaves.
>
> Best regards
>
> George P. Banyard
>

Re: [PHP-DEV] Question about adding !function_identifier

[G. P. B.]

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 glance.
Also comparing it to the nullable question mark is quite bizarre I find,
why not choose the ampersand for references instead?
At least it would cover the same "scope", as types have nothing to do with
how a function behaves.

Best regards

George P. Banyard

Re: [PHP-DEV] Question about adding !function_identifier

[Rowan Collins]

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 comment, 
unless it changes the behaviour of the language in some way.


Regards,

--
Rowan Collins
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question about adding !function_identifier

[M. W. Moe]

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 belong to the prairies.

and what  about ?String (cynicism)

Have a good day.

On Wed, Apr 3, 2019 at 11:42 AM Rowan Collins 
wrote:

> 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 the code,
> easy to grep for, and will be recognised as a comment by any tool for
> parsing PHP.
>
> The second example is hard to spot, completely opaque in meaning, and
> would break any tool which didn't have it added as a feature. I'm really
> struggling to see any advantages at all, other than saving a few key
> presses.
>
> Of course, neither documents what type of exceptions will be thrown, so
> it's a bit like documenting every return type as either "void" or
> "mixed"; which is why the more common practice would look more like this:
>
> /** @throws InvalidFooException */
> function handle(int $cmd, ...$arg): int
>
>
> > 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, this not wrong or bad; you deal
> > with it.
>
>
> You're right, I haven't worked in a team that size, but if I did, I
> would expect strict coding standards that emphasise clear intent and
> documented behaviour to be absolutely essential for everyone to know
> what was going on.
>
>
> > either you enforce extra qualifiers in term of signature or you don't
> > encourage it
>
>
> I'm struggling to see the difference between enforcing "add an ! before
> the name if it throws" and "add a comment next to the name if it
> throws", or even "add X to the name if it throws", unless the language
> itself is going to perform some extra check.
>
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Question about adding !function_identifier

[Rowan Collins]

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 the code, 
easy to grep for, and will be recognised as a comment by any tool for 
parsing PHP.


The second example is hard to spot, completely opaque in meaning, and 
would break any tool which didn't have it added as a feature. I'm really 
struggling to see any advantages at all, other than saving a few key 
presses.


Of course, neither documents what type of exceptions will be thrown, so 
it's a bit like documenting every return type as either "void" or 
"mixed"; which is why the more common practice would look more like this:


/** @throws InvalidFooException */
function handle(int $cmd, ...$arg): int


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, this not wrong or bad; you deal 
with it.



You're right, I haven't worked in a team that size, but if I did, I 
would expect strict coding standards that emphasise clear intent and 
documented behaviour to be absolutely essential for everyone to know 
what was going on.



either you enforce extra qualifiers in term of signature or you don't 
encourage it



I'm struggling to see the difference between enforcing "add an ! before 
the name if it throws" and "add a comment next to the name if it 
throws", or even "add X to the name if it throws", unless the language 
itself is going to perform some extra check.



Regards,

--
Rowan Collins
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question about adding !function_identifier

[M. W. Moe]

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, this not wrong or bad; you deal with
it.

We are a shop where people are using terminal emulators; vim or emacs not
cumbersome IDEs or for some not even a window manager
; reality; you deal with it. Moreover an exception state is not really like
a status; this is an internal language behavior, should
be carried by the syntax even if informal, anyhow could evolve over time.


On Wed, Apr 3, 2019 at 10:24 AM Rowan Collins 
wrote:

> 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 what I expect from engineers; filling
> the
> > gaps between assumptions
> > and reality.
> >
>
>
> I think we have different assumptions about what "documentation" means
> here. I'm not saying you have to write a 500-word paragraph explaining the
> theory and edge-cases in the code; just that you should write a quick
> comment saying what the function expects, and what it will return, beyond
> the ability of the language's syntax.
>
> You *could* write every function like this:
>
> function tbc(...$args) {
> }
>
> That way, you can change the visibility, the argument types, the return
> types, and the name, without "documenting" it in advance. Clearly, that
> would be ridiculous, so you probably actually write this:
>
> public function convertFooToBar(Foo $foo): Bar {
> }
>
> What I mean by "documentation first" is to go a small step further and
> write:
>
> /**
>  * Convert using the lookup tables
>  *
>  * @param Foo $foo Should only be given pre-validated Foo
>  * @return Bar Will always be pre-validated
>  * @throws InvalidFooTypeException
>  */
> public function convertFooToBar(Foo $foo): Bar {
> }
>
>
> This is all part of the *current* design of this function. It might change,
> but if it changes, you change the docblock, just as you'd change the
> signature if you realised it should actually be private, or accept a
> PreValidatedFoo object, or the name is wrong.
>
>
> You seem to want to do this same job, but with as few characters as
> possible, and I don't really understand why, if your aim is to be explicit
> and clear. If you just want to type less, use an IDE or editor with good
> auto-complete support.
>
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>

Re: [PHP-DEV] Question about adding !function_identifier

[Rowan Collins]

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 what I expect from engineers; filling the
> gaps between assumptions
> and reality.
>


I think we have different assumptions about what "documentation" means
here. I'm not saying you have to write a 500-word paragraph explaining the
theory and edge-cases in the code; just that you should write a quick
comment saying what the function expects, and what it will return, beyond
the ability of the language's syntax.

You *could* write every function like this:

function tbc(...$args) {
}

That way, you can change the visibility, the argument types, the return
types, and the name, without "documenting" it in advance. Clearly, that
would be ridiculous, so you probably actually write this:

public function convertFooToBar(Foo $foo): Bar {
}

What I mean by "documentation first" is to go a small step further and
write:

/**
 * Convert using the lookup tables
 *
 * @param Foo $foo Should only be given pre-validated Foo
 * @return Bar Will always be pre-validated
 * @throws InvalidFooTypeException
 */
public function convertFooToBar(Foo $foo): Bar {
}


This is all part of the *current* design of this function. It might change,
but if it changes, you change the docblock, just as you'd change the
signature if you realised it should actually be private, or accept a
PreValidatedFoo object, or the name is wrong.


You seem to want to do this same job, but with as few characters as
possible, and I don't really understand why, if your aim is to be explicit
and clear. If you just want to type less, use an IDE or editor with good
auto-complete support.


Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] Question about adding !function_identifier

[M. W. Moe]

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 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: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 thousand times; that what I expect from engineers; filling
>> the
>> > gaps between assumptions
>> > and reality.
>> >
>> > And for me-self throw vs no throw is important language information and
>> > part of internal behaviors;
>> > to clarify, for instance, would be more useful to have such indicator
>> > rather than having having
>> > abstract and interface which are cumbersome; same as the extra public
>> > keyword; you can do without
>> > especially with the new traits construct.
>> >
>> > Best.
>>
>> If you’re unwilling to write a docblock for some good reason, why not
>> just use the built-in, user-extensible way that most programming languages
>> have to add annotations without runtime effect, namely unstructured
>> comments? Something like /* nothrow */ is both forward- and
>> backward-compatible... Am I missing something?
>>
>> —Claude
>>
>>

Re: [PHP-DEV] Question about adding !function_identifier

[M. W. Moe]

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: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 thousand times; that what I expect from engineers; filling
> the
> > gaps between assumptions
> > and reality.
> >
> > And for me-self throw vs no throw is important language information and
> > part of internal behaviors;
> > to clarify, for instance, would be more useful to have such indicator
> > rather than having having
> > abstract and interface which are cumbersome; same as the extra public
> > keyword; you can do without
> > especially with the new traits construct.
> >
> > Best.
>
> If you’re unwilling to write a docblock for some good reason, why not just
> use the built-in, user-extensible way that most programming languages have
> to add annotations without runtime effect, namely unstructured comments?
> Something like /* nothrow */ is both forward- and backward-compatible... Am
> I missing something?
>
> —Claude
>
>

Re: [PHP-DEV] Question about adding !function_identifier

[Claude Pache]

> 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 thousand times; that what I expect from engineers; filling the
> gaps between assumptions
> and reality.
> 
> And for me-self throw vs no throw is important language information and
> part of internal behaviors;
> to clarify, for instance, would be more useful to have such indicator
> rather than having having
> abstract and interface which are cumbersome; same as the extra public
> keyword; you can do without
> especially with the new traits construct.
> 
> Best.

If you’re unwilling to write a docblock for some good reason, why not just use 
the built-in, user-extensible way that most programming languages have to add 
annotations without runtime effect, namely unstructured comments? Something 
like /* nothrow */ is both forward- and backward-compatible... Am I missing 
something?

—Claude


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question about adding !function_identifier

[Stijn Peeters]

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 may move around during the development process, but I don't 
really see how you can't move around the docblocks with the functions they 
belong to... A decent IDE will make this easy and can also use the @throws tag 
to provide the contextual information you're looking for, again, without having 
to change the language itself.

Best,
Stijn



Op 3 april 2019 bij 18:52:58, M. W. Moe (mo.mu@gmail.com) schreef:

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 between assumptions  
and reality.  

And for me-self throw vs no throw is important language information and  
part of internal behaviors;  
to clarify, for instance, would be more useful to have such indicator  
rather than having having  
abstract and interface which are cumbersome; same as the extra public  
keyword; you can do without  
especially with the new traits construct.  

Best.  


On Wed, Apr 3, 2019 at 9:42 AM Rowan Collins   
wrote:  

> 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 desperate to dig into the code  
> that they can't write a minimal docblock (or so lazy that they won't), how  
> likely is it that they'll correctly add this new indicator?  
>  
> If you want to be explicit, don't put off docblocks until later (writing  
> them before you've even implemented the function can be a great way of  
> clarifying your design), and use an IDE or CI tool that will tell you when  
> they're missing or incorrect.  
>  
> Regards,  
> --  
> Rowan Collins  
> [IMSoP]  
>  

Re: [PHP-DEV] Question about adding !function_identifier

[M. W. Moe]

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 between assumptions
and reality.

And for me-self throw vs no throw is important language information and
part of internal behaviors;
to clarify, for instance, would be more useful to have such indicator
rather than having having
abstract and interface which are cumbersome; same as the extra public
keyword; you can do without
especially with the new traits construct.

Best.


On Wed, Apr 3, 2019 at 9:42 AM Rowan Collins 
wrote:

> 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 desperate to dig into the code
> that they can't write a minimal docblock (or so lazy that they won't), how
> likely is it that they'll correctly add this new indicator?
>
> If you want to be explicit, don't put off docblocks until later (writing
> them before you've even implemented the function can be a great way of
> clarifying your design), and use an IDE or CI tool that will tell you when
> they're missing or incorrect.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>

Re: [PHP-DEV] Question about adding !function_identifier

[Rowan Collins]

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 desperate to dig into the code
that they can't write a minimal docblock (or so lazy that they won't), how
likely is it that they'll correctly add this new indicator?

If you want to be explicit, don't put off docblocks until later (writing
them before you've even implemented the function can be a great way of
clarifying your design), and use an IDE or CI tool that will tell you when
they're missing or incorrect.

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] Question about adding !function_identifier

[M. W. Moe]

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 and a throw vs nothrow is an
important contextual information, it will forcibly
change the way you engage it.



On Wed, Apr 3, 2019 at 9:20 AM Sara Golemon  wrote:

> 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 runtime check something like a pure syntax indicator to make
>> the code clearer?
>>
>> If you're suggesting something with no runtime validation, then why not
> simply use docblock annotations?  They're widely supported and understood
> already.
>
> Basically, what will having that syntax give you that not having it won't?
>
> -Sara
>

Re: [PHP-DEV] Question about adding !function_identifier

[Sara Golemon]

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 runtime check something like a pure syntax indicator to make
> the code clearer?
>
> If you're suggesting something with no runtime validation, then why not
simply use docblock annotations?  They're widely supported and understood
already.

Basically, what will having that syntax give you that not having it won't?

-Sara

Re: [PHP-DEV] PHP_FLOAT_MIN is positive

[Sara Golemon]

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 is negative:
>
> echo PHP_INT_MIN; // -9223372036854775808
> echo PHP_FLOAT_MIN; // 2.2250738585072E-308
>
> If it is intended, maybe the doc
>  should be clear
> about this, at the moment it is just:
>
> Smallest representable floating point number.
>
>
> Which is confusing IMO.
>
> Perhaps confusing, but not without precedent.  See the C++ definitions for
::min() and ::lowest() on
https://en.cppreference.com/w/cpp/types/numeric_limits.

std::numeric_limits::min() is a positive value very near zero.
std::numeric::limits::lowest() is a very large negative value.

-Sara

[PHP-DEV] Question about adding !function_identifier

[M. W. Moe]

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 indicator to make
the code clearer?


Have a good day.

Re: [PHP-DEV] PHP_FLOAT_MIN is positive

[Joe Watkins]

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, use - PHP_FLOAT_MAX.
> > > Available as of PHP 7.2.0.
> >
>
>
> I'd avoid the word "smallest". PHP_FLOAT_MIN could be described as having
> the "smallest magnitude", and -PHP_FLOAT as being "the largest magnitude,
> but negative".
>
> Perhaps:
>
> > Closest representable positive floating point number to zero. If you need
> the
> > negative number furthest from zero, use -PHP_FLOAT_MAX.
>
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>

[PHP-DEV] PHP 7.4 segfaults

[Matteo Beccati]

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 since phpng.


The Revive Adserver test suite has currently a few failures with 7.4 
that I need to look into, but some of them are in fact caused by 
segmentation faults in PHP, possibly by its legacy syntax usage:


https://revive.beccati.com/bamboo/browse/REV-LP-P74M-1801

I've identified two different kinds: one in zend_assign_to_variable and 
the other one during shutdown. Here are the backtraces:


https://gist.github.com/mbeccati/da3e304cd1fcdeddc43ec35f4c5c224f

I can provide more info on how to run the test suite or grant ssh access 
to the box if anyone is interested in digging deeper.



Cheers
--
Matteo Beccati

Development & Consulting - http://www.beccati.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP_FLOAT_MIN is positive

[Rowan Collins]

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_MIN could be described as having
the "smallest magnitude", and -PHP_FLOAT as being "the largest magnitude,
but negative".

Perhaps:

> Closest representable positive floating point number to zero. If you need
the
> negative number furthest from zero, use -PHP_FLOAT_MAX.


Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] PHP_FLOAT_MIN is positive

[Claude Pache]

> 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
> integer, and as such is negative:
> 
> echo PHP_INT_MIN; // -9223372036854775808
> echo PHP_FLOAT_MIN; // 2.2250738585072E-308
> 
> If it is intended, maybe the doc
>  should be clear
> about this, at the moment it is just:
> 
> Smallest representable floating point number.
> 
> 
> Which is confusing IMO.
> 
> Cheers,
> Ben

And in order to avoid further confusion, the constant ought to be renamed 
PHP_FLOAT_MIN_POSITIVE.

Rust named it correctly: 
https://doc.rust-lang.org/std/f64/constant.MIN_POSITIVE.html 


—Claude

Re: [PHP-DEV] PHP_FLOAT_MIN is positive

[Benjamin Morel]

>
> 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 strictly positive number with a negative exponent:
0.000(...)00022250738585072.

FLT_MIN is the smallest real near 0. Are you looking for -FLT_MAX?
> With IEEE754 floats, there are positive and negative zeros, so the range
> above and below 0 is the same.


It's interesting to know that - PHP_FLOAT_MAX is actually the smallest
representable floating point number (unlike - PHP_INT_MAX). It would be
great to document this as well.

I would propose to change the current documentation to:

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.


What we could also do is introduce another constant to represent the actual
smallest possible float, but its naming would likely conflict with
PHP_FLOAT_MIN, and it does not bring much value, so I'm not sure whether
this is a good idea.
We did introduce a PHP_INT_MIN though, even though it was available as ~
PHP_INT_MAX, so it's worth mentioning.

Thoughts?



On Wed, 3 Apr 2019 at 13:50, Michael Wallner  wrote:

> 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 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; // -9223372036854775808
> >> echo PHP_FLOAT_MIN; // 2.2250738585072E-308
> >>
> >> If it is intended, maybe the doc
> >>  should be clear
> >> about this, at the moment it is just:
> >>
> >> Smallest representable floating point number.
> >>
> >>
> >> Which is confusing IMO.
>
> FLT_MIN is the smallest real near 0. Are you looking for -FLT_MAX?
> With IEEE754 floats, there are positive and negative zeros, so the range
> above and below 0 is the same.
>
>
> --
> Regards,
> Mike
>
>

Re: [PHP-DEV] PHP_FLOAT_MIN is positive

[Côme Chilliet]

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

Re: [PHP-DEV] Re: [RFC] Unbundle ext/interbase

[Pierre Joye]

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.
>
> Behind the scenes, the german firebird community has reached out to me
> in private with what seems to be their intention to take over the
> extension, but without any further feedback from them (nor internals
> participaction), even with the help of Joe and Sebastian to write a
> mail in german to explain the reasoning and what an extension in PECL
> may mean for them.
>

You can add me to the loop and I can explain them the process, in German or
have a call with them if needed.



> Given this, the RFC will go into voting on noon monday EET, April 8th
> as previously planned.
>

thanks:)


> --
> regards,
>
> Kalle Sommer Nielsen
> ka...@php.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] PHP_FLOAT_MIN is positive

[Michael Wallner]

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 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; // -9223372036854775808
>> echo PHP_FLOAT_MIN; // 2.2250738585072E-308
>>
>> If it is intended, maybe the doc
>>  should be clear
>> about this, at the moment it is just:
>>
>> Smallest representable floating point number.
>>
>>
>> Which is confusing IMO.

FLT_MIN is the smallest real near 0. Are you looking for -FLT_MAX?
With IEEE754 floats, there are positive and negative zeros, so the range
above and below 0 is the same.


-- 
Regards,
Mike



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] PHP_FLOAT_MIN is positive

[Joe Watkins]

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 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; // -9223372036854775808
> > echo PHP_FLOAT_MIN; // 2.2250738585072E-308
> >
> > If it is intended, maybe the doc
> >  should be clear
> > about this, at the moment it is just:
> >
> > Smallest representable floating point number.
> >
> >
> > Which is confusing IMO.
> >
> > Cheers,
> > Ben
> >
>

Re: [PHP-DEV] PHP_FLOAT_MIN is positive

[Diogo Neves]

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 as such is negative:
>
> echo PHP_INT_MIN; // -9223372036854775808
> echo PHP_FLOAT_MIN; // 2.2250738585072E-308
>
> If it is intended, maybe the doc
>  should be clear
> about this, at the moment it is just:
>
> Smallest representable floating point number.
>
>
> Which is confusing IMO.
>
> Cheers,
> Ben
>

[PHP-DEV] PHP_FLOAT_MIN is positive

[Benjamin Morel]

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; // -9223372036854775808
echo PHP_FLOAT_MIN; // 2.2250738585072E-308

If it is intended, maybe the doc
 should be clear
about this, at the moment it is just:

Smallest representable floating point number.


Which is confusing IMO.

Cheers,
Ben