Hi Lynn,
> There are automated data exports with prices, that will be automatically
consumed on the other side.
I agree that these cases can go horribly wrong. However, my reasoning is
the following:
- if a piece of code currently relies on locale-independence (e.g.
automated data exports) then t
On 24-03-2020 10:21, Máté Kocsis wrote:
> Hi Larry,
>
> In my opinion, one of the core assets of PHP is that it contains relatively
> few syntactic sugar compared
> to some other languages, e.g. C#. Maybe it's just me, but I believe it
> makes the code written in PHP
> easier to read. And I think
On Tue, Mar 24, 2020 at 7:41 PM G. P. B. wrote:
> On Tue, 24 Mar 2020 at 11:03, Lynn wrote:
>
>> I would like
>> to see a warning of sorts so I can fix this before untested legacy code
>> will seriously break data exports.
>>
>> Regards,
>> Lynn
>>
>
> We are not saying that this won't be preva
On Tue, 24 Mar 2020 at 11:03, Lynn wrote:
> Hi,
>
> This is a great RFC! Just one minor thing.
>
> > Outputting floats as strings in locales which change the decimal
> separator will have a slightly different output. In our opinion, the
> backward compatibility break won't be serious in practice
>
> If the answer to that is "well don't do that", then what's the
> alternative? PHP offers no other syntax for evolvable immutable objects
> than private properties with Wither methods. Making Wither methods harder
> makes evolvable immutable objects harder. Unless there's some entirely
> diff
On 3/23/2020 3:53 PM, Johannes Schlüter wrote:
For Windows pecl produces builds where we can, while users have to
install by hand.
Yeah, I've noticed this and thought about building a tool to help
automate installation.
However, it would be much easier to use PECL extensions on Windows if
P
On Tue, 24 Mar 2020 at 14:28, Reindl Harald wrote:
>
> Am 24.03.20 um 15:23 schrieb Rowan Tommins:
> > On the other hand, this is exactly the kind of thing where
> strict_types=1 makes things worse - you'll actually get *better* error
> output if you use strict_types=0 and pass the string to a fu
Am 24.03.20 um 15:23 schrieb Rowan Tommins:
> On the other hand, this is exactly the kind of thing where strict_types=1
> makes things worse - you'll actually get *better* error output if you use
> strict_types=0 and pass the string to a function marked as requiring int
no!
with strict_types=
On 24 March 2020 13:32:35 GMT+00:00, Enno Woortmann
wrote:
> How about adding some syntactic sugar and
>allow type casting inside the detructuring expression?
>
>$data = "foo:*:1023:1000::/home/foo:/bin/sh";
>[$user, $pass, (int) $uid, (int) $gid, $gecos, $home, $shell] =
>explode(":", $data);
On Tue, Mar 24, 2020, at 6:52 AM, Nikita Popov wrote:
> On Mon, Mar 23, 2020 at 1:48 AM Larry Garfield
> Thanks for the write-up Larry. I like where you're going with this.
>
> If we were starting from a blank slate design, I would advocate for:
>
> a) having an object initializer syntax
> b) n
On 3/23/2020 12:08 PM, Rowan Tommins wrote:
On Mar 23, 2020, at 1:51 PM, Ben Ramsey wrote:
Thank you, yes, that's exactly what I'm saying. PHP is, right now, a
modular product.
some have to be painfully worked around (e.g. curl).
Not sure it's as painful as you've said:
https://github.com/cu
Hi,
currently when using array destructuring the variables are assigned as
they are. For example we split a string with explode all variables will
contain strings:
$data = "foo:*:1023:1000::/home/foo:/bin/sh";
[$user, $pass, $uid, $gid, $gecos, $home, $shell] = explode(":", $data);
If we want t
On Mon, Mar 23, 2020 at 1:48 AM Larry Garfield
wrote:
> Hi folks.
>
> There have been a lot of RFCs and possible RFCs of late that are all
> circling around the same related problem space: Working with objects right
> now involves too much boilerplate to get things done. As I've mentioned
> seve
On 23/03/2020 17:58, jan.h.boeh...@gmx.de wrote:
I have opened voting on
https://wiki.php.net/rfc/userspace_operator_overloading, which allows users
to overload operators in their own classes.
I am certainly not opposed to operator overloading, and would like to
see it in the language.
Howev
On 24.03.2020 at 11:03, Lynn wrote:
>> Outputting floats as strings in locales which change the decimal
>> separator will have a slightly different output. In our opinion, the
>> backward compatibility break won't be serious in practice
>
> In my opinion, this will be huge. I can't trace back wher
On Mon, Mar 23, 2020 at 6:58 PM wrote:
> Hi internals,
>
> I have opened voting on
> https://wiki.php.net/rfc/userspace_operator_overloading, which allows
> users
> to overload operators in their own classes.
>
> Voting closes on 2020-04-06.
>
> Regards,
> Jan Böhmer
>
To offer a counter-point,
On Tue, Mar 24, 2020 at 10:40 AM Máté Kocsis wrote:
> Hi Internals,
>
> Together with George, I'd like to propose an RFC for a long-standing
> problem PHP has:
> casting floats to string depends on the locale settings. As this behaviour
> is nonsense, and
> because it can cause quite serious prob
Am 24.03.2020 um 11:03 schrieb Marco Pivetta:
Just posting here why I voted "no": it is not your implementation proposal,
but rather the concept per-se that IMO shouldn't land in the language.
I voted "no" for the same reason.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscr
Hey Jan,
Just posting here why I voted "no": it is not your implementation proposal,
but rather the concept per-se that IMO shouldn't land in the language.
Operator overloading makes call-site code reading extremely hard, and it
makes the language much more complex for very little benefit.
Every
Hi,
This is a great RFC! Just one minor thing.
> Outputting floats as strings in locales which change the decimal
separator will have a slightly different output. In our opinion, the
backward compatibility break won't be serious in practice
In my opinion, this will be huge. I can't trace back wh
Hi Internals,
Together with George, I'd like to propose an RFC for a long-standing
problem PHP has:
casting floats to string depends on the locale settings. As this behaviour
is nonsense, and
because it can cause quite serious problems, we would like to get rid of
locale-dependence
in PHP 8.
Plea
Hi Larry,
In my opinion, one of the core assets of PHP is that it contains relatively
few syntactic sugar compared
to some other languages, e.g. C#. Maybe it's just me, but I believe it
makes the code written in PHP
easier to read. And I think this is what we should optimize for. Not for
saving a
22 matches
Mail list logo
