[PHP-DEV] Re: RFC: CachedIterable (rewindable, allows any key keys)

[tyson andre]

Hi internals,

> I've created a new RFC https://wiki.php.net/rfc/cachediterable adding 
> CachedIterable,
> which eagerly evaluates any iterable and contains an immutable copy of the 
> keys and values of the iterable it was constructed from
> 
> This has the proposed signature:
> 
> ```
> final class CachedIterable implements IteratorAggregate, Countable, 
> JsonSerializable
> {
>     public function __construct(iterable $iterator) {}
>     public function getIterator(): InternalIterator {}
>     public function count(): int {}
>     // [[$key1, $value1], [$key2, $value2]]
>     public static function fromPairs(array $pairs): CachedIterable {}
>     // [[$key1, $value1], [$key2, $value2]]
>     public function toPairs(): array{} 
>     public function __serialize(): array {}  // [$k1, $v1, $k2, $v2,...]
>     public function __unserialize(array $data): void {}
>  
>     // useful for converting iterables back to arrays for further processing
>     public function keys(): array {}  // [$k1, $k2, ...]
>     public function values(): array {}  // [$v1, $v2, ...]
>     // useful to efficiently get offsets at the middle/end of a long iterable
>     public function keyAt(int $offset): mixed {}
>     public function valueAt(int $offset): mixed {}
>  
>     // '[["key1","value1"],["key2","value2"]]' instead of '{...}'
>     public function jsonSerialize(): array {}
>     // dynamic properties are forbidden
> }
> ```
> 
> Currently, PHP does not provide a built-in way to store the state of an 
> arbitrary iterable for reuse later
> (when the iterable has arbitrary keys, or when keys might be repeated). It 
> would be useful to do so for many use cases, such as:
> 
> 1. Creating a rewindable copy of a non-rewindable Traversable 
> 2. Generating an IteratorAggregate from a class still implementing Iterator
> 3. In the future, providing internal or userland helpers such as 
> iterable_flip(iterable $input), iterable_take(iterable $input, int $limit),
>     iterable_chunk(iterable $input, int $chunk_size), iterable_reverse(), etc 
> (these are not part of the RFC)
> 4. Providing memory-efficient random access to both keys and values of 
> arbitrary key-value sequences 
> 
> Having this implemented as an internal class would also allow it to be much 
> more efficient than a userland solution
> (in terms of time to create, time to iterate over the result, and total 
> memory usage). See https://wiki.php.net/rfc/cachediterable#benchmarks
> 
> After some consideration, this is being created as a standalone RFC, and 
> going in the global namespace:
> 
> - Based on early feedback on 
> https://wiki.php.net/rfc/any_all_on_iterable#straw_poll (on the namespace 
> preferred in previous polls)
>   It seems like it's way too early for me to be proposing namespaces in any 
> RFCs for PHP adding to modules that already exist, when there is no consensus.
> 
>   An earlier attempt by others on creating a policy for namespaces in 
> general(https://wiki.php.net/rfc/php_namespace_policy#vote) also did not pass.
> 
>   Having even 40% of voters opposed to introducing a given namespace (in 
> pre-existing modules)
>   makes it an impractical choice when RFCs require a 2/3 majority to pass.
> - While some may argue that a different namespace might pass,
>   https://wiki.php.net/rfc/any_all_on_iterable_straw_poll_namespace#vote had 
> a sharp dropoff in feedback after the 3rd form.
>   I don't know how to interpret that - e.g. are unranked namespaces preferred 
> even less than the options that were ranked or just not seen as affecting the 
> final result.
> 
> Any other feedback unrelated to namespaces?

After feedback, I have decided to postpone the start of voting on this (or 
other proposals related to SPL or iterables) until April at the earliest,
to avoid interfering with the ongoing SPL naming policy discussions.

Thanks,
- Tyson

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

Re: [PHP-DEV] [RFC] mysqli bind in execute

[Craig Francis]

On Thu, 11 Feb 2021 at 7:43 pm, Kamil Tekiela  wrote:

> https://wiki.php.net/rfc/mysqli_bind_in_execute
>
> I'd be happy to hear your comments.




Please let this pass.

The current approach is absolutely horrible and causes so many developers
using mysqli to do things incorrectly (like trying to use escaping, which
is so easy to get make mistakes with).

Craig



On Thu, 11 Feb 2021 at 7:43 pm, Kamil Tekiela  wrote:

> Hi internals,
>
> I am proposing the next change to improve mysqli extension. This RFC's goal
> is to add a new optional parameter to mysqli_stmt:execute() that will take
> an array of parameters.
>
> The RFC is located at https://wiki.php.net/rfc/mysqli_bind_in_execute
>
> I'd be happy to hear your comments.
>
> Kind Regards,
> Kamil Tekiela
>

[PHP-DEV] [RFC] mysqli bind in execute

[Kamil Tekiela]

Hi internals,

I am proposing the next change to improve mysqli extension. This RFC's goal
is to add a new optional parameter to mysqli_stmt:execute() that will take
an array of parameters.

The RFC is located at https://wiki.php.net/rfc/mysqli_bind_in_execute

I'd be happy to hear your comments.

Kind Regards,
Kamil Tekiela

Re: [PHP-DEV] Re: Proposal: namespace the SPL

[Chase Peeler]

On Thu, Feb 11, 2021 at 1:08 PM Lynn  wrote:

>
>
> On Thu, Feb 11, 2021 at 6:55 PM Levi Morrison via internals <
> internals@lists.php.net> wrote:
>
>> I don't know the answer to that question. However, I don't think we
>> should add a deprecation on the very first version that we add the
>> aliases anyway. I think that would make for a bad upgrade experience
>> from 8.0 to 8.1. I would leave that more for 8.3, 8.4-ish in the
>> release cycle so there are at least a few versions for people to
>> organically change their code without triggering any notices of any
>> kind.
>>
>
> I would very much prefer this to be deprecated in the same version. This
> way you prevent the confusion of which of the two to use and have people
> implement the one we already know is going to be removed. Deprecations do
> not make it a bad upgrade experience at all. Quite the opposite in my
> opinion, they hint to me nice and early on which parts of the code base I
> have to adjust. The earlier the better.
>

I'm really ambivalent about when they are introduced, but I actually think
I agree with you. I know it's very much just a personal anecdote, but since
I don't turn deprecation notices on until I'm ready to actually look for
and fix them, I don't find them obtrusive at all.


-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] Proposal: namespace the SPL

[Rowan Tommins]

On 11/02/2021 16:39, Levi Morrison wrote:

  2. Any new types going into `ext/spl` use the `Spl` namespace. New
types added to `ext/spl` should be either related to data structures
or iterators, which is the bulk of what the SPL is.
  a. This rule is to help prevent the SPL from becoming the dumping
grounds for new types.



I think having this rule mentioned and agreed somewhere at least is a 
good idea.


We could perhaps in future look at moving those parts currently labelled 
as "spl" which *don't* fall into those categories somewhere else. It's 
weird that you can now _only_ use autoloading via a function prefixed 
"spl_", even though it's a language feature.


Regards,

--
Rowan Tommins
[IMSoP]

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

Re: [PHP-DEV] Re: Proposal: namespace the SPL

[Lynn]

On Thu, Feb 11, 2021 at 6:55 PM Levi Morrison via internals <
internals@lists.php.net> wrote:

> I don't know the answer to that question. However, I don't think we
> should add a deprecation on the very first version that we add the
> aliases anyway. I think that would make for a bad upgrade experience
> from 8.0 to 8.1. I would leave that more for 8.3, 8.4-ish in the
> release cycle so there are at least a few versions for people to
> organically change their code without triggering any notices of any
> kind.
>

I would very much prefer this to be deprecated in the same version. This
way you prevent the confusion of which of the two to use and have people
implement the one we already know is going to be removed. Deprecations do
not make it a bad upgrade experience at all. Quite the opposite in my
opinion, they hint to me nice and early on which parts of the code base I
have to adjust. The earlier the better.

Re: [PHP-DEV] Re: Proposal: namespace the SPL

[Levi Morrison via internals]

On Thu, Feb 11, 2021 at 10:48 AM Chase Peeler  wrote:
>
>
>
> On Thu, Feb 11, 2021 at 12:23 PM Levi Morrison via internals 
>  wrote:
>>
>> On Thu, Feb 11, 2021 at 9:57 AM Mark Randall  wrote:
>> >
>> > On 11/02/2021 16:39, Levi Morrison wrote:
>> > > Let me know what you think. I am hopeful this approach will work because:
>> > >   1. It is focused on a specific area which already has an established
>> > > "namespace", but in name-only (not technically).
>> > >   2. It does not try to solve the larger problem, which has a lot of
>> > > disagreement.
>> > >   3. I will be proposing new types for ext/spl soon (`ReverseIterator`
>> > > and an array iterator that is more efficient than `\ArrayIterator`),
>> > > and Tyson Andre has already proposed `CachedIterable` and company
>> > > which is in `ext/spl`, so this space has active development.
>> > >
>> > > Thank you for your time.
>> > >
>> >
>> > Do you want a dumping ground? Because this is how you create a dumping
>> > ground :-)
>> >
>> > If we're going to start putting things into namespaces (and we should)
>> > then we should absolutely avoid repeating the mistakes of the past by
>> > dumping completely unrelated things together.
>>
>> I agree, which is the point of accepting things in a narrow scope.
>> Data structures and iterators go hand-in-hand, as many iterator
>> implementations are directly connected to the internal implementation
>> details of the related data structure. There are other iterators, and
>> as long as they are general purpose they are fine too. These things
>> are related, not unrelated.
>>
>> > If SPL\ is to exist (and personally I think SPL is so cancerous, it
>> > shouldn't) then IMO it must absolutely be SPL\iterators.
>>
>> As mentioned in the previous point, iterators and data structures
>> belong together. It does not make sense to separate the implementation
>> of FixedArray and its iterator into two different namespaces; they are
>> one cohesive unit.
>>
>> Lastly, if we don't adopt a namespace soon, what will new names be? I
>> can guarantee it will be something like `SplReverseIterator`, not
>> `SplIteratorReverseIterator`. It won't be
>> `SplDatastructureCachedIterable`, it would be something like
>> `SplCachedIterable` (or `CachedIterable`, ugh).
>>
>> As you see, "Spl" _is_ the namespace. Any more or any less is
>> incongruent with what we have. This is why I am hopeful that
>> _specifically_ using "Spl" for these specific types can reach
>> agreement; all we are changing is `Spl$thing` to `Spl\$thing`.
>>
>
> I think Spl makes sense (there might be a debate over whether it should be 
> Spl or SPL though). How feasible is it to create generate a deprecation 
> notice when the global version is used? I assume the hope is to eventually 
> move away from using those, and I don't think that's a horrible BC break 
> given that users have enough time to prepare for it.

I don't know the answer to that question. However, I don't think we
should add a deprecation on the very first version that we add the
aliases anyway. I think that would make for a bad upgrade experience
from 8.0 to 8.1. I would leave that more for 8.3, 8.4-ish in the
release cycle so there are at least a few versions for people to
organically change their code without triggering any notices of any
kind.

>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: https://www.php.net/unsub.php
>>
>
>
> --
> Chase Peeler
> chasepee...@gmail.com

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

Re: [PHP-DEV] Re: Proposal: namespace the SPL

[Chase Peeler]

On Thu, Feb 11, 2021 at 12:23 PM Levi Morrison via internals <
internals@lists.php.net> wrote:

> On Thu, Feb 11, 2021 at 9:57 AM Mark Randall  wrote:
> >
> > On 11/02/2021 16:39, Levi Morrison wrote:
> > > Let me know what you think. I am hopeful this approach will work
> because:
> > >   1. It is focused on a specific area which already has an established
> > > "namespace", but in name-only (not technically).
> > >   2. It does not try to solve the larger problem, which has a lot of
> > > disagreement.
> > >   3. I will be proposing new types for ext/spl soon (`ReverseIterator`
> > > and an array iterator that is more efficient than `\ArrayIterator`),
> > > and Tyson Andre has already proposed `CachedIterable` and company
> > > which is in `ext/spl`, so this space has active development.
> > >
> > > Thank you for your time.
> > >
> >
> > Do you want a dumping ground? Because this is how you create a dumping
> > ground :-)
> >
> > If we're going to start putting things into namespaces (and we should)
> > then we should absolutely avoid repeating the mistakes of the past by
> > dumping completely unrelated things together.
>
> I agree, which is the point of accepting things in a narrow scope.
> Data structures and iterators go hand-in-hand, as many iterator
> implementations are directly connected to the internal implementation
> details of the related data structure. There are other iterators, and
> as long as they are general purpose they are fine too. These things
> are related, not unrelated.
>
> > If SPL\ is to exist (and personally I think SPL is so cancerous, it
> > shouldn't) then IMO it must absolutely be SPL\iterators.
>
> As mentioned in the previous point, iterators and data structures
> belong together. It does not make sense to separate the implementation
> of FixedArray and its iterator into two different namespaces; they are
> one cohesive unit.
>
> Lastly, if we don't adopt a namespace soon, what will new names be? I
> can guarantee it will be something like `SplReverseIterator`, not
> `SplIteratorReverseIterator`. It won't be
> `SplDatastructureCachedIterable`, it would be something like
> `SplCachedIterable` (or `CachedIterable`, ugh).
>
> As you see, "Spl" _is_ the namespace. Any more or any less is
> incongruent with what we have. This is why I am hopeful that
> _specifically_ using "Spl" for these specific types can reach
> agreement; all we are changing is `Spl$thing` to `Spl\$thing`.
>
>
I think Spl makes sense (there might be a debate over whether it should be
Spl or SPL though). How feasible is it to create generate a deprecation
notice when the global version is used? I assume the hope is to eventually
move away from using those, and I don't think that's a horrible BC break
given that users have enough time to prepare for it.


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

-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] Re: Proposal: namespace the SPL

[Levi Morrison via internals]

On Thu, Feb 11, 2021 at 9:57 AM Mark Randall  wrote:
>
> On 11/02/2021 16:39, Levi Morrison wrote:
> > Let me know what you think. I am hopeful this approach will work because:
> >   1. It is focused on a specific area which already has an established
> > "namespace", but in name-only (not technically).
> >   2. It does not try to solve the larger problem, which has a lot of
> > disagreement.
> >   3. I will be proposing new types for ext/spl soon (`ReverseIterator`
> > and an array iterator that is more efficient than `\ArrayIterator`),
> > and Tyson Andre has already proposed `CachedIterable` and company
> > which is in `ext/spl`, so this space has active development.
> >
> > Thank you for your time.
> >
>
> Do you want a dumping ground? Because this is how you create a dumping
> ground :-)
>
> If we're going to start putting things into namespaces (and we should)
> then we should absolutely avoid repeating the mistakes of the past by
> dumping completely unrelated things together.

I agree, which is the point of accepting things in a narrow scope.
Data structures and iterators go hand-in-hand, as many iterator
implementations are directly connected to the internal implementation
details of the related data structure. There are other iterators, and
as long as they are general purpose they are fine too. These things
are related, not unrelated.

> If SPL\ is to exist (and personally I think SPL is so cancerous, it
> shouldn't) then IMO it must absolutely be SPL\iterators.

As mentioned in the previous point, iterators and data structures
belong together. It does not make sense to separate the implementation
of FixedArray and its iterator into two different namespaces; they are
one cohesive unit.

Lastly, if we don't adopt a namespace soon, what will new names be? I
can guarantee it will be something like `SplReverseIterator`, not
`SplIteratorReverseIterator`. It won't be
`SplDatastructureCachedIterable`, it would be something like
`SplCachedIterable` (or `CachedIterable`, ugh).

As you see, "Spl" _is_ the namespace. Any more or any less is
incongruent with what we have. This is why I am hopeful that
_specifically_ using "Spl" for these specific types can reach
agreement; all we are changing is `Spl$thing` to `Spl\$thing`.

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

[PHP-DEV] Re: Proposal: namespace the SPL

[Mark Randall]

On 11/02/2021 16:39, Levi Morrison wrote:

Let me know what you think. I am hopeful this approach will work because:
  1. It is focused on a specific area which already has an established
"namespace", but in name-only (not technically).
  2. It does not try to solve the larger problem, which has a lot of
disagreement.
  3. I will be proposing new types for ext/spl soon (`ReverseIterator`
and an array iterator that is more efficient than `\ArrayIterator`),
and Tyson Andre has already proposed `CachedIterable` and company
which is in `ext/spl`, so this space has active development.

Thank you for your time.



Do you want a dumping ground? Because this is how you create a dumping 
ground :-)


If we're going to start putting things into namespaces (and we should) 
then we should absolutely avoid repeating the mistakes of the past by 
dumping completely unrelated things together.


If SPL\ is to exist (and personally I think SPL is so cancerous, it 
shouldn't) then IMO it must absolutely be SPL\iterators.


Without that all we've done is swap one problem for another.

The idea of putting data structures next to generic iterator helpers is, 
quite frankly, nuts.


Mark Randall

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

[PHP-DEV] Proposal: namespace the SPL

[Levi Morrison]

Hello, everyone,

There has been a lot of disagreement about namespacing, and people
seem to have different viewpoints. I am not sure how to reconcile this
broader discussion.

However, there are certain names in the global namespace which I am
hopeful we can revolve. For instance, `SplObserver`, `SplQueue`,
`SplFixedArray`, etc all follow the `Spl` prefix. There is already an
established "namespace" for these names.

So here is my limited proposal:
 1. We create names in the `Spl` namespace that are aliases to their
equivalent types with the `Spl` prefix:
`Spl\FixedArray` -> SplFixedArray
`Spl\Queue` -> SplQueue
 a. The new names are the aliases so any code which uses
`get_class($obj)` will not have the name change on them in a minor
release (8.1).
 b. We may switch the direction of this alias in 9.0.
 2. Any new types going into `ext/spl` use the `Spl` namespace. New
types added to `ext/spl` should be either related to data structures
or iterators, which is the bulk of what the SPL is.
 a. This rule is to help prevent the SPL from becoming the dumping
grounds for new types.
 3. We leave functions alone for now.

Let me know what you think. I am hopeful this approach will work because:
 1. It is focused on a specific area which already has an established
"namespace", but in name-only (not technically).
 2. It does not try to solve the larger problem, which has a lot of
disagreement.
 3. I will be proposing new types for ext/spl soon (`ReverseIterator`
and an array iterator that is more efficient than `\ArrayIterator`),
and Tyson Andre has already proposed `CachedIterable` and company
which is in `ext/spl`, so this space has active development.

Thank you for your time.

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

Re: [PHP-DEV] Requesting RFC karma for your wiki account.

[G. P. B.]

On Thu, 11 Feb 2021 at 02:03, Russell Stuart <
russell+lists.php@stuart.id.au> wrote:

> I'm created a branch to php-src that makes pdo_firebird::getColumnMeta()
> return "native_type" in addition to "pdo_type".  It also fixes a bug in
> the current getColumnMeta() (of the SIG_SEGV variety), and adds a unit
> test getColumnMeta() for it.  There is none currently.
>
> The branch is here:
>
>
> https://github.com/rstuart/php-src/tree/0044.1-add-pdo-firebird-getcolumnmeta.patch
>
> If I get RFC karma, I will create an RFC and a pull request for it.
>
> --
> Regards,
> Russell Stuart
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
I don't think this would need an RFC as the MySQL PDO driver went through
the same change.
Have you opened a PR against php/php-src?

Best regards,

George P. Banyard

Re: [PHP-DEV] [VOTE]: Change Default mysqli Error Mode

[Christian Schneider]

Am 11.02.2021 um 00:35 schrieb Kamil Tekiela :
> I have started voting on https://wiki.php.net/rfc/mysqli_default_errmode
> The voting period is 2020-02-11 -- 2020-02-28

For the record: I do not think the wording fo the "Backward Incompatible 
Changes" section is appropriate, especially the *only* in "To bring back the 
old behaviour one needs to add only this line before instantiating mysqli 
class". This IMHO downplays the impact for people hosting legacy code.

Also: If there would have been an intermediate PHP version with default 
MYSQLI_REPORT_ERROR I would have voted "Yes", but in the current form I have to 
say "No".

- Chris

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

[PHP-DEV] Re: Changes to finfo and imap functions

[Christoph M. Becker]

On 11.02.2021 at 05:57, Brent Roose wrote:

> The chagelog for PHP 8.1 lists the two following changes:
>
>
> - Fileinfo:
>   . The fileinfo functions now accept and return, respectively, finfo objects
> instead of resources.
>
> - IMAP:
>   . The IMAP functions now accept and return, respectively, IMAPConnection 
> objects
> instead of resources.
>
> I suppose these changes are part of the move away from "resources everywhere" 
> ? I was wondering whether these function will still accept resource objects 
> in PHP 8, or if support for them is completely removed.
>
> I tried searching externals.io  for a previous 
> discussion but could only find https://externals.io/message/111297#111298 
> 

Yes, these changes fall under the general resource to object conversion
(which is IMO generally a very good move), and the respective resources
are completely removed.  However, it seems that the incompatibility is
not only wrt. is_resource() checks, which can easily be resolved (and
may not be an issue for some code bases), but also regarding conversion
to int.  It might be sensible to implement cast_object handlers for
those classes, which may be deprecated.

The SSH2 extension would need particular attention in this regard, since
it deliberately uses resource to int/string conversion for its wrappers,
and even looks up the resources from the regular_list[1].

[1]


--
Christoph

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