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
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,
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
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
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
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
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 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 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 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
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 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
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 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);
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 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
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
>
> 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 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
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 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
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
22 matches
Mail list logo
