Re: [PHP-DEV] [RFC] [DISCUSSION] Locale-independent float to string cast
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 this change wouldn't cause any breakage since a workaround has already been in place there (e.g. the programmers use var_export() instead of casting) - if a piece of code relies on the locale-dependent string representation of floats then there will be a BC break, sure, however I believe that code isn't very sensitive to the change in the vast majority of the cases since that data is for presentation purposes only. Or do you have other locale-dependent use-cases in mind? I am sure there are some but I think the number of the situations where the change is problematic is less than what it first seems. Regards, Máté
Re: [PHP-DEV] Improving PHP's Object Egonomics: A broad analysis
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 this is what we should optimize for. Not for > saving a few lines of code, > but for making the code easier to read and understand. It's not just you. :) I fully agree with you here. PHP has a straight, down-to-earth character with very little magic going on. This is what makes the code easy to understand and debug. I just would not use the term 'syntactic sugar' in this context. To me, syntactic sugar has a positive connotation: A nicer way to express the same thing that is easier to read. Magic is making things happen in non-obvious ways that are easily missed when looking at the code. Magic can look really attractive, until something does not work as expected and you fail to see why. Python code tends to have tons of it. The point where sugar ends and magic begins is a matter of taste. To me, constructor promotion tends slightly towards magic. But then, anyone can choose to use the feature or not. > To be honest, my impression is that most of the problems you list (e.g. > verbose constructor, bean problem, > or even property accessors) mainly boil down to the verbosity of PHP (or > the "visual debt" problem > how some people calls it). As I wrote in the first paragraph, I don't think > it's a bad thing. Reducing verbosity is not the problem. Introducing magic is. While property accessors are magic, they are a form of magic that I would be willing to accept, for the following reasons. A nice feature of accessors is that they allow swapping a traditional public class property for a property accessor without changing API. Such a feature currently has little value, because public properties are not commonly used because they cannot be marked as read-only yet. Once public class properties can be marked read-only I would be comfortable exposing them directly, without writing any getters and setters for them. The only thing that would still worry me is: What if I need to add some form of access logic later on? Property accessors allow me to do this without introducing a BC break. So yes, property accessors are magic. However, in combination with read-only properties they would allow for dropping tons of getter methods and directly expose properties in stead. They allow this because they are the 'safety net' which makes me comfortable doing it. We get more PHP and less Java. This probably means that I will occasionally have to actually use property accessors at some point and introduce a bit of magic. Then, it still isn't the worst possible magic. Accessors are explicitly declared on the class, an editor could easily show me that accessing a particular property calls a method and show me the code. It's not ideal but it's not that bad either. > But I don't understand why is would be a good thing to have two types of > methods? How should we decide if we > should use normal methods or property accessors? I think the current I would prefer to only use accessors to add logic to property access without introducing a BC break. A successor to using __get() and __set(). For access logic that is obviously non-trivial from the start I would probably continue to use regular getter and setter methods. > I still don't think that property accessors would solve the main use-case > of "write-once" properties. Indeed. For that purpose I would prefer a keyword for marking a public property as read-only. Regards, Dik Takken -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] Locale-independent float to string cast
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 prevalent,especially in legacy code, > however, IMHO, this is not a serious issue as it is only a matter how one > character is displayed to end users. > It's so much more than a character that's being displayed. There are automated data exports with prices, that will be automatically consumed on the other side. These kind of changes can seriously break if they were expected to be localized currency formats. We're talking massive amounts of data here. I've seen price formats go wrong often and seen them be fixed even up to a week ago. It's hard to track all usages in a 20 year old code base. As much as I love that this can be fixed, I rather not see it fixed at all if there's no upgrade path available. Regards, Lynn
Re: [PHP-DEV] [RFC] [DISCUSSION] Locale-independent float to string cast
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 > > In my opinion, this will be huge. I can't trace back where the thousands of > possible conversions are used in legacy software. There's a variety of > custom format functions, sprintf implementations, string casts, and > number_format usages. Would it be possible to trigger a warning or > deprecation when using a locale that would have a different result from > what the new result will be? If I'd use a locale that results in `3.5`, I > don't need a warning. If I use a locale that results in `3,5`, 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 prevalent,especially in legacy code, however, IMHO, this is not a serious issue as it is only a matter how one character is displayed to end users. As said by Christoph we did not consider a deprecation warning due to the performance impact this would lead to as float to string conversions are a common operation. The idea of a temporary INI setting which warn about these conversions is an interesting idea, but I personally would rather not introduce one. Moreover, with a temporary INI setting how long would it last, one minor version, one major version? Something in between the two? On Tue, 24 Mar 2020 at 11:15, Nikita Popov wrote: > I'm obviously in favor of this proposal. > > Only really comment I have is on printf(): You're right that we have %f and > %F to toggle locale-sensitivity, but the %e, %E, %g, %G formats are always > locale-sensitive. It might make sense to introduce locale-insensitive > variants of those, especially considering that %G is considered the > "standard" floating point format. Internally we support %H for that, so we > could expose that... (Alternatively, locale-sensitivity might be removed > for e/E/g/G.) > > Regards, > Nikita *sight* I was not aware of this issue ... Personally, I would prefer that %e and %E are not locale aware as they are meant to represent a standard notation. This would then mean that %g is locale aware as %f is and %G is not because %E and %F are not locale aware. But I'm open to suggestion considering this edge case. Best regards George P. Banyard
Re: [PHP-DEV] Improving PHP's Object Egonomics: A broad analysis
>
> 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
> different approach I am not aware of to achieve the same goal, in which
> case please share. :-)
>
For transparency purposes: the idea I presented during the discussion of
"write-once" properties was
to make the following syntax (or a similar one) possible in order to make
cloning of these properties possible:
> $self = clone $this with {property1: "foo", ...};
It would clone the object and in the same time change the listed properties
(no matter if they have the "write-once"
flag). It would also take visibility rules into account, so a private
property could only be modified in the private scope.
I think this idea would address your concerns, although I haven't received
any feedback about it yet,
so I'm not sure if it has any gotchas/edge cases that would make it or its
implementation infeasible.
Máté
Re: [PHP-DEV] Are PECL modules preferable?
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 PHP on Windows actually had a simple way to add all the DLLs in a PECL extension to *just* the 'ext' directory and not have to copy multiple DLLs all over the place. For example, imagick has a ton of imported DLLs that are referenced by the main extension DLL, which fails to load for a lot of people. Then they have to go searching Google to figure out how to fix it for each separate SAPI. I'm thinking the problem is something that can be remedied with SetDllDirectory(): https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-setdlldirectorya Or AddDllDirectory(): https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-adddlldirectory Depending on if WinXP support is still a thing and/or having multiple directories is even possible. Calling LoadLibraryEx() looks like it would be a pain to implement given that the only references in the entire code to "LoadLibrary" is pushed all the way back into m4/configure? As PHP parses the 'extension_dir' INI option, it could call the relevant function above to allow for loading additional DLLs from the same directory when loading extensions. Doing that would fix so many Windows loader related issues that people have with getting the precompiled PECL extensions to work on Windows (especially with mixed SAPI environments). -- Thomas Hruska CubicleSoft President I've got great, time saving software that you will find useful. http://cubiclesoft.com/ And once you find my software useful: http://cubiclesoft.com/donate/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type casting while array destructuring
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 function marked
> as requiring int
> no!
>
> with strict_types=0 the casting simp,y happens by the caller and you get
> no error at all
>
Only if the string is a valid integer; compare https://3v4l.org/uvPYZ with
https://3v4l.org/h1aT5
function foo(int $x) { var_dump($x); }
declare(strict_types=1);
$a = 'hello';
$a = (int)$a; // cast doesn't produce any errors
foo($a); // dumps int(0)
declare(strict_types=0);
$a = 'hello';
foo($a); // TypeError: Argument 1 passed to foo() must be of the type int,
string given
That's what I mean about "stricter casting" - (int)$a basically always
succeeds, so it would be useful to have a version that rejects things like
non-integer strings. That could be Yet Another Runtime Mode using
declare(), but it could just be a different syntax, so that you'd write
this:
// regardless of which strict_types mode you're in
$a = 'hello';
$a = (int!)$a; // TypeError: string value is not valid for strict cast to
type int
foo($a); // statement never reached
Regards,
--
Rowan Tommins
[IMSoP]
Re: [PHP-DEV] Type casting while array destructuring
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=0 the casting simp,y happens by the caller and you get no error at all -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type casting while array destructuring
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 the one hand, this seems fairly straightforward, and although casts wouldn't
normally appear on the left side of an expression, the intent is pretty clear.
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. By
forcing a cast, you're actually silencing the error, and turning all
unrecognised values to 0.
If the desire is for stricter type handling, we probably need stricter casts,
perhaps using different syntax like (int!) rather than just more places to put
the existing ones.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improving PHP's Object Egonomics: A broad analysis
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) not having first-class constructors at all
> c) using named constructors instead.
>
> This also happens to be exactly what Rust does, go figure... Unfortunately
> this kind of approach is hard to retrofit into PHP, because we already have
> constructors, almost all classes define them, and it's hard to reconcile
> object initialization syntax and non-trivial constructors in a meaningful
> way. Combining this with the "no public properties" cargo cult we have
> inherited from Java, the paradigm shift is probably too large here.
If wishes were horses, I'd agree. Though both you and Mate mentioned named
constructors; I am not sure how that would play into the compacted constructor
here.
> If we can't have object initializers, then improving what we can do with
> constructors is the next best thing :)
>
> I generally like the ideal of combining property declaration and
> constructors. I've had this on my mind for a while already, and also
> received the same suggestion from a couple of other people (I think Nicolas
> was one of them?) The current amount of boilerplate that is needed is just
> large enough that I will often go with a quick and simple ad-hoc array
> structure rather than declaring an explicit value object type. The main
> concern, as others have already mentioned, is that these inline
> declarations can end up being quite verbose, especially once attributes get
> involved.
>
> I think I will write up a quick implementation & RFC for this part, as it
> seems like something we should at least consider in more detail.
I look forward to it! I am quite open to alternate syntaxes that are more
amenable to attributes and delegation, as long as the net result is what we're
after: Less repetition so making record-like classes is easier.
> Named parameters are a pretty tough topic. I think one of the main points
> of contention is that they make the parameters names part of the API
> contract, and as such also subject to LSP. Your proposal offers two
> possible ways to side-step this: First, by making named parameters opt-in
> with a special syntax {}. Second, by limiting them to constructors. The
> latter variant still exposes parameter names in the API, but at least does
> not require their preservation across inheritance, as constructors are
> excluded from LSP. I'm somewhat torn on this, because it makes named
> parameters unusable with the very large body of existing methods, and
> introduces an inconsistency in which methods can use named params and which
> don't.
My own feeling here is that making people care about parameter names is not
actually that big of a deal. You should really be caring about variable names
anyway. Python seems to do fine with named parameters being part of the
contract AFAIK. Especially if we could get it in for PHP 8, that's a major
anyway, so I would be fine with it.
The other options (opt-in or constructor only) are IMO fallbacks in case we're
nervous about it, or if the parser ends up being happier with a more explicit
syntax. (Gotta keep the parser happy.)
> Regarding the remainder, I think that all of readonly properties,
> asymmetric visibility and property accessors have their place and value,
> with some overlap between them. As you already mentioned, the previous
> property accessors proposal also included asymettric visibility as a
> special case, and that's how I would introduce it as well.
>
> However, I generally think that the main value really is the readonly
> properties as proposed in the recent RFC. Nowadays, a large fraction of the
> classes I use are immutable value objects, for which public readonly
> properties provide a much closer match to the semantics I want.
>
> I think that the problem with with-er methods is just that: It's a problem
> with with-er methods. It's what happens when you try to shove immutability
> into something that is not actually being used in an immutable manner.
> Don't pretend things are immutable when they aren't...
>
> Regards,
> Nikita
I agree that Withers are solving an odd problem; however, it's the same
approach that PHP itself takes already. Consider DateTimeImmutable:
$d = new DateTimeImmutable();
$d2 = $d->setDate(2020, 1, 3)
->setTime(12, 45)
->setTimezone(new DateTimeZone('America/Chicago')
->modify('+1 week');
That's a Wither pattern. The names a a bit wonky for compatibility with
DateTime, but that's the exact approach that Wither methods model. From a user
perspective it's pretty good.
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
Re: [PHP-DEV] Are PECL modules preferable?
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/cubiclesoft/ultimate-web-scraper/blob/master/docs/emulate_curl.md On a side note, good PHP userland streams-based implementations are faster than the ext/curl extension. The ext/curl extension also doesn't emit as much useful debugging information. -- Thomas Hruska CubicleSoft President I've got great, time saving software that you will find useful. http://cubiclesoft.com/ And once you find my software useful: http://cubiclesoft.com/donate/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Type casting while array destructuring
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 to write functions consuming $uid and $gid as integer values
with strict types enabled we need to cast the values afterwards:
$uid = (int) $uid;
$gid = (int) $gid;
// or during the function call
$myConsumingObject->myConsumingFunction((int) $uid, (int) $gid);
I think you get my point. 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);
// $uid and $gid are integer values now. All other variables remain as
they are and contain strings
An example with associative arrays in loops:
$array = [
[
'name' => 'a',
'id' => '1'
],
[
'name' => 'b',
'id' => '2'
],
];
foreach ($array as ['id' => (int) $id, 'name' => $name]) {
// $id contains integer values
}
Further thoughts: when using the list() reference assignment implemented
in PHP7.3 the referenced value could be casted (something to discuss
about, maybe as future scope as casting a reference assignment currently
isn't supported):
$array = [1, 2];
[(string) $a, (string) &$b] = $array;
// $a would be a string: '1'
// $b would be a string: '2'
// $array would contain one integer and one string element: [1, '2']
Thoughts?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improving PHP's Object Egonomics: A broad analysis
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
> several times, I believe we need to be looking for broader solutions rather
> than narrowly-focused one-offs.
>
> To that end, I have written an extensive analysis of the problem space and
> the current and recent proposals. I've put it on my blog rather than
> inline here because it's quite long and the blog offers better formatting.
>
> Discussion can happen here, but I'll also respond to comments there.
>
> In short: I believe our biggest potential win is to focus on 3 RFCs:
>
> * Constructor Promotion
> * Named parameters
> * Compound Property Visibility
>
> For details, see the full writeup:
>
> https://hive.blog/php/@crell/improving-php-s-object-ergonomics
>
> Thank you for your attention.
>
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) not having first-class constructors at all
c) using named constructors instead.
This also happens to be exactly what Rust does, go figure... Unfortunately
this kind of approach is hard to retrofit into PHP, because we already have
constructors, almost all classes define them, and it's hard to reconcile
object initialization syntax and non-trivial constructors in a meaningful
way. Combining this with the "no public properties" cargo cult we have
inherited from Java, the paradigm shift is probably too large here.
If we can't have object initializers, then improving what we can do with
constructors is the next best thing :)
I generally like the ideal of combining property declaration and
constructors. I've had this on my mind for a while already, and also
received the same suggestion from a couple of other people (I think Nicolas
was one of them?) The current amount of boilerplate that is needed is just
large enough that I will often go with a quick and simple ad-hoc array
structure rather than declaring an explicit value object type. The main
concern, as others have already mentioned, is that these inline
declarations can end up being quite verbose, especially once attributes get
involved.
I think I will write up a quick implementation & RFC for this part, as it
seems like something we should at least consider in more detail.
Named parameters are a pretty tough topic. I think one of the main points
of contention is that they make the parameters names part of the API
contract, and as such also subject to LSP. Your proposal offers two
possible ways to side-step this: First, by making named parameters opt-in
with a special syntax {}. Second, by limiting them to constructors. The
latter variant still exposes parameter names in the API, but at least does
not require their preservation across inheritance, as constructors are
excluded from LSP. I'm somewhat torn on this, because it makes named
parameters unusable with the very large body of existing methods, and
introduces an inconsistency in which methods can use named params and which
don't.
Regarding the remainder, I think that all of readonly properties,
asymmetric visibility and property accessors have their place and value,
with some overlap between them. As you already mentioned, the previous
property accessors proposal also included asymettric visibility as a
special case, and that's how I would introduce it as well.
However, I generally think that the main value really is the readonly
properties as proposed in the recent RFC. Nowadays, a large fraction of the
classes I use are immutable value objects, for which public readonly
properties provide a much closer match to the semantics I want.
I think that the problem with with-er methods is just that: It's a problem
with with-er methods. It's what happens when you try to shove immutability
into something that is not actually being used in an immutable manner.
Don't pretend things are immutable when they aren't...
Regards,
Nikita
[PHP-DEV] Re: [VOTE] Userspace operator overloading
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. However, I'll be voting no because of a couple of implementation points: 1. I feel like the choice of NULL as the return type for not implemented is far from ideal, especially for 8.0 which provides for union type hints. 2. The error handling behaviour is too timid. If operator overloading is to become a first-class feature, error handling should reflect as such and any attempt to use objects without the appropriate handlers being installed really should result in an error being thrown just as it would be if an undefined method was called. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] Locale-independent float to string cast
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 where the thousands of > possible conversions are used in legacy software. There's a variety of > custom format functions, sprintf implementations, string casts, and > number_format usages. Would it be possible to trigger a warning or > deprecation when using a locale that would have a different result from > what the new result will be? If I'd use a locale that results in `3.5`, I > don't need a warning. If I use a locale that results in `3,5`, I would like > to see a warning of sorts so I can fix this before untested legacy code > will seriously break data exports. It would certainly be *possible* to raise a warning/notice if a (non SCCP optimized) float to string conversion would have different results. This would have a (small) performance impact though, so I'd would rather avoid enforcing it (i.e. maybe temporarily introduce an INI directive for this purpose). -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Userspace operator overloading
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, I voted yes on this proposal. A couple of thoughts: 1. This is exposing functionality that already exists for internal classes to userland classes. As a general rule, I think we should always strive to have behavioral parity between internal and userland classes. 2. Because this just exposes existing functionality, the amount of technical complexity this introduces is very small, especially compared to the significance of what this enables. The implementation complexity of RFCs is increasingly becoming a problem, due to the complex way in which existing language features interact. This RFC does not fall into that category. 3. As mentioned, this functionality already exists internally and is used by GMP, where it works (imho) very well. Of course, this is also something of a poster-child use case for operator overloading, in that the object literally represents a number. But there are plenty other similar examples, some of them very relevant to PHP (money represention). I think there is a somewhat irrational fear that operator overloading is going to be misused... but having worked in quite a few languages that do support operator overloading, I think I've only encountered this in two instances: First, the infamous use of << and >> as stream operators in C++ (which is really horrible, and gives operator overloading a bad name everywhere). And second, the use of / as a path concatenation operator in some libraries. And I think that's it. All other uses I've worked with were things like arbitrary-precision integers, floats, decimals or rationals; complex numbers, vectors, matrixes or tensors; bit vectors, constant ranges, known bits representations. Operator overloading is not a feature that is commonly needed or should be used much, but it does tend to make code a *lot* more readable in the cases where it is useful. I think people might also find this blog post by Guido interesting: https://neopythonic.blogspot.com/2019/03/why-operators-are-useful.html Regards, Nikita
Re: [PHP-DEV] [RFC] [DISCUSSION] Locale-independent float to string cast
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 problems, we would like to get rid of > locale-dependence > in PHP 8. > > Please find our RFC at > https://wiki.php.net/rfc/locale_independent_float_to_string. > I'm obviously in favor of this proposal. Only really comment I have is on printf(): You're right that we have %f and %F to toggle locale-sensitivity, but the %e, %E, %g, %G formats are always locale-sensitive. It might make sense to introduce locale-insensitive variants of those, especially considering that %G is considered the "standard" floating point format. Internally we support %H for that, so we could expose that... (Alternatively, locale-sensitivity might be removed for e/E/g/G.) Regards, Nikita
Re: [PHP-DEV] [VOTE] Userspace operator overloading
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 unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Userspace operator overloading
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. Everything suggested in the RFC can be done by using explicit arrows: `->` (method calls), which lead to expressively named methods and parameters. I have posted similar thoughts about `->__toString()` and `->toString()` when it comes to cast operations vs explicit calls at https://github.com/ShittySoft/symfony-live-berlin-2018-doctrine-tutorial/pull/3#issuecomment-460441229 Overall, without type classes and infix functions, operator overloading is, IMO, just messy. Greets, Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] [DISCUSSION] Locale-independent float to string cast
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 where the thousands of possible conversions are used in legacy software. There's a variety of custom format functions, sprintf implementations, string casts, and number_format usages. Would it be possible to trigger a warning or deprecation when using a locale that would have a different result from what the new result will be? If I'd use a locale that results in `3.5`, I don't need a warning. If I use a locale that results in `3,5`, 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 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 problems, we would like to get rid of > locale-dependence > in PHP 8. > > Please find our RFC at > https://wiki.php.net/rfc/locale_independent_float_to_string. > > Regards, > George and Máté >
[PHP-DEV] [RFC] [DISCUSSION] Locale-independent float to string cast
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. Please find our RFC at https://wiki.php.net/rfc/locale_independent_float_to_string. Regards, George and Máté
Re: [PHP-DEV] Improving PHP's Object Egonomics: A broad analysis
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 few lines of code, but for making the code easier to read and understand. Now, if we had constructor promotion, we should search for properties both on the top of the class and in the constructor. And I agree with Michał, this kind of code can get out of hand of control very fast. That said, I don't think that declaring properties in the constructor is a good idea. It's also because many people (including myself) tend to write static methods first (I mainly use them as named constructors), so we'd either lose track of properties declared in the constructor or have to force a code style that puts the constructor to the top. Also, some IDEs (but PHPStorm for sure) can generate the constructor very easily from the declared properties. Speaking about the evaluation of "Write-Once Properties" and "Compound Property Visibility", I disagree in some regards. I'll start with the less important one: > Because the write-once state is preserved across cloning, it makes > Evolution worse. I think it's quite expected that properties won't be writable after cloning. That would be a very bad design otherwise. That's why I think your real problem is the opposite: that currently the clone operator is not prepared for this change. That's why I missed the "Rust-like cloning" (or the other clone variant that I presented in the "write-once property" thread) as the solution of the "Evolution" problem of "write-once" properties. My other problem with the evaluation of the "Immutability problem" is that it suggests that immutability is only an external concern, and it isn't a thing in the private/protected scope. Why do you think so? Currently (unfortunately) visibility is the only thing that can at some extent (in external scopes) control mutability in PHP. However, if we look at the problem from the type system perspective, visibility has nothing to do with it: we won't have any guarantee that a property is immutable even if we make it private. To be honest, my impression is that most of the problems you list (e.g. verbose constructor, bean problem, or even property accessors) mainly boil down to the verbosity of PHP (or the "visual debt" problem how some people calls it). As I wrote in the first paragraph, I don't think it's a bad thing. For example, if we had "compound property visibility" then we could separate read/write visibility of properties without using getters/setters (I think this is what you also wrote). If we had property accessors then besides the separation of visibility, we could have materalized properties or properties that validate themselves. Probably the syntax would become more concise, but effectively we would make methods from the properties. But I don't understand why is would be a good thing to have two types of methods? How should we decide if we should use normal methods or property accessors? I think the current situation is much better: use getters and/or setters to separate visibility of properties, and perform validation in setters if you need it. And I I still don't think that property accessors would solve the main use-case of "write-once" properties. Cheers, Máté
