Hey everyone,
I'm new to the PHP community and have enjoyed learning the language over
the past year or so. I saw someone in the Laravel community mention how
they wished PHP had built-in functions for converting temperatures between
Fahrenheit and Celcius, and it seemed like a great small change to learn
how to contribute to PHP itself. So here I am!
I'd like edit access to the Wiki so I can submit a proper RFC. My Wiki
username is samldev.
Thanks!
Sam Lewis
Hi Sam
they wished PHP had built-in functions for converting temperatures between
Fahrenheit and Celcius, and it seemed like a great small change to learn
how to contribute to PHP itself. So here I am!
That's great. Adding functions definitely is the best way to get one’s
feet wet with contributing to PHP itself.
That said, PHP’s standard library is already pretty large and any new
addition should provide value to a large number of projects, given the
amount of work associated with it. A new function might conflict with
existing userland functions having the same name, it needs to be
documented (and documentation translated), it needs to be maintained for
20+ years and of course there's all the overhead of the RFC process.
I'm not sure if functionality to convert between Fahrenheit and Celsius
reaches that bar of usefulness and I doubt that an RFC proposing those
would pass.
I don't mean to discourage you from contributing and if you want, I
would be happy to review your implementation even if you decide not to
follow through with an RFC (ping @TimWolla on GitHub), perhaps it will
be useful for any other functionality you might come up with in the future.
And of course if you still plan to do the RFC that's also fine. But
someone else will need to grant you the RFC karma, as I do not have the
permissions to do so.
Best regards
Tim Düsterhus
Hi Sam
they wished PHP had built-in functions for converting temperatures between
Fahrenheit and Celcius, and it seemed like a great small change to learn
how to contribute to PHP itself. So here I am!That's great. Adding functions definitely is the best way to get one’s
feet wet with contributing to PHP itself.That said, PHP’s standard library is already pretty large and any new
addition should provide value to a large number of projects, given the
amount of work associated with it. A new function might conflict with
existing userland functions having the same name, it needs to be
documented (and documentation translated), it needs to be maintained for
20+ years and of course there's all the overhead of the RFC process.I'm not sure if functionality to convert between Fahrenheit and Celsius
reaches that bar of usefulness and I doubt that an RFC proposing those
would pass.I don't mean to discourage you from contributing and if you want, I
would be happy to review your implementation even if you decide not to
follow through with an RFC (ping @TimWolla on GitHub), perhaps it will
be useful for any other functionality you might come up with in the future.And of course if you still plan to do the RFC that's also fine. But
someone else will need to grant you the RFC karma, as I do not have the
permissions to do so.Best regards
Tim Düsterhus
Why stop at temperature though. It would (actually) be very useful to have a standard (built-in) way for units conversion in-general. Not just for Celsius to Fahrenheit, but also Kelvin. Hours, minutes, seconds, etc, as well. DateTime kinda-sorta handles time already -- if a bit clumsily.
— Rob
Thanks all for sharing your thoughts!
I would be happy to review your implementation even if you decide not to
follow through with an RFC (ping @TimWolla on GitHub)
I'll definitely take you up on this, thank you.
Why stop at temperature though
That's fair, maybe that will increase the value proposition of the RFC
enough to be worth considering more seriously.
Sam
Hi Sam
they wished PHP had built-in functions for converting temperatures
between
Fahrenheit and Celcius, and it seemed like a great small change to learn
how to contribute to PHP itself. So here I am!That's great. Adding functions definitely is the best way to get one’s
feet wet with contributing to PHP itself.That said, PHP’s standard library is already pretty large and any new
addition should provide value to a large number of projects, given the
amount of work associated with it. A new function might conflict with
existing userland functions having the same name, it needs to be
documented (and documentation translated), it needs to be maintained for
20+ years and of course there's all the overhead of the RFC process.I'm not sure if functionality to convert between Fahrenheit and Celsius
reaches that bar of usefulness and I doubt that an RFC proposing those
would pass.I don't mean to discourage you from contributing and if you want, I
would be happy to review your implementation even if you decide not to
follow through with an RFC (ping @TimWolla on GitHub), perhaps it will
be useful for any other functionality you might come up with in the future.And of course if you still plan to do the RFC that's also fine. But
someone else will need to grant you the RFC karma, as I do not have the
permissions to do so.Best regards
Tim DüsterhusWhy stop at temperature though. It would (actually) be very useful to have
a standard (built-in) way for units conversion in-general. Not just for
Celsius to Fahrenheit, but also Kelvin. Hours, minutes, seconds, etc, as
well. DateTime kinda-sorta handles time already -- if a bit clumsily.— Rob
Hi Sam
Please do not "top-post" on this mailing list. This means: Please put
your reply below the quoted part and ideally also cut the quoted part to
the minimum context that you actually want to reply to. You can see how
I did this in my first reply to you and also in this reply.
That's fair, maybe that will increase the value proposition of the RFC
enough to be worth considering more seriously.
A well-designed “Units extension” would certainly be more valuable that
adding a few functions without a clear plan / proper API design. But it
would probably still be something that would better be solved in
userland as a composer library. Unit conversions functions will likely
not experience a relevant performance improvement when implemented
natively, they are not particularly hard to implement with regard to
edge cases so that they would warrant a “well-tested” and “blessed” core
implementation and they are unlikely to be so commonly used that they
need to always be available. Having them in a userland API would also
allow them to move more quickly: New units could be added on-demand,
rather than being restricted to a once-per-year release cycle.
The type of functionality that is nowadays added to PHP’s standard
library is “building block” functionality: Functions that a userland
developer would commonly need in their custom library or application.
The array_find functions added in PHP 8.4 are a good example. It's
something that every major framework already implements in one way or
another, it fits with the existing array_filter functionality and it's
so generically useful that many libraries benefit from it.
The same is true for Randomizer::getBytesFromString() added in PHP
8.3. It's also commonly implemented and as it turns out, it is very
susceptible to being incorrectly implemented (due to off-by-one errors).
For that there's also the existing Randomizer class which a clear API
design and scope so that the function fits in nicely with the existing API.
Best regards
Tim Düsterhus
Hey Tim
Please do not "top-post" on this mailing list.
Thank you for the explanation, I saw this in the rules but the Gmail web
client did a good job hiding this from me :)
The type of functionality that is nowadays added to PHP’s standard
library is “building block” functionality: Functions that a userland
developer would commonly need in their custom library or application.
Thank you for this context and the examples, that is all super helpful
to understand where language contributions make sense. As I continue
writing PHP I'm sure this will start to become more obvious to me as well.
Thanks again for your friendly and informative responses, they are a model
for how to welcome a new person to any community!
Sam
Hi Sam, Tim, Rob
Maybe there could be another good feature to start with - the function to
format bytes into a human-readable format (for debug purpuses) to have
pretty view of the size (like 1.5GB, or 20MB)
Right now every time I need this, I find myself copying the function from
stack overflow, since PHP doesn't have any built-in solution:
https://stackoverflow.com/questions/2510434/format-bytes-to-kilobytes-megabytes-gigabytes
This is too little thing for having separate composer library, and perhaps
having it built-in would be better?
What do you think?
Hi
Maybe there could be another good feature to start with - the function to
format bytes into a human-readable format (for debug purpuses) to have
pretty view of the size (like 1.5GB, or 20MB)[…]
This is too little thing for having separate composer library, and perhaps
having it built-in would be better?
On a surface level such a function would appear to be very simple, but
the “human-readable format” bit alone already raises multiple questions,
with the most notable one being: What is human-readable?
There's different languages in the world and they all use different
decimal separators and group digits differently. And they possibly have
different rules with regard to whether or not a space is required
between the scalar part and the unit. In fact your example already is
incorrect English, because English requires a space between the scalar
part and the unit. And it should ideally be a non-breaking space.
So in English it would be:
- 1.5 GB
- 20 MB
In German we use the comma as the decimal separator (and also a space
before the unit), so it would need to be:
- 1,5 GB
- 20 MB
Then there's also the question of whether to use the binary scale or the
decimal scale. In other words: Should 1460 Bytes be rendered as 1.5 kB
or as 1.4 KiB?
Also: How many decimal digits should be printed? Should it even be a
fixed number of decimal digits, or are we rather interested in a total
number of significant digits? In more explicit terms:
For 2 decimal digits:
1234 Bytes -> 1.23 kB
12345 Bytes -> 12.35 kB
123456 Bytes -> 123.46 kB
For 3 significant digits:
1234 Bytes -> 1.23 kB
12345 Bytes -> 12.3 kB
123456 Bytes -> 123 kB
Then there's the question of when the next unit should be used. Should
the cut-off point be “there needs to be a 1 in front of the decimal
point”? In some cases printing 0.9 GB might be preferable to 900 MB.
I could probably go on and find further questions, but I believe this
already showcases how the devil is in the details - as with many RFCs
that look great on a surface level.
In this specific case of usefully formatting numbers, I can recommend
taking a look at the NumberFormatter class of ext/intl
(https://www.php.net/manual/en/class.numberformatter.php). The API is
not particularly pretty, but it handles the complex details of
“correctly formatting a float according to language rules”. AFAICT you
would still need to append the correct unit (and divide the number of
bytes) yourself, though.
Best regards
Tim Düsterhus
Hi Sam, Tim, Rob
Maybe there could be another good feature to start with - the function
to format bytes into a human-readable format (for debug purpuses) to
have pretty view of the size (like 1.5GB, or 20MB)Right now every time I need this, I find myself copying the function
from stack overflow, since PHP doesn't have any built-in solution:
https://stackoverflow.com/questions/2510434/format-bytes-to-kilobytes-megabytes-gigabytesThis is too little thing for having separate composer library, and
perhaps having it built-in would be better?What do you think?
Hi Sam
I'm new to the PHP community and have enjoyed learning the language over the past year or so. I saw someone in the Laravel community mention how they wished PHP had built-in functions for converting temperatures between Fahrenheit and Celcius, and it seemed like a great small change to learn how to contribute to PHP itself. So here I am!
I'd like edit access to the Wiki so I can submit a proper RFC. My Wiki username is samldev.
Sorry for the delay. Since you were in contact with other people I
wasn't sure if this was being handled. I have granted you RFC karma
now. Good luck!
Ilija