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 prop
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 sig
> 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 good
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 add
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 or
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 app
> 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 par
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. And
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 i
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 `__toString
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.
Th
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
(https://en.wikipedia.org
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 h
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 t
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 s
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, 202
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 Date(Tim
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 c
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
DateTimeInterface::for
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 return
26 matches
Mail list logo
