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

[Niels Dossche]

On 6/3/23 00:28, Jorg Sowa wrote:
> I would write RFC anyway to check the reception, but I need Karma to do it.
> Could I ask someone for it?
> 

You'll need to register on the wiki, and send an email to internals in which 
you say your wiki name.

Kind regards
Niels

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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] RFC [Discussion]: Marking overridden methods (#[\Override])

[Niels Dossche]

Hi Tim

On 5/11/23 18:37, Tim Düsterhus wrote:
> Hi
> 
> I'm now opening discussion for the RFC "Marking overridden methods 
> (#[\Override])":
> 
> 
> 
> RFC: Marking overridden methods (#[\Override])
> https://wiki.php.net/rfc/marking_overriden_methods
> 
> Proof of concept implementation is in:
> 
> https://github.com/php/php-src/pull/9836
> 
> 
> 
> Thanks to Ilija Tovilo for reviewing the implementation, providing additional 
> test cases and proof-reading the RFC text. Also thanks to my coworkers at 
> WoltLab for proof-reading the RFC text as well. Any remaining mistakes [1] 
> are my fault :-)
> 
> Best regards
> Tim Düsterhus
> 
> [1] For example the typo in the URL that I noticed too late.
> 

I support this RFC. Thank you for working on this.
The implementation also looks quite small and not intrusive in the engine.

I see some people sharing feelings that this perhaps belongs more into static 
analysis tools instead.
In my opinion, static analysis tools are used to catch mistakes the language 
can't protect you against (*).
In the case of this attribute, the language could very well protect the user so 
I think it makes sense to add it to the language.
Furthermore, implementing it in the language makes it universal.

(*) at least, without sacrifices

Kind regards
Niels

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Hans Henrik Bergan]

DATE_ISO8601 doesn't have to be removed anytime soon, but no new code
should be written using that constant, thus an E_DEPRECATED is
warranted.

Is anyone really arguing against that statement?

On Tue, 30 May 2023 at 18:26, Hans Henrik Bergan  wrote:
>
> >In my opinion, deprecating this does not do anything besides annoying
> users.
>
> 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)
>
> On Fri, 26 May 2023 at 12:17, Derick Rethans  wrote:
> >
> > On Fri, 19 May 2023, Jorg Sowa wrote:
> >
> > > I would like to propose the deprecation of the constants DATE_ISO8601,
> > > DateTimeInterface::ISO8601 and DateTimeInterface::RFC7231, DATE_RFC7231.
> >
> > …
> >
> > > 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]
> >
> > In my opinion, deprecating this does not do anything besides annoying
> > users.
> >
> > > 
> > > 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]
> > > 
> >
> > This should instead be fixed of being deprecated. It is a recent
> > addition after all.
> >
> > cheers,
> > Derick
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures

[Máté Kocsis]

Hi Claude,

The very risk is that the programmer must be aware that the return
> convention has changed. Recall that not everyone run static analysers,
> especially for such a trivial migration, and that not every code is
> statically analysable (e.g.. `$foo->$bar()`).
>

I hope that I don't sound elitist, but codebases not using static
analysis... are kind of hopeless... That is, in my opinion, there's no
other option
to run a larger PHP project successfully than to either use static analysis
or to have programmers who don't commit any mistakes. For the rest
of the less valuable projects, the cost of messing up with the return value
check is not much.

What is the purpose of changing the return convention of IntlCalendar
> methods, and is it worth?
>

The purpose is to have the "correct" return type. Is it worth it? Well, it
depends... For me, what's important is that PHP becomes a more and
more predictable and accessible language, and I care less about minimizing
backward compatibility breaks.

The introduction of the "true" type was useful, since we now have more
correct type information, but adding new functions with this return type
would be unfortunate, as many people (especially the ones coming from other
languages) would be puzzled about the meaning of
the "true" type more than if the return type was "void". I'm pretty sure
that George - the author of the true type - agrees that the main purpose
of this type is to eliminate its declarations from internal functions and
methods.

Regards,
Máté

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

[Pierre]

Le 02/06/2023 à 10:57, Janusz Szczypka a écrit :
You are right about speed penalty for using those functions over 
simple loops, however if we would stick to that point of view, we 
should deprecate and remove array_filter, array_map, array_walk, 
array_u...


I'm not sure they deserve deprecation, but I think that proposal may be 
the right time to talk about adding a real iterable API in PHP core for 
every one to use, a complete and consistent one, that would work on all 
traversable data structures, https://github.com/nikic/iter is perfect in 
my opinion for a good start, and would really deserve to be in SPL, and 
maintained along with core, and be usable without any composer dependencies.


PHP is really lacking a complete enumerable / iterable / traversable 
API. Maybe this is time to design and add one ?


--

Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Janusz Szczypka]

W dniu 2.06.2023 o 03:24, Hans Henrik Bergan pisze:

sounds like array_find could be implemented by just adding a new flag
for array_filter's $mode:
ARRAY_FILTER_STOP_ON_FIRST_MATCH
or some such?


array_filter is guaranteed to always return an array and we should not 
change it.

Flags are used just to decide what should be sent to a callback.

In my other e-mail I have just proposed adding similiar flags to 
array_find function as you have it now in array_filter, so it can be 
used to search by keys and/or values.


Best regards,
Janusz

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Janusz Szczypka]

W dniu 2.06.2023 o 02:14, Casper Langemeijer pisze:

On Thu, Jun 1, 2023, at 18:02, Janusz Szczypka wrote:

array_find(): This function would allow developers to find the first element in
an array that satisfies a specific condition. The condition would be defined by 
a callback function.

This would actually be an alternative to a simple foreach() with an if() and a 
break. As your example implementation makes clear.

array_find() and array_find_key() would still do the same internally, but add a 
function call adding the overhead of pushing parameters to stack, switching the 
scope, passing return value back switch scope and pop from the callstack again. 
If parameters or return value are typed this adds even more overhead.

I don't think there is any optimisation possible when this is done in C.

To the proposer it probably feels that this is an array function currently 
missing, but instead it's probably better not to have array_find() because 
people might actually use it for larger datasets.

Although I acknowledge that it will reduce the number of lines of PHP code it 
doesn't actually reduce the mental capacity to read and maintain code. I find 
the simple elemental building blocks of loops, conditionals and expressions 
easier and more expressive. In my experience this is especially so for less 
experienced developers.

Then there is a problem of naming. array_search() and array_find(). To a new 
developer, how would they know which is which?

Also there is the missing array_find_value_and_key() method. Because why should 
we be limited to either matching the key OR the value?


Hi,

You are right about speed penalty for using those functions over simple 
loops, however if we would stick to that point of view, we should 
deprecate and remove array_filter, array_map, array_walk, array_u...


Proposed functions are not intended for developers working on large 
arrays with speed constraints, but for simple usecases where (at least 
for some people) readability will be improved by reducing 6 lines of 
code to just 1.


"find" is consistent with names of the same function in other languages 
as Tim has pointed in his email yesterday.


I leally do not see many uses for array_find_value_and_key, however - as 
I you can see in my example implementations - condition is only checked 
for the values of the array. We could have a nice family of 
array_find_... functions including adding array_find_by_key and 
array_find_key_by_key, array_find_by_value_and_key and 
array_find_key_by_value_and_key... ;) or better discuss whether we 
should pass both key and value to callback like below (order of the 
arguments for the callback is to be discussed) or use flags like in 
array_filter to decide what do we want to pass


function array_find(callable $callback, array $array)
{
    foreach ($array as $key => $value) {
    if (call_user_func($callback, $value, $key) === true) {
    return $row;
    }
    }
    return null;
}

vs

function array_find(callable $callback, array $array, int $mode = 0)
{
...
}

Best regards,
Janusz

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC Karma

[Tim Düsterhus]

Hi

On 6/2/23 00:51, Nick Humphries wrote:

As per my earlier post discussing the concept of an RFC to add public 
properties to interfaces, I would like to request karma to create this RFC.


The folks handing out the RFC karma would need to know your Wiki 
username to do so.


Best regards
Tim Düsterhus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php