Re: [PHP-DEV] Updates needed to various RFCs

[Jorg Sowa]

Thank you, Juliette. I added missing information to my RFC: Raising zero to
the power of negative number.

Kind regards,
Jorg

Re: [PHP-DEV] Re: [Discussion] Add date_test_set_now() function

[Jorg Sowa]

> You don’t make any effort to help or provide constructive criticism; you
just love to (incorrectly) tell everyone what they're doing wrong and how
they should be doing it, without adding anything constructive to the
conversation.

Please limit to the arguments on the topic, not a person.

The argument "Relying on the global mutable state is a bug" is completely
valid and in most of the cases is the signal of bad design. And it has been
already addressed in some of the functions, look at
https://wiki.php.net/rfc/deprecations_php_8_3 for deprecations on rand
functions. However, it's not so trivial to fix everything introducing
compatibility-breaking changes. So it shouldn't be advised to add more of
such functions.

Kind regards,
Jorg

Re: [PHP-DEV] [RFC] Static Constructor

[Jorg Sowa]

Hi Erick,
It would be useful to include the example of Singleton implementation with
a static constructor.

Kind regards,
Jorg

Re: [PHP-DEV] [RFC] [discussion] Correctly name the rounding mode and make it an Enum

[Jorg Sowa]

> It should also be noted that ceil/floor is very English specific
terminology that may not be immediately obvious to non-English speakers,
thus my preference for using some variation of towards positive/negative
infinity.

This statement is subjective in my opinion. For me, it's the contrary,
that's why I'm opposing introducing new terms to the PHP replacing ones
that already exist (ceil()/floor()). I don't have the data on such modes in
other programming languages, but I checked the data in Google Trends:
https://trends.google.com/trends/explore?q=round%20toward%20positive%20infinity,ceiling%20math,round%20positive%20infinity,towards%20positive%20infinity&hl=en

Far more people search for `ceiling` than `round toward positive infinity`
or `round positive infinity`. Of course, I may be wrong by choosing
incorrect search phrases, but it's also good to see some data/examples that
changing this in PHP is for the better.

> by *removing* the newly introduced constant and instead exposing the
functionality *only* via the new Enum.

It brings inconsistency that some modes are accessible by ints and enums
and others only by enums. If there is no deprecation plan yet I am not sure
this is the right approach.

Kind regards,
Jorg

Re: [PHP-DEV] [RFC] [discussion] Correctly name the rounding mode and make it an Enum

[Jorg Sowa]

Hey Saki,
I like this change. When I was implementing additional rounding modes for
the next PHP version I was initially struggling with the naming and this
change will be helpful.

I have only one concern about the names `NegativeInfinity` and
`PositiveInfinity`. They may be too formal from the user's perspective. As
we already have functions `ceil` and `floor` it's more intuitive for
developers to understand the logic of ceiling and floor rounding.

But if voters will prefer those terms then it makes sense to change the
constants implemented in PHP 8.4 (and thus not released yet) from
`PHP_ROUND_(CEILING|FLOOR)` to
`PHP_ROUND_(POSITIVE_INFINITY|NEGATIVE_INFINITY)` for the sake of
consistency.

Kind regards,
Jorg

Re: [PHP-DEV] [RFC] Transform exit() from a language construct into a standard function

[Jorg Sowa]

> I don't think there are any other "functions" like this.

What about list(), isset(), print(), echo(), require(), include(), unset(),
empty()? We use them the same way as functions, but those are not real
functions.

Kind regards,
Jorg

Re: [PHP-DEV] [RFC] [Discussion] #[\Deprecated] attribute again v1.3

[Jorg Sowa]

I like the proposition and I like the idea of $since parameter, however,
this option is too ambiguous about what should store. Should it store the
PHP version, package version, or the date?

What about setting this parameter vaguely as the boolean we can pass?

#[Attribute(Attribute::TARGET_METHOD | Attribute::TARGET_FUNCTION)]
class Deprecated
{
public function __construct(
public readonly ?string $note = null,
public readonly ?bool $since = null
) {
}
}

#[Deprecated(since: $packageVersion > 5.5)]
#[Deprecated(since: PHP_VERSION_ID > 80100)]
#[Deprecated(since: date("Y-m-d") > "2024-01-21")]

Kind regards,
Jorg

[PHP-DEV] Re: [RFC][Vote] Raising zero to the power of negative number

[Jorg Sowa]

Hi everyone,

The vote has been closed and accepted with 27 votes for yes, and 0 for no.

Thanks to everyone who participated in the vote and discussion.

Kind regards,
Jorg

Re: [PHP-DEV][DISCUSSION] Fix mb_trim inaccurate $character

[Jorg Sowa]

Hello Yuya,
I don't think modifying voted RFCs is allowed despite the size of the
change. Moreover, there are no dates of the voting included in the
description of the RFC so it's not clear for visitors when exactly the RFC
has been approved.

Kind regards,
Jorg

[PHP-DEV] [RFC][Vote] Raising zero to the power of negative number

[Jorg Sowa]

Hello everyone

I've just opened voting for the RFC Raising zero to the power of the
negative number
Link: https://wiki.php.net/rfc/raising_zero_to_power_of_negative_number

Voting started now, and will end on April 20 2024, 00:00 UTC.

Kind regards,
Jorg

Re: [PHP-DEV] [RFC][Discussion] Raising zero to the power of negative number

[Jorg Sowa]

Thank you Marc for your opinion. It makes sense to me that we should have
the possibility to mimic the IEEE-754 standard, thus we should have `fpow`
function as well. I have updated the RFC and would like to start the voting
if there are no new comments.

Kind regards,
Jorg Sowa

Re: [PHP-DEV] RFC Proposal : Allows calling non-static public methods through the __callStatic magic method instead of throwing an error.

[Jorg Sowa]

For the reference to the others: https://3v4l.org/UmPVo

Kind regards,
Jorg

Re: [PHP-DEV] RE: Testing new list server

[Jorg Sowa]

Hello Derick,
there is something wrong. I don't get all of the emails from the new setup,
only part. Examples of emails I didn't receive:
- https://externals.io/message/122391
- https://externals.io/message/122390
- https://externals.io/message/122388

I'm using Gmail and Spam doesn't contain any of them.

Kind regards,
Jorg

Re: [PHP-DEV] [RFC][Discussion] Raising zero to the power of negative number

[Jorg Sowa]

Hello everyone,
If there is no other feedback I would like to start voting in the next few
days.

Kind regards,
Jorg

Re: [PHP-DEV] [RFC][Vote] Promote the PHP Foundation

[Jorg Sowa]

Hello Jim,
shoudl this RFC be placed into the Policies repository as it was accepted?

https://github.com/php/policies

Kind regards,
Jorg

Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type

[Jorg Sowa]

> The only solution I can think of is to keep the deprecation in place
until PHP 10, but that's a very long time from now and the RFC says this
simplifies a decent amount of engine code, so I'm not wild about that idea.

Another solution is to have version 8.5. Also given the fact that much of
the deprecated code will be removed in PHP 9.0, maybe it's worth discussing
how long should be period between 9 and 10?

Kind regards,
Jorg Sowa

Re: [PHP-DEV] [RFC][Discussion] Raising zero to the power of negative number

[Jorg Sowa]

Thank you for the suggestions. I agree that error message should be more
meaningful. I changed it.

The main driver of this change is to match the division by zero behavior
for both operators which can operate on both integers and floats. Would it
make sense to create a function `fpow` similarly to `fdiv` for the correct
IEEE 754 logic?

Kind regards,
Jorg

[PHP-DEV] [RFC][Discussion] Raising zero to the power of negative number

[Jorg Sowa]

Hello everyone!

I want to start the discussion on the RFC: Raising zero to the power of
negative number

Link: https://wiki.php.net/rfc/raising_zero_to_power_of_negative_number

Kind regards,
Jorg

[PHP-DEV] Google Summer of Code 2024

[Jorg Sowa]

Hello all,
Google Summer of Code 2024 is open for organization applications until the
22nd of Jan. I found that PHP project took part in this program in 2008,
2009, and 2010.

Do you think it would be beneficial to attend again? It would encourage new
developers to contribute to the project and even if no idea is taken, we
would have a collection of ideas that could be an inspiration for
non-students.

Kind regards,
Jorg Sowa

Re: [PHP-DEV] [RFC] Collecting All Policies Into One Repository

[Jorg Sowa]

> It should contain the consolidated unified policy documentation that is
> "currently" active.

> The other option is what we currently have, and I am proposing to go
> away from. So the idea is that this repository is not a
> collection of the accepted policy *amendments* (or *replacements*),
> as that's what the RFCs / PRs are still for.

Thank you for the explanation. That's exactly what I was hoping for.

Kind regards,
Jorg

Re: [PHP-DEV] [RFC] Collecting All Policies Into One Repository

[Jorg Sowa]

Hey Derick,
Thank you for proposing this change. As a author of comment you mentioned I
believe this will help new maintainers to get all the information about the
RFC process from one place.

I have one question regarding the future changes. Do you see it would be
possible to make amendment to the accepted RFCs by the Pull Requests (and
formal RFC approach) making changes the existing policies or adding the new
policy replacing the old ones? In other words, this repository would server
as the collection of all ever accepted policies or it would contain the
unified policy documentation?

I'm asking because I saw the directory `archive`, and it contains expired
RFC. I don't think this would help new contributors. For the history
purposes it would be nice to have it in the git history, but for the PHP
development process is not relevant anymore and is little overhead.

Kind regards,
Jorg

Re: [PHP-DEV] [RFC] [VOTE] Add 4 new rounding modes to round() function

[Jorg Sowa]

I'm sorry for the confusion.

I followed the guide for the voting stating that the first voting is
primary, and rest are secondary, which don't require 2/3 votes on yes.
https://wiki.php.net/RFC/voting#voting

As this was my first RFC I was struggling a little bit, because the whole
description about RFCs are divided into several pages and in the template
there is not really an example for the primary and secondary voting. For
the new contributors some things are not entirely clear.

Maye we could improve the documentation of the process moving everything to
the Git? This could improve the transparency of the whole process and allow
for the clearer descriptions by the joint contribution?

Kind regards,
Jorg

Re: [PHP-DEV] [RFC] [VOTE] Add 4 new rounding modes to round() function

[Jorg Sowa]

Hello everyone,

The poll has been closed.

The RFC has been accepted with 19 votes yes and 0 votes no.

Creating aliases for Intl extension constants has been accepted with 10
votes yes and 6 votes no.

Thank you all for participating.

Kind regards,
Jorg

Re: [PHP-DEV] [VOTE] [RFC]

[Jorg Sowa]

Thank you for catching this. This is a mistake that I have just fixed. This
part states now:

> ROUND_TOWARD_ZERO (equivalent of PHP_ROUND_TOWARD_ZERO) alias of
ROUND_DOWN
>
ROUND_AWAY_FROM_ZERO (equivalent of PHP_ROUND_AWAY_FROM_ZERO) alias of
ROUND_UP


I have been caught myself by the vague terms of rounding up and rounding
down.

Kind regards,
Jorg

Re: [PHP-DEV] RFC Proposal - static modifier for classes

[Jorg Sowa]

Hi Lanre,
I like your idea and I was even thinking about proposing the same addition.

The thing that is missing in the description is how the static class should
handle magic methods. Should they be disabled for them?

One plus of static classes which exist in other languages are that we
wouldn't need the hack with private constructor to build Singleton. But...
that's not the recommended pattern to use as explained by Larry. So I am
not really sure whether it makes sense to add complexity to the PHP source
code for such small benefit. Or maybe you see other benefits?

I must also admit like others that your further arguments as below, are not
good as someone after your implementation will need to maintain this code.
> 1. I will personally implement this feature.
> 2. This change is non-breaking and backward compatible.
> 3. It is entirely opt-in. If you hold reservations about using static
classes, you can simply choose not to use them.

Kind regards,
Jorg

Re: [PHP-DEV] [RFC] [VOTE] Add 4 new rounding modes to round() function

[Jorg Sowa]

Thank you for your input Levi, this perspective wasn't mention before. I
agree with deprecation, that's why I removed this part from the RFC. I left
separate vote on creating aliases for the extension though, as from the
discussion this was not so certain and clear to everyone.

Kind regards,
Adam

[PHP-DEV] [RFC] [VOTE] Add 4 new rounding modes to round() function

[Jorg Sowa]

Hello internals!
I have just opened voting on the RFC to add 4 new rounding modes to round()
function.

Voting will end November 30th, 00:00 GMT.

Link:
https://wiki.php.net/rfc/new_rounding_modes_to_round_function

I'm sorry for previous message, but completely missed the title of the
message.

Kind regards,
Jorg

[PHP-DEV] [VOTE] [RFC]

[Jorg Sowa]

Hello internals!
I have just opened voting on the RFC to add 4 new rounding modes to round()
function.

Voting will end November 30th, 00:00 GMT.

Link:
https://wiki.php.net/rfc/new_rounding_modes_to_round_function

Kind regards,
Jorg

Re: [PHP-DEV] Re: [RFC] [Discussion] Add 4 new rounding modes to round() function

[Jorg Sowa]

Thank you for your comments. Listening to the opinions I will not include
deprecation of the constants and introducing the RoundingMode enum in this
RFC. Sorry for the delay. I will start eventually voting on the
RFC tomorrow.

Kind regards,
Jorg

Re: [PHP-DEV] Basic Type Alias

[Jorg Sowa]

I really like the idea and I would love to see it in PHP. I'm wondering
however, what would be the scope of the feature and how complex would be
designed type system. Examples I saw in this thread could be easily
replaced with union and intersection types (i.e. numeric as int|float). In
my opinion, there is a little benefit implementing in this shape making the
PHP core more complex.

The two use cases of user defined types in PHP which would benefit a lot
IMO, would be:
1. Typed arrays similar to Typescript.
2. Semantic types which would increase the security of systems. Example:
type UserId = int;

function setUserId_1(int $userId){}

function setUserId_2(UserId $userId){}

setUserId_1(5); // OK
setUserId_2(5); // TypeError

setUserId_1(UserId(5)); // OK
setUserId_2(UserId(5)); // OK

Kind regards,
Jorg

Re: [PHP-DEV] Two new functions array_first() and array_last()

[Jorg Sowa]

> Sure in many use cases undefined and null can be equivalent, but there
> are other use cases and considering the fact that php does not have a
> user level "undefined" value. It should at least attempt to not be
> ambiguous when possible. Instead of being ambiguous by default,
> requiring the user to do additional work to not be ambiguous.
>
> I do think the method is a great opportunity to avoid ambiguity,
> without a huge sacrifice on cost. As you said, throwing an exception
> would only further complicate things. Sure an empty check would get
> the job done, but again I believe it should not require such
> additional logic just to not be ambiguous.
>

Can we have ultimately a flag in the function for throwing an exception in
case of empty array?

Kind regards,
Jorg

Re: [PHP-DEV] Change default method of disabling JIT for PHP 8.4

[Jorg Sowa]

Hello Daniil,
I like this proposition. I never understood why the JIT is disabled by the
ini setting `buffer_size` rather than other simple 'switch' like setting.

Kind regards,
Jorg

Re: [PHP-DEV] Re: [RFC] [Discussion] Add 4 new rounding modes to round() function

[Jorg Sowa]

> I don't think deprecating the constants in the version where the aliases
are introduced is a good idea.

I removed the deprecation. You are right.

> I will also echo Tim's idea of using an enum instead and a union type.
> For the namespace, I think it would make sense to use Maths\RoundingMode

Doesn't Math/Maths namespace introduce BC break?

Kind regards,
Jorg

[PHP-DEV] Re: [RFC] [Discussion] Add 4 new rounding modes to round() function

[Jorg Sowa]

Thank you all for the discussion. I modified description of the RFC and
added deprecation of constants ROUND_UP and ROUND_DOWN from Intl extension
as an additional voting.

Thanks also for input about possible mode ROUND_STOCHASTIC, however I think
it's the idea for the extension and not the addition to the standard
functions.

I would like to start the voting in coming days.

Kind regards,
Jorg

Re: [PHP-DEV] [RFC] [Discussion] Adding bcround, bcfloor and bcceil to BCMath

[Jorg Sowa]

Hello,

Recently I was trying to fix and clean some of the stuff within the BCmath
extension along with Girgias who helped me. I wanted to enrich this
extension with similar functions that GMP contains and improve the
performance, however, I went to some conclusions and stopped it.

1. BCMath extension isn't fast enough compared to other existing arbitrary
precision PHP extensions. Comparison:
https://php-decimal.github.io/#performance
2. BCMath doesn't have OO API and thus it may break the backward
compatibility as Claude noticed.
3. GMP GNU library provides support for float numbers, however, its
functionality is not exposed in the PHP extension. And BCMath doesn't
provide as many functions as GMP.

And I understood that the BCMath extension should be abandoned eventually
when the GMP library is properly extended. There is no need for 2 arbitrary
precision extensions complementary to each other but for the rich one
having all of the functionalities.

I don't want to discourage you, because there is clearly a need for such
functions. Speaking from my perspective I would rather invest time into the
GMP extension than extend the BCMath extension.

If anyone also thought about this direction I could help and join forces to
have one proper math library in PHP.

Kind regards,
Jorg

Re: [PHP-DEV] [RFC] [Discussion] Add 4 new rounding modes to round() function

[Jorg Sowa]

Thank you all for the comments. The naming brought some constructive
discussion.

My preferred solution would be inconsistent PHP_ROUND_AWAY_FROM_ZERO and
PHP_ROUND_TOWARD_ZERO as those are friendlier to the most of developers and
are not possible to mistake with other modes. I would go even one step
further and create aliases for NumberFormatter constants to have the naming
consistent.

> Introducing a brand-new RoundingMode enum (using union types) I
> suggested in my first email would nicely solve the naming problem and
> would also make the API more obvious to use due to stronger typing in
> the long run.

That's also interesting idea and I would push it, however I'm afraid about
the naming of namespace. I recollect some of the RFCs were rejected simply
because of the namespace. If there is a guideline for the namespace of core
functions I would willingly get familiar to it. Otherwise, I don't want to
open Pandora box only because of the namespace of Enum. It would also bring
BC to the function, unless we would accept both enum and old constants.

Kind regards,
Jorg

[PHP-DEV] [RFC] [Discussion] Add 4 new rounding modes to round() function

[Jorg Sowa]

Hello everyone,

I would like to start the RFC process about adding 4 new rounding modes to
the round() function.

As the topic was previously discussed and the change is quite small, I
would like to start the voting on the beginning of next week.

RFC: https://wiki.php.net/rfc/new_rounding_modes_to_round_function

Thanks Niels for spotting incorrect links to the modes.

Kind regards,
Jorg

[PHP-DEV] Re: Introducing 2 new modes to round function

[Jorg Sowa]

Hello everyone,
As I am not sure what I should next I decided to follow the formal way and
I created the RFC for the change. I will start voting soon. Please let me
know if you have any suggestions.

RFC under discussion:
https://wiki.php.net/rfc/new_rounding_modes_to_round_function

Re: [PHP-DEV] Introducing 2 new modes to round function

[Jorg Sowa]

I had no idea about your PR Mark. It's pity to see that many improvements
(even simple) like this eventually was not implemented, despite the effort
authors put into.

I have created PR with the change. https://github.com/php/php-src/pull/12056

If you think I should proceed with RFC please let me know. Of course it
will not be merged into the PHP 8.3, but the next version.

Kind regards,
Jorg

Re: [PHP-DEV] Introducing 2 new modes to round function

[Jorg Sowa]

Thank you for your suggestions. I added two remaining modes and I think
it's complete now.

I changed the names to `PHP_ROUND_CEILING` and `PHP_ROUND_FLOOR` to be
consisted with rounding modes in number_format() function. I'm not sure
about `PHP_TOWARD_ZERO` and 'PHP_AWAY_FROM_ZERO` as in there it's
`ROUND_DOWN` and `ROUND_UP`, which I also find too vague.

However, I could find names UP and DOWN in other documentations. And sadly
it refers to away from zero and toward zero, so there is big mismatch in
existing naming.

https://developer.apple.com/documentation/foundation/numberformatter/roundingmode/down
https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/math/RoundingMode.html

Kind regards,
Jorg

[PHP-DEV] Introducing 2 new modes to round function

[Jorg Sowa]

Hello internals!

I would like to propose introducing two new modes to the function
`round()`: PHP_ROUND_DOWN and PHP_ROUND_UP.

Those modes are highly requested as you can see by the comments on round
documentation page. First comment mentioning about those modes has 309
votes as of today. Introducing those 2 modes would be complementing to the
rounding in this function.

Round documentation: https://www.php.net/manual/en/function.round.php
My implementation: https://github.com/php/php-src/pull/11741

I'm not sure if such minor improvement requires RFC, but as someone may
have some concerns I create this thread to get your feedback.

Kind regards,
Jorg

Re: [PHP-DEV] [VOTE] Interface Default Methods

[Jorg Sowa]

> So, here's a crazy thought: why do inheritance, interfaces, and traits
> need to be separate at all?
>
> At some level, they're all ways of composing a class with different
> restrictions, e.g. inheritance requires a single parent, interfaces must be
> abstract, traits don't interact with typing, etc. This RFC was an attempt
> to lift some (but not all) of these restrictions on interfaces; in that
> sense, it almost seems like too small of a step, and one which leaves the
> language in a confusing intermediate state.
>

I agree with this statement. Although I can't vote, I would be for this
feature. However, abstract classes would become orphans with the approval
and should be more clarification in the RFC what to do with them and the
whole inheritance design in the language, because this is significant
change.

[PHP-DEV] Re: RFC Karma Request: deprecation of ISO_8601 constants

[Jorg Sowa]

Hello again!

I didn't get any response and I'm not sure then whether I followed
everything correctly.

I want to write an RFC about deprecating the constants ISO_8601 and RFC7231
which I sent to the mailing list while ago for discussion. If I miss
anything I would be glad for assistance.

Kind regards,
Jorg

[PHP-DEV] RFC Karma Request: deprecation of ISO_8601 constants

[Jorg Sowa]

Hello,
I would like to request for RFC Karma.

I want to create RFC for deprecation of constants ISO_8601.

My wiki account is jorg_sowa.

Kind regards,
Jorg

Re: [PHP-DEV] Deprecation of the formats DATE_ISO8601 and DATE_RFC7231

[Jorg Sowa]

> In my opinion, since it isn't, and likely never was, a legal ISO8601
> string, it's a no-brainer that it should be deprecated. (it's at least
> been illegal since iso8601:2004 released in 2004)

I thought the same when I started the discussion. It's not good promotion
for PHP, when every mention about using proper ISO8601 format starts with
warning (use DATE_ATOM, not ISO_8601!). It doesn't need to be removed
straight in PHP 9. We can wait for next major version.

I just don't understand why keeping invalid concept in the language is
important for such simple structure like constant. I understand it's BC,
but it cannot be keep forever.

I would write RFC anyway to check the reception, but I need Karma to do it.
Could I ask someone for it?

Re: [PHP-DEV] Proposal: addition of array_find() and array_find_key() functions

[Jorg Sowa]

Hey,
Native implementation of the function array_find would decrease number of
lines needed to perform basic loops over the arrays from 4-6 lines to just
1. And I recollect a few times when the argument of reducing lines of code
needed to type was a valid reason of implementing the change.

Moreover, only this function would allow to achieve the same result as
proposed functions any()/all() by Tyson Andre 3 years ago. I still cannot
understand the context why the rejection reasons as "Too small in
scope/Object to the choice of namespace/Prefer the global namespace"
prevented PHP to have something which is a basically standard in other
languages.

https://wiki.php.net/rfc/any_all_on_iterable

Kind regards,
Jorg

Re: [PHP-DEV] RFC [Concept] - Interface Properties

[Jorg Sowa]

Hello,

I agree with David's statement:
> So yes anyay, my view is that between interfaces as we have them today,
> traits and abstract classes, there isn't a problem which needs to be
solved
> by now allowing properties on interfaces, but it would open up a
likelihood
> of encouraging things which are often regarded as anti-patterns.

It could be abused creatively. Interfaces define the behaviour of the
object, not the data the object should contain. That's why the properties
are implementation details. Liskov principle describes the behavioral
subtyping, not the state.

Although a few languages already support properties in interfaces (C#,
Java, Typescipt), so it's not rare case in other languages. However, I'm
not well oriented whether those communities have any problems with them.

My though about this topic. Wouldn't allowing abstract properties in
abstract classes resolve the issue of 'enormous amount of boilerplate code'
without touching interfaces, Zoltán?

Kind regards,
Jorg

Re: [PHP-DEV] RFC [Discussion]: mb_str_pad

[Jorg Sowa]

It's a reasonable approach. Thanks for clearing it up.

Kind regards,
Jorg

Re: [PHP-DEV] RFC [Discussion]: mb_str_pad

[Jorg Sowa]

Hello,
As this is a new function do you consider any namespace for it? Based on
passed RFC[1] allowing for namespaces in bundled extensions it would be
nice to introduce new functions with namespace. Maybe the namespace could
be voted in the RFC separately?

Kind regards,
Jorg

[1] https://wiki.php.net/rfc/namespaces_in_bundled_extensions

Re: [PHP-DEV] Deprecation of the formats DATE_ISO8601 and DATE_RFC7231

[Jorg Sowa]

> What do you mean? Do you mean that the constant was legal at some point?

Sorry, but I don't have this knowledge. It's invalid since 2004, but I
suppose this format was implemented before then. Undoubtedly the format is
invalid now.

The usage in 1000 most popular libraries:
DATE_ISO8601 (4 packages, 1 in comments)
DateTimeInterface::ISO8601 (18 packages)
DateTimeInterface::RFC7231 (1 package - Jetbrains/phpstorm-stubs)
DATE_RFC7231 (1 package - Jetbrains/phpstorm-stubs)

Most of the packages already inform about deprecation. PHP stubs by
Jetbrans warn about deprecation, although it's not officially.

Re: [PHP-DEV] Deprecation of the formats DATE_ISO8601 and DATE_RFC7231

[Jorg Sowa]

> How common is it in the wild?  I am pretty sure I've used it myself
without really thinking many times, which I suspect is common.  Knowing how
much code would be impacted would determine how we'd go about deprecating
it and on what timeline.

I'm not sure how would be possible to find out. I suppose most of the
frameworks (and thus popular PHP libraries) avoid this constant as showed
in Drupal and Carbon. The scanning of popular libraries will not show the
scale of the problem (however I will do it tomorrow) Helpful fact is that
those constants are just constants so it's easily replaceable with
strings 'Y-m-d\\TH:i:sO'
and 'D, d M Y H:i:s \\G\\M\\T'.

[PHP-DEV] Deprecation of the formats DATE_ISO8601 and DATE_RFC7231

[Jorg Sowa]

Hello everyone,

I would like to propose the deprecation of the constants DATE_ISO8601,
DateTimeInterface::ISO8601 and DateTimeInterface::RFC7231, DATE_RFC7231.

Arguments for deprecating DATE_ISO8601:
- outdated format, standard has been changed while ago
- incompatible with format ISO8601_EXPANDED
- misleading behavior for developers [1]

[2]

- doesn't support microseconds [3] 
- many misunderstandings in the userland [4]

[5] 

In my opinion the question is not whether this constant should be
deprecated, but when. I know that the problem was discussed in the past,
but I hope enough time has passed already to touch this topic again
although of the BC nature. [6] 
[7]


Arguments for deprecating DATE_RFC7231:
- error prone nature, the format never really supported timezone. I'm not
sure how it appeared in the code, but tests clearly lack cases for this
format. I'm not sure if it was missed on purpose, but with tests it would
be obvious that the format shouldn't ever appear in the core. [8]
 [9]


It's my first proposition in the PHP Core and I'm not sure if I should
suggest it through RFC or normal discussion like this. If I should propose
it in RFC then I can prepare it along with PR.

Kind regards,
Jorg

Re: [PHP-DEV] [RFC] Define proper semantics for range() function

[Jorg Sowa]

Thank you. That makes sense. I have last question about case with integer
and string digit, i.e. range('5', 10) or range('1', 9). What would be in
this case expected output? I couldn't find any test cases covering this
example.

Kind regards,
Jorg

On Tue, May 16, 2023 at 2:29 PM G. P. B.  wrote:

> On Mon, 15 May 2023 at 23:53, Jorg Sowa  wrote:
>
>> Hello!
>>
>> I have one concern about the part:
>>
>> > Emit an E_WARNING when $start or $end is cast to an integer because
>> the other boundary input is a number or numeric string. (e.g. range
>> <http://www.php.net/range>('5', 'z'); or range <http://www.php.net/range>
>> (5, 'z');)
>>
>> Doesn't it limit the functionality of the function for the numbers as
>> characters? Currently when we call range('/','z') we get full range of
>> characters. https://onlinephp.io/c/9cb12
>>
>> But when we change argument $start to next character which is zero ('0')
>> then we get array with only one element. https://onlinephp.io/c/a0cda
>>
>> Casting numerical string in this function may be confusing.
>>
>> Sorry for making fuss just before voting, but didn't see this topic
>> before and wanted to share my insights with you thinking it may be relevant.
>>
>
> No worries, this is the point of giving a heads-up.
> Someone else brought this to my attention again as well.
> And the concern makes sense, I've updated the implementation and RFC to
> adjust the behaviour with string digits:
> https://wiki.php.net/rfc/proper-range-semantics
>
> Please let me know if this addresses the issue and is also clear.
>
> Best regards,
>
> George P. Banyard
>
>
>
>

Re: [PHP-DEV] [RFC] Define proper semantics for range() function

[Jorg Sowa]

Hello!

I have one concern about the part:

> Emit an E_WARNING when $start or $end is cast to an integer because the
other boundary input is a number or numeric string. (e.g. range
('5', 'z'); or range (5,
'z');)

Doesn't it limit the functionality of the function for the numbers as
characters? Currently when we call range('/','z') we get full range of
characters. https://onlinephp.io/c/9cb12

But when we change argument $start to next character which is zero ('0')
then we get array with only one element. https://onlinephp.io/c/a0cda

Casting numerical string in this function may be confusing.

Sorry for making fuss just before voting, but didn't see this topic before
and wanted to share my insights with you thinking it may be relevant.

Kind regards,
Jorg

On Mon, May 15, 2023 at 4:42 PM G. P. B.  wrote:

> Hello Internals,
>
> I plan to put the RFC to a vote tomorrow in its current state, which has
> not been changed since the 30th of March:
> https://wiki.php.net/rfc/proper-range-semantics
>
> Any final comments or complaints should be raised now.
>
> Best regards,
>
> George P. Banyard
>