Hi Nikita,
śr., 3 mar 2021, 16:04 użytkownik Nikita Popov
napisał:
> Hi internals,
>
> I would like to propose allowing the use of "new" inside various
> initializer expressions: https://wiki.php.net/rfc/new_in_initializers
>
> In particular, this allows specifying object default values for
On Mar 3, 2021, at 14:25, Kamil Tekiela wrote:
>
> when both are strings then chances are that this is an error.
Except when comparing two values from sources known to provide numbers as
strings, such as form input and database results. :-)
Cheers,
Ben
signature.asc
Description: Message
> Hello again everyone!
>
> Based upon feedback both on this list and elsewhere, I’ve decided to remove
> the FiberScheduler API from the fiber proposal.
>
> The FiberScheduler API greatly increased the complexity of the implementation
> and the potential for edge cases that would need to be
Am 03.03.2021 um 21:25 schrieb Kamil Tekiela :
> Sorry Nikita, but adding special handling for edge-cases is only going to
> make things messier.
I didn't want to say that, as there is plenty of code out there who might fall
in this trap this intermediate measure might still make sense.
The
Oh, I like Chris's idea. Yes, please.
Let's deprecate numerical comparison when both operands are strings and
remove that behaviour in PHP 9.0.
Type juggling can be useful when one of them is an integer or float but
when both are strings then chances are that this is an error.
Sorry Nikita, but
Am 03.03.2021 um 19:21 schrieb Stanislav Malyshev :
> Nobody who applies == to strings and expects it to work out as stri g
> comparison is doing the right thing. If you apply == to hex-encoded hashes,
> that code is fubar, and fixing one particular corner case won't rescue it. So
> I wonder if
This is
On Wed, Mar 3, 2021 at 4:04 PM Nikita Popov wrote:
> Hi internals,
>
> I would like to propose allowing the use of "new" inside various
> initializer expressions: https://wiki.php.net/rfc/new_in_initializers
>
> In particular, this allows specifying object default values for properties
Hi!
PHP's == comparison semantics for strings have a peculiar edge-case, where
comparisons of the form "0e123" == "0e456" return true, because they are
interpreted as floating point zero numbers. This is problematic, because
strings of that form are usually not numbers, but hex-encoded hashes
On Wed, Mar 3, 2021 at 5:49 PM Nikita Popov wrote:
> On Wed, Mar 3, 2021 at 4:28 PM Alexandru Pătrănescu
> wrote:
>
>> Hi,
>>
>> This looks very nice and I'm interested in further steps where not only
>> new can be used :).
>>
>> The only thing I think it would be good to improve is to have a
> Am 03.03.2021 um 14:01 schrieb Andreas Heigl :
>
> I'd rather see those classes as ValueObjects that should not have to
> take care about their external representation. And a custom Formatter
> that handles all the weird edge cases as a separate entity would be a
> much easier to maintain
> On Mar 3, 2021, at 09:03, Nikita Popov wrote:
>
> Hi internals,
>
> I would like to propose allowing the use of "new" inside various
> initializer expressions: https://wiki.php.net/rfc/new_in_initializers
>
> In particular, this allows specifying object default values for properties
> and
On Wed, Mar 3, 2021 at 4:28 PM Alexandru Pătrănescu
wrote:
> Hi,
>
> This looks very nice and I'm interested in further steps where not only
> new can be used :).
>
> The only thing I think it would be good to improve is to have a
> deterministic order for running initialization.
> Yes, this can
> On Mar 3, 2021, at 08:04, Nikita Popov wrote:
>
> Hi internals,
>
> PHP's == comparison semantics for strings have a peculiar edge-case, where
> comparisons of the form "0e123" == "0e456" return true, because they are
> interpreted as floating point zero numbers. This is problematic, because
On Wed, Mar 3, 2021 at 8:42 AM Andreas Heigl wrote:
>
> Am 03.03.21 um 14:24 schrieb Moritz Friedrich:
> >
> >
> >> Am 03.03.2021 um 14:01 schrieb Andreas Heigl :
> >>
> >> I'd rather see those classes as ValueObjects that should not have to
> >> take care about their external representation.
Hi,
This looks very nice and I'm interested in further steps where not only new
can be used :).
The only thing I think it would be good to improve is to have a
deterministic order for running initialization.
Yes, this can be done at a later point, I guess. But maybe there is already
an order of
Am 03.03.2021 um 11:53 schrieb Pierre :
>
> Le 03/03/2021 à 11:37, Moritz Friedrich a écrit :
>> Hi internals,
>> I’ve been active in the PHP ecosystem as @Radiergummi for quite a while now,
>> but not on internals yet, so: nice to meet you all!
>>
>> I would like to propose adding a
Hi internals,
I would like to propose allowing the use of "new" inside various
initializer expressions: https://wiki.php.net/rfc/new_in_initializers
In particular, this allows specifying object default values for properties
and parameters, and allows the use of objects as attribute arguments.
Hi internals,
I’ve been active in the PHP ecosystem as @Radiergummi for quite a while now,
but not on internals yet, so: nice to meet you all!
I would like to propose adding a `__toString()` method to the `DateInterval`
class that should return a valid ISO8601 interval
Hi internals,
PHP's == comparison semantics for strings have a peculiar edge-case, where
comparisons of the form "0e123" == "0e456" return true, because they are
interpreted as floating point zero numbers. This is problematic, because
strings of that form are usually not numbers, but hex-encoded
On Wed, Mar 3, 2021, at 4:37 AM, Moritz Friedrich wrote:
> Hi internals,
> I’ve been active in the PHP ecosystem as @Radiergummi for quite a while
> now, but not on internals yet, so: nice to meet you all!
>
> I would like to propose adding a `__toString()` method to the
> `DateInterval` class
Am 03.03.21 um 14:24 schrieb Moritz Friedrich:
>
>
>> Am 03.03.2021 um 14:01 schrieb Andreas Heigl :
>>
>> I'd rather see those classes as ValueObjects that should not have to
>> take care about their external representation. And a custom Formatter
>> that handles all the weird edge cases as a
Hey
Am 03.03.21 um 13:05 schrieb Hans Henrik Bergan:
> if FWIW if DateTime::__toString() was just
> function __toString():string{
> return $this->format(\DateTime::RFC3339);
> }
>
> i certainly wouldn't complain.
>
> On Wed, 3 Mar 2021 at 12:16, Bruce Weirdan wrote:
>
>> On Wed, Mar 3,
Le 03/03/2021 à 13:05, Hans Henrik Bergan a écrit :
if FWIW if DateTime::__toString() was just
function __toString():string{
return $this->format(\DateTime::RFC3339);
}
i certainly wouldn't complain.
On Wed, 3 Mar 2021 at 12:16, Bruce Weirdan wrote:
Considering the replies, PHP
if FWIW if DateTime::__toString() was just
function __toString():string{
return $this->format(\DateTime::RFC3339);
}
i certainly wouldn't complain.
On Wed, 3 Mar 2021 at 12:16, Bruce Weirdan wrote:
> On Wed, Mar 3, 2021 at 1:07 PM Moritz Friedrich wrote:
>
> > but I’m not too fond of the
On Wed, Mar 3, 2021 at 1:07 PM Moritz Friedrich wrote:
> but I’m not too fond of the constant - all other built-in date constants
> translate to a string of plain format characters, which isn’t possible in
> this case
Adding another format character (similar to %c used by
Le 03/03/2021 à 11:37, Moritz Friedrich a écrit :
Hi internals,
I’ve been active in the PHP ecosystem as @Radiergummi for quite a while now,
but not on internals yet, so: nice to meet you all!
I would like to propose adding a `__toString()` method to the `DateInterval`
class that should
26 matches
Mail list logo
