Re: [PHP-DEV] RFC idea: using the void type to control maximum arity of user-defined functions

[Pierre]

Le 04/04/2024 à 23:38, Mark Trapp a écrit :

On Thu, Apr 4, 2024 at 2:16 PM Bilge  wrote:

On 04/04/2024 16:57, Tim Düsterhus wrote:

I think it would be reasonable to consider deprecating passing extra
arguments to a non-variadic function.

This seems like the only reasonable thing to do, to me. If this were the
case, there should be no need for any new syntax, since we could simply
deny passing extra arguments in the next major, no?

Bilge

I'd caution about being too hasty to deprecate and remove support for
this feature without understanding the underlying reasons why it has
been used historically, and without providing a better (not just
different) alternative for those use cases, lest an impossible upgrade
path is created.

While the variadic operator should be a 1:1 replacement for using
func_get_args(), is it enough of a benefit to force potentially tens
of thousands of codebases to change when they both accomplish the same
thing? What bad thing happens if PHP continues to support both
methods?

There is already enough friction to upgrade between major versions.
Introducing an optional attribute or syntax allows codebases that care
about signature strictness get that safety, while avoiding a
potentially costly and onerous upgrade for the community.

- Mark


I agree with both, ie. I think it's reasonable to deprecate extra 
variadic arguments, but also do it with caution: some old code, some 
templating systems for example may use implicit variadic arguments to 
pass values to templates.


There are tons of use case like this in old yet still running code.

But I would love it to be deprecated, raise warnings, and give some time 
for people to fix (adding an explicit `mixed ... $values` is enough to 
fix broken code).


Cheers,

--

Pierre

Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2

[Pierre]

Le 21/02/2024 à 19:55, Larry Garfield a écrit :

Hello again, fine Internalians.

After much on-again/off-again work, Ilija and I are back with a more polished 
property access hooks/interface properties RFC.  It’s 99% unchanged from last 
summer; the PR is now essentially complete and more robust, and we were able to 
squish the last remaining edge cases.

Baring any major changes, we plan to bring this to a vote in mid-March.

https://wiki.php.net/rfc/property-hooks

It’s long, but that’s because we’re handling every edge case we could think of. 
 Properties involve dealing with both references and inheritance, both of which 
have complex implications.  We believe we’ve identified the most logical 
handling for all cases, though.

Note the FAQ question at the end, which explains some design choices.

There’s one outstanding question, which is slightly painful to ask: Originally, 
this RFC was called “property accessors,” which is the terminology used by most 
languages.  During early development, when we had 4 accessors like Swift, we 
changed the name to “hooks” to better indicate that one was “hooking into” the 
property lifecycle.  However, later refinement brought it back down to 2 
operations, get and set.  That makes the “hooks” name less applicable, and 
inconsistent with what other languages call it.

However, changing it back at this point would be a non-small amount of grunt 
work. There would be no functional changes from doing so, but it’s lots of 
renaming things both in the PR and the RFC. We are willing to do so if the 
consensus is that it would be beneficial, but want to ask before putting in the 
effort.


Yes please ! Pass !

I don't have voting rights, but we need this.

Cheers,

Pierre R.

Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs

[Pierre Joye]

On Mon, Jan 1, 2024, 6:18 PM Rowan Tommins  wrote:

> On 31 December 2023 16:31:31 GMT, Pierre Joye 
> wrote:
>
> >php handles this in threadsafe mode
>
> Depending on your exact definition of "php", this is either irrelevant or
> just plain wrong.
>
> If you mean "the HTTP SAPIs shipped with official builds of PHP", then
> it's true, none handle multiple concurrent requests in a single thread
> using async I/O. But none handle multiple consecutive requests in a single
> thread using a "worker mode" either, which is the whole point of this
> conversation.
>


Unless I misunderstand the current proposal, it is about providing a core
interface to allow one to create its own SAPI similar to FrankenPHP, which
does not handle request in a singe thread but a thread pool handled by go's
coroutine.

I can imagine other developers implement it using other mechanisms (rust or
c++ f.e.) but the main interface from a php internal pov remains.

It is a first step and based on the usages/feedback, the next steps could
be the second part of your comment. Or?

best,
Pierre

>

Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs

[Pierre Joye]

hello,

On Sun, Dec 31, 2023, 6:59 PM Rowan Tommins  wrote:

Then one of us is missing something very fundamental. As I understand it,
> Swoole's model is similar to that popularised by node.js: a single thread
> processes multiple incoming requests concurrently, using asynchronous I/O.


The nodejs curse yes, where async and co may actually slow down your whole
node.

 DB result
> 09 Request A formats and returns response
> 10 Request A complete
> 11 Request B resumed
> 12 Request B fornats and returns response
>

php handles this in threadsafe mode, like modphp f.e. It is why frankenphp
requires a TS build of php. Requests are handled by a thread pool, not in
single thread event loop which may block all requests.

best,
Pierre

Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs

[Pierre Joye]

Hello,

On Tue, Dec 26, 2023, 1:56 AM Jordan LeDoux  wrote:

>
> So you want to introduce a SAPI that doesn't work with any of the existing
> HTTP solutions people use that only supports HTTP requests? Or am I
> misunderstanding something?
>
> This sounds a bit like you want to merge in a tool that is designed for
> your personal product directly into core. FrankenPHP may be incredible and
> awesome, but the world runs on Apache and Nginx for HTTP requests.



The world was running on cgi when php was created and a few years after.
Then the world was running on threads/apache. Then it ran in fcgi and
finally fcgi fpm for the last few years.

Other languages support this since quite some time. Projects like reactphp,
swoole and the likes provide userland versions of it and the benefits are
clear. They even worked together recently to get a common core. Many
(large) projects out there already support FrankenPHP, the needs are there.

FrankenPhp and a worker mode go beyond the classical php usages we had.
Desktop applications or IoT are getting more common (see laravel's
nativephp f.e.). I have done something similar for one of our products
using embedded sapi but how it is done using frankenphp would be an order
of magnitude better.

Having the complex parts in the core us a good start to experiment, adapt.
Later a core sapi may be added, we cannot know without trying and let the
community uses it.

best,
Pierre

Re: [PHP-DEV] New "PECL"

[Pierre Joye]

On Mon, Dec 11, 2023, 11:21 PM Larry Garfield 
wrote:

> On Mon, Dec 11, 2023, at 9:46 AM, Derick Rethans wrote:
>
> > Yeah, I understand. And I feel the same. But if there is no registry (a
> > goal), then there is no way to find out which of your extension version
> > support a specific PHP version, without checking every tag in your
> > repository. That's not going to be fast.
> >
> > cheers,
> > Derick
>
> See, I think I disagree on this point.  Having a registry is table-stakes
> for package managers these days.  Composer, npm/yarn, whatever Python does
> this week, Cargo, Bundle, Maven/Gradle... a packager isn't complete without
> a registry.  The one exception is Go, and its approach is... just a mess,
> frankly.
>
> Whether PECLtng piggybacks on Packagist, self-hosts using something like
> Satis, or does a home-grown thing, I don't think a neo-PECL without a
> registry is a viable and sustainable way forward.  That needs to be in the
> initial design.
>

hi Larry,

you are fully right here.

On top of the already mentioned points, it brings visibility to extension
packages, which is a key factor to adoption at large.

It also helps for an automatic builds.

A service is also a must for automatic releases/triggers builds. You can
see this service with a github tag hook on pickleweb.

It is also quite a good thing to automate dependencies management. It could
be relatively straightforward to update them per distros, or windows (see
my earlier post, already managed using windows. php.net data).

Also without the services (implemented but no public packagist for
extensions yet), I think pickle already does 95% of it (including local
windows builds). Adding signature is relatively simple.

Important note, during pickle development, the number 1 request was to be
fully integrated with composer. it was not possible until composer v2,
plugin and custom tags.  Given that composer is the only used package
manager , it should be the way to go. To create something from scratch
without taking these points into accounts can only lead to a sub optimal
solution.

There are also development environments tools out there which could provide
relatively easily per project extensions management (either cli or pools).

PHP is not my primary platform anymore, business wise, however I am happy
to help if desired.  I can only, with a diplomatic emphasis, suggest to the
author to understand where the php ecosystem is (or was 3 years or more
ago).


best,
Pierre

>

Re: [PHP-DEV] Filesystem path APIs

[Pierre Joye]

On Fri, Dec 8, 2023, 3:44 PM Max Semenik  wrote:

> On Wed, Dec 6, 2023 at 10:20 PM Niels Dossche 
> wrote:
>
> > Hi internals
> >
> > I'd like to start a pre-RFC discussion about filesystem path APIs in PHP.
> > The reason I bring this up is because of this recent feature request:
> > https://github.com/php/php-src/issues/11258
> >
> > The feature request is about the following:
> > We already have some functions to work with paths in PHP, e.g. basename,
> > dirname, realpath.
> > We do not have some common path APIs that you can find in other languages
> > like: path_join to join paths and path_normalize to normalize paths.
> >
>
> We have a lot of commonly used functionality that's successfully fulfilled
> by Composer packages - does this really have to be core functionality?
>

if any of them could be a easy win, relative path resolver without checking
its existence would be one. It is available internally but the existence
check option is not exposed.

>

Re: [PHP-DEV] New "PECL"

[Pierre Joye]

Hello Tim,

On Wed, Dec 6, 2023 at 9:05 AM Tim Starling  wrote:

> Have you considered keeping the support matrix in the registry
> database, instead of in pecl.json? Then it can be updated with new
> build/test information after release.

We do it for windows, used by pickle, you can see one part here:

https://windows.php.net/downloads/php-sdk/deps/dllmapping.json

The other parts being part of each extension.

It could be achieved similarly for linux package managers, maybe
maintained by them directly.

A few years back, I made some tests on windows and linux using
https://conan.io/ and https://vcpkg.io/, they both work on most
platforms PHP supports and also have cmake integration (php build
using cmake has been worked done, very nicely :).

Having maintained these parts for many years, dealt with 3rd parties
(developers of librairies, distro packages maintainers, etc) as well
as dealt with many end users (php developers), I must say I would
absolutely not start to define our own things but rely as much as
possible on the well working existing solutions.

On the same topic, npecl's requirements (why not a RFC/proposal btw?)
are kind of out of sync with what I have seen and still see. F.e.,
doing it outside the composer ecosystem will most likely create a
niche and not a wide adoption.There have been a lot of efforts put
into similar topics since 5.3 and a lot of learning, it may be a good
thing to learn from them. There are also tools now available to give
developers out of box tools to define whatever environments they may
need and switch between them within a click or command line (Laravel
community created a few good ones, mac for the biggest one, and other
platforms), having them rely on php's platform for the core and non
core extensions (including their respective deps) will be amazingly
helpful.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

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

Re: [PHP-DEV] New "PECL"

[Pierre Joye]

On Tue, Dec 5, 2023, 10:13 PM Pierre Joye  wrote:

>
>
> You may mention https://github.com/FriendsOfPHP/pickle
>
> which supports pecl.php.net pear format,  composer like support, and
> conversion to composer format.
>
> I did a website as well as a test bed and we had a long with the composer
> team what would be the best way to integrate it. That's something that
> became possible with composer 2.x, which now widely used. Similarly we
> discussed the idea to create a packagist dedicated to extensions.
>
> That would be, imo, the best option to date.
>
>
> The current code may need some updates for php8 but nothing difficult or
> requiring big changes.
>

there was also a draft rfc while we were thinking to propose to bundle it.
But we then decided to follow the composer's packagist philosophy instead.

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

>

Re: [PHP-DEV] New "PECL"

[Pierre Joye]

Hi Derick,

On Tue, Dec 5, 2023, 8:45 PM Derick Rethans  wrote:

> Hi there!
>
> Within the PHP Foundation, we have been talking for a while as what to
> do with PECL, and its website.
>
> The code is old, and hard to maintain. And the database is full of
> mojibake. It is also an outdated method of installing things, especially
> because userland code is so much easier to handle through Composer.
>
> Through the Sovereign Tech Fund (https://www.sovereigntechfund.de/) the
> Foundation has acquired some funding to improve this situation.
>
> Hence, to start of replacing PECL with something applicable for this
> decade, we started working on a requirements document:
>
>
> https://docs.google.com/document/d/1_N0E9xo3jn9aKrIZHIbTYaY5lXw71BpSO6-it4cRpDo
>
> In this first stage, we would like to invite you in commenting on the
> document (either inline, or here).
>
> Please keep in mind that this is a requirements document, and should not
> contain either design or implementation details. Once we have thought
> about these details as well, this will be turned into an RFC.



You may mention https://github.com/FriendsOfPHP/pickle

which supports pecl.php.net pear format,  composer like support, and
conversion to composer format.

I did a website as well as a test bed and we had a long with the composer
team what would be the best way to integrate it. That's something that
became possible with composer 2.x, which now widely used. Similarly we
discussed the idea to create a packagist dedicated to extensions.

That would be, imo, the best option to date.


The current code may need some updates for php8 but nothing difficult or
requiring big changes.


best,
Pierre

Re: [PHP-DEV] Make PHP JIT to generate AVX2/AVX3 for performance improvement?

[Pierre Joye]

On Tue, Oct 31, 2023, 3:57 PM tag Knife  wrote:

> > Hi  Guys,
> >
> > A quick question: is it possible to enable AVX2/AVX3 in PHP JIT generated
> > code, and hence can get some performance improvement?
> > Just check the community first: if anyone has already tried that or got
> > some experiences? before we dive into this investigation.
> > We are discussing if we could get some extra performance via new AVX
> > instructions in PHP program execution.
> >
> > Thanks.
> >
>
> AVX3 might be too new to just flat out generate for it. But
> It can be quite simple for the JIT compiler to be aware of what
> features flags are enabled on a CPU and generate compatible
> instructions that will run on that CPU.
>

it is not really new, however the gain for most cases are not necessarily
significant but for specific cases.

For most usages in php, at a request level, the gain will be barely
measurable.

Also for latest avx, most hosting servers won't have them anyway.

I would think some specific APIs to prepare specific data to be processed
using the best available runtime intrinsics would bring much more than in
JIT.

As a sidenote, most libraries used by php,  where larger intrinsics vectors
bring something, implement them already.


best,
Pierre

>

Re: [PHP-DEV] Constructor promoted property and default value

[Pierre]

Le 23/10/2023 à 18:11, Saki Takamachi a écrit :

If I understand your use case properly, you should be confused by properties 
with default values that are not constructor-promoted as well ? Am I wrong ? In 
this case, your problem is not with promoted properties ?

If we specify it the way you say, the initial values ​​of the constructor 
arguments will be available even when the constructor is not called.

Such behavior felt a little counterintuitive.


Which then would simply be the same behavior as properties when not 
promoted but declared in the class body instead:


```php

class Foo
{
    public $val = 'abc';
}

$redis_foo = serialize(new Foo());

$foo = unserialize($redis_foo);
var_dump($foo->val);
// string(3) "abc"

```

Right ?

What's the most disturbing in my opinion is that: `class Foo { public 
string $val = 'abc' }` and `class Foo { public function 
__construct(public string $val = 'abc' ) {}}` don't yield the same 
behavior at the time.


Regards,

--

Pierre

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

Re: [PHP-DEV] Constructor promoted property and default value

[Pierre]

Le 23/10/2023 à 17:35, Saki Takamachi a écrit :

Hi, Pierre

You may have overlooked the existence of the magic method `__unserialize()`. 
Constructor is not the only way to create instances.

When rebuilding a serialized object, you may need the initial values ​​of 
properties. This can easily happen if you are using rolling updates and using 
Redis. The constructor is not called if `__unserialize()` is called. In this 
case, defining the initial value of a property as an argument to a constructor 
that is never called confuses us.

Regards.

Saki


If I understand your use case properly, you should be confused by 
properties with default values that are not constructor-promoted as well 
? Am I wrong ? In this case, your problem is not with promoted properties ?


Regards,

--

Pierre

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

Re: [PHP-DEV] Constructor promoted property and default value

[Pierre]

Le 23/10/2023 à 17:16, Larry Garfield a écrit :

Where this becomes a problem is readonly properties, since those are not 
allowed to have default values.  (That would make them constants with worse 
performance.)  A solution would need to be able to detect that the 
parent::__construct() isn't called, and then call it anyway, or at least 
partially call it.  Unfortunately, I can think of many cases where such a call 
would result in unexpected behavior.

It might be possible to resolve, but it's definitely not simple, and it could 
easily lead to weird behavior.

--Larry Garfield


Thanks for the explanation !

I see, there is no easy answer, yet current state is, in my opinion, 
unintuitive for developers, and eventually unsatisfying when falling in 
this trap.


That's sad that readonly properties make this not trivial. Maybe some 
kind of object construct-post-hook could detect those case and affect 
variables with default values ? I don't know enough PHP internals to 
give a rational answer to this problem through...


Regards,

--

Pierre

[PHP-DEV] Constructor promoted property and default value

[Pierre]

Hello internals,

I stumbled upon this behavior, if I write this:

```php
class Foo
{
    public ?string $prop = null;

    public function __construct(?string $prop = null)
    {
    $this->prop = $prop;
    }
}

class Bar extends Foo
{
    public function __construct(
    public ?string $bar = null,
    ) {}
}

// Echoes nothing, but it works as expected.
echo (new Bar())->prop;
```

It works as intended, but if I replace the `Foo` class using:

```php
class Foo
{
    public function __construct(
    public ?string $prop = null,
    ) {}
}
```

It won't work anymore and I have the following error:

```
PHP Warning:  Uncaught Error: Typed property Foo::$prop must not be 
accessed before initialization in php shell code:9

```

If I understand it correctly:
 - in the first case, default value is attached to the object property, 
so if I omit its constructor, I have the default,
 - in the second case, default value is attached to the constructor 
parameter, and not to the object property, which means that in case the 
parent constructor is not called in the `Bar` class, `$prop` remains 
initialized.


It doesn't sound like a bug, but I think that many people would actually 
expect otherwise: that the constructor promoted property keep their 
default even when constructor is not explicitly called.


Is there any good reason behind this ? Wouldn't it be best to change 
this behavior ? Would it be a risk for backward compatibility (my guess 
is "not that much, probably not a all even") ?


Regards,

--
Pierre

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

Re: [PHP-DEV] Custom object equality

[Pierre]

Le 18/10/2023 à 22:22, Jordan LeDoux a écrit :


While I (obviously) appreciate the goal of the proposal here since I 
wrote the gigantic operator overload RFC the last time it was 
proposed, I do not support this idea here for one very simple reason: 
it is a clunky, work-around implementation to try and get the benefits 
of operator overloads without actually doing it.
Even if I don't really like operator overload, I would very much prefer 
the gigantic operator overload to pass than a band-aid patch with a new 
operator, I'm all in for consistency.


The need to control comparisons is real and obvious. So long as voters 
are categorically opposed to actual operator overloads no matter the 
implementation, as represented here by you Pierre but by no means a 
position that only you hold, I don't think we should be looking for 
ways to get the functionality through hacks like this. It may get 
passed in the short term and get PHP developers the equality 
comparison control that objects desperately need, but it makes all 
future improvements almost impossible to do.


Maybe I don't master english enough and I can speak to strictly 
sometime. If an operator overload RFC that doesn't have any blind spot 
or weird edge case happens, I'd be happy to see it pass, at least it 
would close bike shedding around this topic and life would continue happily.


I can't vote, but if I could, I wouldn't vote against a proper, robust, 
and easy to debug for developers operator overload RFC, I would simply 
abstain, because even if I personally don't like it, lots of people want 
it and I'm simply one among millions of PHP users, I don't want anyone 
to be frustrated.


The most important thing in my previous message I wanted to say was that 
the "~" symbol refers to something "approximate" in many contexts, in my 
opinion it's not the right choice for an equality operator. My opinion 
is either go for a full-on proper operator overload or simply don't.


Regards,

--

Pierre

Re: [PHP-DEV] Previous discussions about generics syntax only?

[Pierre]

Le 18/10/2023 à 17:37, Robert Landers a écrit :

That is all I want whenever I think of Generics in PHP. The rest is
just complicated fluff in my humble opinion.


Where I respectfully disagree is about exactly this: you would 
appreciate array, I would very much appreciate 
SomeDoctrineRepository so that my IDE would actually give me 
the right autocompletion.


There's also another use where it would get even better:

```

EntityManager::find(Query): T

class SomeQuery implements Query {}

// Later in code:

$someEntity = $entityManager->get(new SomeQuery())

assert($someEntity instanceof T); // Is now useless, my IDE simply knows.

```

There are many simple use case that can make our life easier, outside of 
simply array, lists, vectors etc...


Even if type erasure is done and there no runtime checks, it would 
greatly help when correctly done at the right place by userland APIs. 
ORM's are one place, but there are many others.


Regards,

--

Pierre

Re: [PHP-DEV] Custom object equality

[Pierre]

Le 18/10/2023 à 14:50, someniatko a écrit :

Hi internals,

This approach allows combining
- no BC break - `~=` is a new syntax which is unavailable in older PHP
versions
- explicitly showing an intent that objects are compared using a custom
comparison, rather than standard PHP one
- allow to skip writing boilerplate equals() methods which just forward
equals() to the nested objects
- standardize such comparisons on the language level

Of course how exactly this operator looks may be changed, `~=` is just an
example.

WDYT?


I'm not fond of operator overloading, I actually quite hate it, I like 
the expressiveness of an equals() method.


I would very much prefer to have a set of standard interfaces such as 
Comparable { compareTo($other): int } or Equatable { equals($other): 
bool; } which the standard API and userland libraries could make use of.


In all cases, I don't like the ~= choice because in my mind it literally 
translates to "is approximately/barely/maybe comparable to".


By the way, please  do not use abbreviations such as WDYT, I'm not a 
native english speaker and I don't know all abbreviations, I had to 
duckduckgo' it.


Regards,

--

Pierre

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

Re: [PHP-DEV] Previous discussions about generics syntax only?

[Pierre]

Le 18/10/2023 à 13:01, Alex Wells a écrit :

  The community has just now decided on the PHPDoc syntax for generics, has
just started widely adopting them in packages and has just got first-party
support from PHPStorm. I doubt that migrating to yet another temporary
solution (one that still doesn't address all of the concerns) is a good
idea right now.


Documentation is not code, and you could have syntax errors within 
without ever knowing it. Documentation is documentation and static 
analysis based upon documentation is fragile. All static analyzers may 
not even be in phase, when you contribute to projects you have to learn 
code style and conventions, but you also have to learn documenting style 
and conventions, and you must add the fact that from one project to 
another, generics documentation convention changes. Even thought you 
think it's "community decided convention", not all tools are in sync, 
sadly, and not all the community is OK with it.


I don't use PHPStorm, it's not the only IDE out there, or even people 
use simple editors sometime. Not all of them will have the same support 
level regarding "community decided convention". And even worse, most 
advanced IDE implementation may actually drive the "community decided 
convention" and steal the "democratic syntax vote" from the community, 
it's a very bad move where people that make money by selling their IDE 
may become the one driving the syntax and convention, and which will 
then en-prison their users in using their IDE, sometime the only 
supporting the convention they created themselves. OK, it's probably not 
that true, but at a very theoretical level, it's what it is.


When new syntax elements arise within a new PHP version, all editors, 
IDE, LSP backends will adopt it immediately, whereas it's definitely not 
true for "community decided convention". You have one, then two, then 
some static analysis tool or some IDE adds new subtle changes, new 
syntax, you never have, and will never have, at any point in time, a 
situation where all tools are in sync.


I do love the idea to have the syntax at PHP level with type erasure 
because it's not a "community decided convention" anymore, but a parser 
syntax that the engine supports which has been discussed and voted for, 
it is being validated, and exposed in reflection, which makes it 
resilient, solid, usable, and universal.


Having type erasure eliminates runtime checks, but it still can pose the 
basis for later real runtime checks. I like the idea even thought I'm 
not fully comfortable with regarding later feasibility, if the syntax is 
wrong and things cannot be implemented later in the engine, they the 
result would be catastrophic (everyone who have used it would have to 
fix all their code later when another solution would be chosen).


I'm aware this isn't an easy topic, and I have no solution for it. But 
"community decided convention" is not a solution either, it's at best, 
some kind of band-aid, and at worst, creating confusion because 
conventions differs from project to project, from tooling to tooling, 
and it's terrible for developers.


Regards,

--

Pierer

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

[Pierre]

Le 15/10/2023 à 18:09, Larry Garfield a écrit :

That has already been done:https://www.php.net/array_is_list

--Larry Garfield


Oh, I forgot it was accepted and merged, thanks for pointing at it.

Cheers,

Pierre

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

[Pierre]

Le 15/10/2023 à 01:11, Ben Ramsey a écrit :

On Oct 14, 2023, at 16:30, Nikita Popov  wrote:

On Sat, Oct 14, 2023, at 20:00, David Grudl wrote:

PHP lacks two very basic functions for working with arrays:

- array_first() returning the first element of an array (or null)
- array_last() returning the last element of the array (or null)

While PHP has functions that return the first and last keys,
array_key_first() and array_key_last(), it does not have more useful
functions for values.

a) What about reset() and end()?
Programmers "abuse" the reset() and end() functions for this purpose.
The problem is that these functions are used to move the internal
pointer in the array. Which is why they have a name that is
inappropriate when used in the sense of "return me the first element".

Much worse, they shouldn't to be used to get first/last value, because
they have a side effect (i.e. moving the pointer).

Further, in the absence of an element, they return the obsolete false
and not the currently expected null, which can be combined with the ??
operator. In this they differ from the similar functions
array_key_first() and array_key_last().

b) What about $array[array_key_first($array)]?

For such basic functions as returning the first and last item in an
array, there should be a function in the basic package, not a
workaround. Moreover, this requires having the array in a local
variable, since $this->getFoo()[array_key_first($this->getFoo())]
would be very inefficient and possibly incorrect.

c) Two such functions were proposed and rejected during the
array_key_first/last RFC
(https://wiki.php.net/rfc/array_key_first_last)

Yes, that was in 2018. At that time, functions like str_contains() or
str_starts_with() wouldn't have even come into existence, just because
there was an obscure way to do it without them. I believe we've moved
on since then. Today we know how useful it is to use simple,
easy-to-understand methods, both for programmers who write and read
the code.

DG

I'm in favor of adding these.

To add to what you already said, because reset/end modify the array, there's a 
good chance that calling these functions will copy the whole array due to a 
modification you are not actually interested in.

So basically you have the choice between calling end(), which is the wrong 
thing to do semantically and may be slow, or using 
$array[array_key_last($array)], which is rather convoluted, and incorrect if 
the array is potentially empty.

Regards,
Nikita

I’m in favor of these functions, for all the same aforementioned reasons.


Yes please !

array_first() and array_last() are definitely needed. I wrote `foreach 
($foo as $value) break;` too many times in my life. array_key_first() 
and array_key_last() I wouldn't use it much, but they'd probably  find 
their use cases as well.


The first two probably only make sense for a numerically indexed array, 
so I guess that array_is_list() (whatever the name is, I don't want to 
bikeshed about naming) would be a good addition as well, that, in my 
opinion, would be pertinent to add at the same time.


Regards,

Pierre

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

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

[Pierre Joye]

On Fri, Oct 13, 2023, 2:01 AM Jordan LeDoux  wrote:

>
>
>
> I believe MPFR is what is used by ext-decimal. The only thing that makes
> ext-decimal a somewhat difficult replacement for BCMath is that one of them
> uses precision and the other uses scale. (Total accurate digits versus
> total significant digits.) Fermat has implementations for both BCMath and
> ext-decimal, while also using GMP. It is much more difficult to control the
> number of accurate digits in ext-decimal than in BCMath, but ext-decimal is
> literally hundreds of times faster. I think, however, that Rudi (the author
> of ext-decimal) was against including ext-decimal in core.
>

it isn't really needed if not at the language level.

scaled basic operations can be (relatively) easily optimized, with an order
of magnitude faster than what bcmath does.

however, the real challenge, imho, is the different uses. That's where rock
solid implementation like mpfr could help, for non basic ops or modes.



> But if you want an alternate implementation for arbitrary precision
> decimals, it is certainly the place that someone should start.
>

for the few areas I needed it, I made my own with add/sub and mul/div with
intrinsics.  very little amount of codes and stable.

I am not completely sure how to cover the different usages, scaled
operations may be a good start and keeping bc math user land compatibility
may not too hard.

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

[Pierre Joye]

Hi Jordan

On Fri, Oct 13, 2023, 1:24 AM Jordan LeDoux  wrote:

>
>
> On Thu, Oct 5, 2023 at 5:27 AM Saki Takamachi  wrote:
>
>> Hi, Pierre
>>
>> In fact, I predict that many use cases will be covered by GMP.
>>
>> Still, I think that there may be cases where calculation functions like
>> mainframe BCD are required, such as when calculating money.
>>
>> I am unable to decide whether it is correct to deprecate BCMath and only
>> use GMP.
>>
>> I'd like to hear other people's opinions as well.
>>
>> Regards.
>>
>> Saki
>>
>
> GMP cannot be used in any reasonable way to implement things like sin() or
> cos(). It is *technically* possible, but not at all reasonable.
>

it is the reason I mentioned mpfr,
https://www.mpfr.org/mpfr-current/mpfr.html#Miscellaneous-Functions

the challenge I noticed in a couple of threads recently is the mixup of
radically different usages, like financial numbers with basic ops (+/-
eventually *//) and others.

they cannot use the same tools, most of the times. However there are libs
with different types or mode of operations, which could be a better fit
than what we do now.

It is not an easy research and priorities need to be clear.

BCMath is one of the worst and slowest implementations of arbitrary
> precision decimals.
>

what I was trying to express  :)


best ,

>

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

[Pierre Joye]

Hi

On Wed, Oct 4, 2023, 6:39 PM Saki Takamachi  wrote:

> Hi, Marc, Pierre
>
> Thank you for all the information.
>
> After all, I feel that BCMath and GMP have different roles.
>
> Arbitrary precision mathematics and very high precision mathematics are
> similar but distinctly different.
>

I replied about the FP specific question as it can be confusing. Adding
that gmp* may be a more sustainable solution as it is actively maintained
and widely used.

If PHP has already started integrating these things, then of course I'll
> follow suit, but if not, I'm against these integrations.
>
> If I missed something important, could you please let me know?
>

theoretically I agree, both may have different uses. Practically, and
within php ecosystem, they are used for the same purposes.


best,
Pierre

>

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

[Pierre Joye]

On Tue, Oct 3, 2023, 4:13 PM Saki Takamachi  wrote:

> yes, they do, as do almost all floating points implementation.
>
> Memory limited float values and their respective operations are still
> useful in many areas, but financial values and the likes. Scaled integers
> are the way for accuracy.
>
>
> Also, side note, gmp recommends to rely on https://www.mpfr.org/ for
> accurate FP operations
>
>
> Hi
>
> This seems to be a floating point number with extremely high precision
> compared to regular long doubles. However, as you say, even though the
> accuracy is very high, errors still occur. (the error is so small that it
> almost never becomes a problem.)
>
> By its very nature, BCMath does not introduce any errors. It is debatable
> whether floating point calculations in GMP can play the role of BCMath.
>

so does gmp. The point made about gmp earlier is more about the
sustainability of gmp vs bcmath.

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

[Pierre Joye]

On Tue, Oct 3, 2023, 12:25 PM Saki Takamachi  wrote:

>
> I thought GMP was a function for integers, so I wasn't expecting that tbh.
>
> However, even if GMP supported floating point numbers, wouldn't it end up
> having the inherent error problem of floating point numbers?
>

yes, they do, as do almost all floating points implementation.

Memory limited float values and their respective operations are still
useful in many areas, but financial values and the likes. Scaled integers
are the way for accuracy.


Also, side note, gmp recommends to rely on https://www.mpfr.org/ for
accurate FP operations


best,

>

[PHP-DEV] Re: Security Audit Priorities

[Pierre Joye]

Hello,

On Mon, Sep 25, 2023, 3:49 PM Derick Rethans  wrote:

> .
>
> Typical areas would be where user input can be (automatically read)
> remotely, such as
> our RFC 1867 HTTP header parser. But we are sure there are other
> important areas as well, and we would like your input.
>
> So, if you can suggest an area where doing an external review would have
> high impact, please reply to this email.
>

thanks for the feedback request :)

the sapi in general (and the underlying used APIs, like http headers you
mentioned) would be on top on my mind.

The embedded sapi may take more importance soon I think. It won't be as
wide as fpm but frankenphp (or similar) will see a significant increase in
usage, for good reasons:)

best,
Pierre

>

Re: [PHP-DEV] A new JIT engine for PHP-8.4/9

[Pierre Joye]

Hello :)

Posting again, I just realized I used "reply" not "reply all"

On Mon, Sep 11, 2023 at 4:29 PM Dmitry Stogov  wrote:
>
> Hi internals,
>
> I'm glad to present a new JIT engine that is going to be used in the next
> major PHP version. Now it's a real optimizing compiler with Intermediate
> Representation similar to Java HotSpot server compiler.
>
> It makes a base for future improvements and eliminates many low-level
> details of the existing PHP JIT. Instead of supporting assembler code for
> different CPUs, now PHP generates a single IR and passes it to a
> PHP-independent JIT engine.

Great work! This is a massive jump for PHP. Thank you :)

I don't have much concerns about the license etc as the ZE is already
under Zend the ZE license (never updated since Perforce acquired them,
tho'):

https://github.com/php/php-src/blob/master/Zend/LICENSE

I do really like the IR addition. This opens huge new opportunity, not
only for optimization and JIT but to move forward into bringing new
technology support to PHP (WASM f.e.). There are big challenges and I
am not sure yet it can be ever be fully possible to target WASM.
however, having the ability to do it with a subset of PHP, f.e. some
business logic classes etc., would already be amazing. I can't imagine
a php9 without taking this into account tbh. That would be kill php in
any way but that would definitively puts it in less competitive area
than others (JS, go, rust, ocaml f.e.), for another few years.

I have a simple php function working (just a small go app to parse the
IR text output and convert it. But that's not remotely a POC :). I
discussed with Dmitry and the idea would be to add a WASM target to
libIR (partial support or whatever is possible).

This is the part I would like to see more discussions or feedback as
it will define what could become possible or not. A certain level of
similarity or compatibility could make other targets much easier.

> The old JIT implementation is going to be kept for a while.

I like the idea too. The sooner this work can be available as
experimental, the sooner it will get stable.

Best,
-- 
Pierre

@pierrejoye

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

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

[Pierre]

Le 11/07/2023 à 17:16, Robert Landers a écrit :

On Tue, Jul 11, 2023 at 4:36 PM Larry Garfield  wrote:

You have to check your vendor folder for an interface, or trait, or abstract 
class.  That doesn't change anything.

As noted, now consider a Baz interface.  For interface-and-trait, you add 2 
more definitions.  For interface-with-defaults, you add 1.  For abstract 
classes, you need to add 4: BazBase, FooBazBase, BarBazBase, and FooBarBazBase.

I guess I don't understand what the interface is solving if you're
creating an interface _and_ a trait, why not just create the trait? It


What's solved here is that you simply don't have to create the trait 
anymore, in this specific use case, no more, no less. And I do like it.


You may not see the point for it, but as a recurrent user of the 
interface+trait from another package, it does bothers me a lot because 
it's never clear about the intent when you don't know the trait exists. 
Having the interface default methods makes it self-documenting and much 
clearer for the user.


There's nothing complex here, it's pure sugar candy, and much 
appreciated one by many I guess.



sounds like you're coupling your interface to a specific
implementation and trying to get multi-inheritance out of PHP. This
seems like a design issue, and this RFC seems like a back-way to
multiple inheritance. Why not just allow multiple inheritance?


Regarding the "back-way to multiple inheritance", it's true, and that's 
how lots of languages that were not design with multiple inheritance in 
mind solves it, such as Java, and I personally find this rather elegant.


--

Pierre

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

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

[Pierre]

Le 03/07/2023 à 13:32, Michał Marcin Brzuchalski a écrit :

I voted "yes", my personal use case waits for this feature. My use
case example:

https://gist.github.com/brzuchal/89e9481bbd34a6ce3d95a68eabff038b

With interface default methods I'd no longer need traits that implement a
single or in rare cases 2 methods that
use their respective methods returning objects and iterate in Generator
fashion over a paginated result set.
This is not an issue if there is one implementation of the interface but
when I decorate to apply some:
* caching
* logging
* failover

then the trait has to be attached to every class besides that it has to
exist which is an additional symbol here.

Cheers,
Michał Marcin Brzuchalski


Please everyone yes to this !

I use Symfony daily, and the SomethingAwareInterface / 
SomethingAwareTrait is very annoying, by having default method 
implementations on interfaces, it would remove the use of having traits 
at all. Everything would be much easier to read and write.


LoggerAwareInterface would no longer require us to use LoggerAwareTrait 
on every class, etc...


This is kind of sugar candy I'd really love.

Best regards,

--

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

[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] [RFC] path_join function

[Pierre du Plessis]

On Wed, 17 May 2023 at 18:24, Gunnard engebreth  wrote:

>
> > Maybe im missing something here but the already available `dirname()`
> does this. right?
> https://www.php.net/manual/en/function.dirname.php
>
>
dirname just traverses up the directory, it doesn't join paths.

For example, this example won't be possible with dirname:

path_join('/root', '/foo\\bar/baz', '../test', 'file.json'); // =>
/foo/bar/test/file.json

Re: [PHP-DEV] Future stability of PHP?

[Pierre Joye]

On Tue, Apr 11, 2023, 1:30 AM Deleu  wrote:

>
>
> I resent the sentiment of "if your code or development process was exactly
> like mine you wouldn't be here complaining" and I believe nobody is asking
> PHP to freeze. Not everyone has the ability to fix every deprecation within
> a couple of hours and not everyone has tests. Yes, we get it, it's common
> knowledge nowadays that code without test is unmanageable, but if you
> inherited a 15 year old codebase developed by multiple developers in a
> start-up mentality
>


This is wrong in so many levels Agility mindset, startup or not, does not
prevent to do the required cleanups.

These, by the way, are yearly,  worst case.

producing code faster than they could actually plan for and with no tests,
> its going to take some time to clean that up and if I take longer than you
> would, does it mean I matter less as a PHP user?
>
> PHP 8 is pretty great to work with and a lot better than previous
> versions, but there was no opt-in aspect to a lot of PHP breakages. All
> that we're asking here is for a bit more forgiveness to existing code that
> was developed 2 decades ago by a complete different generation and still
> need to run today while we clean it up.
>


Many things that will actually break codes (removal of features f.e.), have
been deprecated for years.

as it has been mentioned, many distributions provide longer support for
older php versions.

If you want the latest php version, you will have to prepare for it,
constantly and changing, cleaning your code constantly.  This is done as
part of the daily feature additions, no need to ask a PO or whoever else,
just add it to your estimates (if you still use them).

However, asking, as nicely as you did, the volunteers here to do it for you
as the language level, won't work.

best,
Pierre

>

Re: [PHP-DEV] Moving PHP internals to GitHub

[Pierre]

Le 12/04/2023 à 16:29, Rowan Tommins a écrit :


Reactions are a nice social media feature, but I don't think I've ever seen
them used to convey anything particularly meaningful.

If I write a comment that gets 3 smily faces, 4 angry faces, one rocket,
and one of those weird Japanese fireworks, all from people who haven't
otherwise participated in the conversation ... I'll just ignore them and
carry on.

It's certainly not a killer feature I'd uproot an entire community for.

Regards,


I sometime wish there was reactions thought. There's ton of message I 
read I'd only wish to say "I agree" without sending a complete email 
polluting the discussion for just this.


A simple up and down count would be great to visually assess how readers 
receipt the message. For long and complex discussions about some 
controversial RFC's this could have some kind of meaning.


It also could allow people to express they like an RFC independently of 
any technical consideration, this could at least give some kind of 
number of people interested in feature X or Y.


I'm not saying this list needs social network features, and I like it 
being as it is, but yes, for RFC, it sure lacks public opinion surveys, 
easy ones I mean, ones that anyone can stumble upon easily and say "I 
want it", "I don't want it" or "I don't care". There are millions of PHP 
developers, and nobody never reaches them to take temperature about how 
useful would be X or Y feature, and that's sad.


I guess some RFC's would probably move faster if the developer that 
tries to push it explicitly knows that hundreds or thousands of people 
are supporting it. It would also give sense to some hard and ingrate 
tasks, and some explicit gratitude, recognition for the work done, it 
could be very positive, and simply nice for the few PHP developers doing it.


That was my 2 cents about all this. Maybe what the thread creator mean 
is simply that the PHP development process is kind of hidden in this 
list, and it's not that easy to reach or read for people, even when 
using https://externals.io/


Best regards,

--

Pierre

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

Re: [PHP-DEV] Future stability of PHP?

[Pierre Joye]

hello,


On Sun, Apr 9, 2023, 1:37 AM Stephan Soller 
wrote:

> Hello,
>
> I'm sorry if this isn't the correct mailing list for that discussion but I
> couldn't find a more appropriate one where people actually know how the
> wind is
> blowing.
>
> A few days ago I migrated a project from PHP 7.1 to 8.2 and the amount of
> deprecations and fatal errors spooked me a bit (details below if you're
> interested). That got me wondering about the long-term stability of PHP
> (as in
> language and API breaks) and I looked at the RFCs. I got the impression
> that
> static typing has a lot of traction now and I have no idea of what the
> fallout
> might be of changing a dynamically typed language into a statically
> typed one.


I keep reading this in multiple languages, pr even more frameworks.

I understand agency work, managers pushing new features instead of a
cleaning some legacy.

however years of ignoring deprecation notices (very few were introduced
right before 8.0).

Most of them could have been fixed within a couple of hours in any code
base, if they had tests.

I would suggest, very very nicely, to review and rethink the development
flows of these projects instead of asking php to freeze.

best,
Pierre

Re: [PHP-DEV] Windows PECL build machine died

[Pierre Joye]

Hello,

I wonder if we could not use on demand resources for the builds (like
windows gh actions) and use the normal distribution mirrors setup?

Pierre

On Fri, Feb 17, 2023, 8:10 PM JEDI_BC / Bruno CHALOPIN 
wrote:

> Hi
>
> On 11/07/2022 18:25, Christoph M. Becker wrote:
> > On 11.07.2022 at 17:41, Hans Henrik Bergan wrote:
> >
> >> Do you mean it is unlikely that Github Actions will suffice? because
> that
> >> would definitely be a great solution if it was possible/feasible .
> >
> > No.  It is only unlikely that automated uploads to window.php.net will
> > ever be possible using GH actions.
> >
> >> Anyway, with regards to "I don't think there are special requirements
> >> regarding the hardware", can you give a rough estimate on RAM/disk space
> >> requirements?
> >
> > The old machine had something like 4 or 8 GB RAM, and a 128 GB hard disk.
>
> Is there recent development about the situation of the windows pecl
> build machine ?
>
> How can we help ?
>
> Regards,
>
> Bruno CHALOPIN
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Methods which auto-return the class instance

[Pierre Joye]

On Fri, Dec 23, 2022, 7:46 PM joke2k  wrote:

> Thanks for the feedback!
>
> On Fri, 23 Dec 2022, 09:33 Claude Pache,  wrote:
>
> > It is very common for fluent class methods to have a verbose `return
> > $this;` ending in their body.
> > But If you have declared `self` as return type into a non-static class
> > method you have only two options to return:
> >
> > - the $this object
> > - another instance of the same class or subclass
> >
> > ... in order to avoid a return type error.
> >
> >
> > It is still two options, and it is not clear in general which one to
> pick.
> > You could also say that, if you have `object` as return type, there are
> two
> > options to avoid a return type error: either return the `$this` object,
> or
> > return another object.
> >
>
> Yes but declaring `self` is more strict than `object`.
> And talking about the word itself... Declaring to return (your-)`self` but
> you could return someone-else of the same type as you.
> But it is ok, it refers to the class name not the instance. just semantic.
>

I would rather endure it returns the used instance and not another one with
a compatible interface. Not doing do is actually confusing to me, as per
the meaning of self. .

Or maybe, if the goal is to ease declaration of fluent interfaces (methods
chaining), declaring a class fluent (annotation?) would achieve the same
with ambiguous names?

>

Re: [PHP-DEV] Increase maximum size of an uploaded file to 50Mbyte

[Pierre]

Le 10/09/2022 à 11:31, Yasuo Ohgaki a écrit :

2022年9月7日(水) 22:58 Misha :
I can understand the motivation, but I am against the change.

To increase uploaded file max size, POST max size must be increased too.
For 99.99% entry points do not need 50MB POST max size.
and larger POST max size increases DoS risks.

Default upload file max size and POST max size should be small enough value
for better security.
IMHO, PHP script that handles large POST data should increase these
settings.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net


Hello,

Where I work we use a client side component that split files, send them 
chunked, handle progress, resuming etc... along with a server side PHP 
component. This method was originally developed for three reasons: allow 
huge file uploads (videos), give the user a progress bar, and more 
importantly, be able to bypass POST max size restrictions in production 
environments we cannot configure because they're managed by a remote 
external admin team.


My point is, I don't care about default limit remaining 2MB personally 
because we mostly work on products in which chunking files is the 
default. Anyway you also will have limit set at the HTTPd level as well 
if you want to be able to use it fully (in my original case the most 
limiting layer in the HTTP stack was Nginx at the time) having every 
layer in your stack working nicely together regarding POST size is not 
something you will always have in production environment that you don't 
fully manage yourself.


I think that raising the limit to something between 10MB and 20MB is 
something reasonable so that people like me in the future won't be 
forced to develop a client side file chunker for most use (phone photos, 
some PDF files, etc... most commonly), but raising higher may be a 
security issue. My phone takes 4k pics andthey site between 4MB and 
10MB, I think that the default limit doesn't have to be much more than 
this. As soon as you want to let your users upload bigger files, relying 
on a single HTTP POST seems dangerous for all of ergonomics, security 
and performance.


Regards,

--

Pierre

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

Re: [PHP-DEV] Typed constants revisited

[Pierre]

Le 24/03/2022 à 16:06, Mark Niebergall a écrit :

So you are correct, the const value does have a value that has a type, but
there is no way to enforce which type the value is or to use const with
inheritance, which is part of the bigger picture here.


That was exactly my point: the type could simply implicitely be the one 
of the original value.


Then the engine just has to use the existing covariance/contravariance 
rules for type checks based upon the guessed value type. This would fix 
the type safety issue you are referring to.


--

Regards

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

Re: [PHP-DEV] Typed constants revisited

[Pierre]

Le 23/03/2022 à 23:10, Larry Garfield a écrit :

Is there a benefit to it other than "well everything else has types now, so..."?  Even if 
it's esoteric, like in reflection-based meta programming?  (I've been dabbling too much in that 
lately. :-) )  "Everything else does" isn't a compelling argument for me, but there may 
be others I'm not thinking of.

--Larry Garfield


Hello,

Well I was thinking myself that const being well... constant, and so 
always defined, type could be determined at compile time without the 
need to express it in a verbose way.


PHP doesn't do any static type inference, but in this case, it could be 
done almost for free, am I wrong ? If it was determined at compile time, 
then the type checking on overrides would only be trivial, using the 
parent occurrence value inferred type. My point is that there's no need 
to express the type of a value, the value has already has a type.


Regards,

--

Pierre

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

Re: [PHP-DEV] Discussion: String streams

[Pierre]

Le 22/03/2022 à 16:14, Sara Golemon a écrit :

On Tue, Mar 22, 2022 at 5:38 AM Robert Landers 
wrote:


But why can't we have generic operator overloading in which case this could
be completely built by libraries in userland?


I mean... honestly, I feel like I come back around to this very quickly.
Generic overloading gives us much more at the end of the day and allows the
people using PHP day in and day out to make the actual decisions about what
any of these APIs should look like.

So while I said I wanted to avoid the firestorm suggesting userspace
overloading would bring, maybe that's the question to ask:

Who's just a hard-nope on userspace operator overloading?  If your reasons
go beyond foot-gun (and that is a valid reason), could you share what those
reasons are?

-Sara


Hello,

I am a not so hard-nope against userland operator overloading because 
it's magic. My day job is 20% writing code, 30% speaking with clients, 
and 50% reading and using community code. Userland operators are not as 
explicit as verbose method calls; and you can't ctrl-space an operator 
in any existing IDE, it's not obvious at what they does when you read 
code using them in most cases, and beyond that, in order to use them, 
you have to read an external documentation. Not that I don't read 
external documentation, but 80% of time, reading directly interfaces in 
my IDE is enough to know what to do with an API. When an API uses 
methods for doing stuff, code is auto-documented, when people start 
overriding operator, not so much (at least not as easy to find and 
understand at first sight) especially if the code is segregated behind 
interfaces and those interfaces don't explicit the operators (At least I 
hope that, if userland operators land, that interfaces will have a way 
to explicit the override).


And in the end, operators are just sugar for method calls. I don't 
dislike writing $c = $a->plus($b) instead of $c = $a + $b, I even found 
that there's some kind of elegance behind writing stuff explicitly. 
There's no feature in the world that would be blocked by the lack of 
operator overloading.


Moreover, the << >> c++ style stream operators are no more than a way to 
implement the string builder pattern, if I understand it well. Then why 
can't simply we use a StringBuilder class and use methods such as 
append(), prepend() and all ? It's much more explicit and much less 
alien-like for most people.


Regards,

--

Pierre

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

Re: [PHP-DEV] [RFC][Under discussion] Arbitrary string interpolation

[Pierre]

Le 18/03/2022 à 15:02, Chase Peeler a écrit :

On Fri, Mar 18, 2022 at 12:49 AM Theodore Brown 
wrote:


On Thu, Mar 17, 2022 at 5:40 PM Tobias Nyholm 
wrote:


On Thu, 17 Mar 2022, 23:27 Ilija Tovilo,  wrote:


Hi everyone

I'd like to start discussion on a new RFC for arbitrary string
interpolation.
https://wiki.php.net/rfc/arbitrary_string_interpolation

Let me know what you think.

That is a cool idea.
But I am not a big fan of having code in strings.
Wouldn’t this open the door to all kinds of new attacks?

Do you have an example of a new kind of attack this would allow?
The proposal doesn't enable interpolation of strings coming from
a database or user input - it only applies to string literals
directly in PHP code.

Personally I'm really looking forward to having this functionality.
Just a couple days ago I wanted to call a function in an interpolated
string, and it was really annoying to have to wrap the function in a
closure in order to use it.

If this RFC is accepted I'd be able to replace code like this:

 $name = "Theodore Brown";
 $strlen = fn(string $string): int => strlen($string);
 echo "{$name} has a length of {$strlen($name)}.";

with

 $name = "Theodore Brown";
 echo "{$name} has a length of {$:strlen($name)}.";



Out of curiosity, why not:
$name = "Theodore Brown";
echo "{$name} has a length of ".strlen($name).".";

or even
$name = "Theodore Brown";
$len = strlen($name);
echo "{$name} has a length of {$len}.";


I guess it's a matter of taste and convention.

Sometime, it make sense and it's just easier to just use string 
interpolation (for example with multiline templates).


Regards,

--

Pierre

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

Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression

[Pierre Joye]

On Sat, Mar 5, 2022, 10:31 AM Kris Craig  wrote:

> On Wed, Mar 2, 2022 at 4:51 AM Marco Pivetta  wrote:
>
>
> But that doesn't mean we should be using the PHP website to start taking
> sides in military conflicts.
>

There is no side to take but the population in Ukraine, friends, family,
colleagues as well as in Russians, the victims of a dictatorship' lies.

I don't see any issue to show our support for them, quite the opposite, I
do see an issue not to show it. A link to red cross and other ong
supporting refugees and civilians is not political, it is being a human.

It does not mean we take a political side. As much as there is not much to
discuss about that, but the deconstruction,  point by point, of every
single claim to justify this invasion, but php.net is not the place for
that.

best,

>

Re: [PHP-DEV] Setting to disable the "Undefined array index" warning

[Pierre]

Le 15/02/2022 à 13:46, Thomas Nunninger a écrit :

Hi Nicolas,

as far as I understand, adding new ini settings is not the way to go 
as this would mean that your code behaves differently on different 
environments.


Two suggestions:

* Write your own error handler that ignores those errors.

* Try some tool like Rector to rewrite your code.

Best regards
Thomas


Hello,

I do agree with Thomas here, changing PHP internal behavior by 
configuration is a dangerous thing to do.


If I understand correctly, there is "more than 130 000 lines of PHP 
code" to fix, believe me I migrated a few projects along the way from 
PHP 5.6 to 8.0 over time (one was about this size, but it stopped at PHP 
7.0 a few years back). They probably contain less "legacy code" since we 
have strict conventions from the beginning, but we did migrate some 
projects still.


Fact is, a legacy project cannot run without evolving if you want to 
support a recent PHP version. The language itself evolves, and that's 
for the best. Now for really legacy unmaintained projects, there's still 
the solution to keep them running on deprecated PHP version using some 
container technology. It's not ideal, but it can help until you finally 
find the necessary resources to port.


Using a good static analysis tool and possibly some other tools such as 
Rector, 130k lines is not an impossible goal.


I don't think there's an easy solution here, it's either don't upgrade, 
or either refactor, but modern tooling should help you a lot with that.


If it can help you, can can still replace your array access using `$a = 
$foo['bar'] ?? null` instead of `$a = \array_key_exists('bar', $foo) ? 
$foo['bar'] : null`, it's both easier to read and write (you just store 
` ?? null` in your clip board and hit paste on every use case you find).


Hope it helps,

Regards,

--

Pierre

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

Re: [PHP-DEV] Github issues

[Pierre Joye]

On Mon, Feb 14, 2022 at 1:02 PM Marco Pivetta  wrote:
>
> 1. You need to be part of https://github.com/orgs/php/people
> 2. Your group must have issue triage rights

Thanks Marco, I know what can be done in github, I do not know who I
have to ping here to get that done as I cannot add myself to the
organization. The organization was limited when gh was only a mirror,
so I wonder why all accounts did not get migrated.

-- 
Pierre

@pierrejoye | http://www.libgd.org

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

[PHP-DEV] Github issues

[Pierre Joye]

Hi,

What has to be done that the github issues can be handled by the same
developers than in bugs.php.net?

It is a bit weird that I cannot change status or anything else but add
comments :)


Best,
-- 
Pierre

@pierrejoye | http://www.libgd.org

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

Re: [PHP-DEV] Multibyte strings

[Pierre Joye]

good morning,

On Sat, Feb 12, 2022, 3:47 AM Rowan Tommins  wrote:

> On 11/02/2022 18:42, Michał wrote:
> > Considering the given example, the description from the documentation
> > of strlen function: "Returns the length of the given string".
>
>
> Which is exactly what it does. Using Unicode terminology [see
> https://unicode.org/glossary], here are a few different things you could
> count to determine the "length" of a string:
>
> a) bits
> b) bytes
> c) code units (UTF-16 has code units of 16 bits, UTF-8 has code units of
> 8 bits)
> d) code points (one of 1,112,064 numbers that can be given a meaning by
> the Unicode standard)
> e) graphemes (what a user would generally think of as a "character")
> f) pixels (or any other unit of physical size)
>

it is why we have intl, which uses the ICU and allow users to update it.
That means using the latest standard if needed.

best,
Pierre

>

Re: [PHP-DEV] RFC [Discussion]: Redacting parameters in back traces

[Pierre Joye]

Hi Tim,

On Tue, Jan 11, 2022 at 4:40 PM Tim Düsterhus, WoltLab GmbH
 wrote:
>
> Hi Pierre
>
> On 1/11/22 4:48 AM, Pierre Joye wrote:
> > Also sensitive data goes way beyond arguments, GDPR brings a lot of
> > issues here too. Userland packages like monolog provide filters or
> > custom output, I think that is where it should be handled.
>
> I believe that the author of a function is in the best position to
> decide whether a specific argument generally holds sensitive data or
> not. This avoids every exception handler / logger / … having to check
> what function parameters hold sensitive data and scrubbing them,
> possibly missing some.

You are fully correct here.

My thoughts differ as I think there are better tools to handle this
than PHP itself, as well as all other cases where sensitive data may
be exposed (a lot more than backtrace, which is handled already using
the ini setting).
Things like query errors, etc. There is no way we can handle them all
and this is really the developer responsibility to handle this data in
a safe manner. We do our best at the engine level for critical data
from an engine point of view. Application level critical data are the
developers responsibility (config, code, etc.).

Best,
-- 
Pierre

@pierrejoye | http://www.libgd.org

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

Re: [PHP-DEV] RFC [Discussion]: Redacting parameters in back traces

[Pierre Joye]

Good morning Tim,

On Mon, Jan 10, 2022 at 9:06 PM Tim Düsterhus, WoltLab GmbH
 wrote:

I am not sure it makes sense to make the code so verbose to prevent
users from showing sensitive data as it never stops (next
print_r/var_dump and userland version of them?).

Also sensitive data goes way beyond arguments, GDPR brings a lot of
issues here too. Userland packages like monolog provide filters or
custom output, I think that is where it should be handled.

As a side note, the RFC mentions that zend.exception_ignore_args may
not be configurable on some shared hosters, it is INI_ALL, so even in
the code could change it, any time, back and forth:

http://www.libgd.org

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

Re: [PHP-DEV] (Planned) Straw poll: Naming pattern for `*Deque`

[Pierre Joye]

Hi Tyson,

On Tue, Sep 21, 2021 at 9:19 AM tyson andre  wrote:
>
> While there is considerable division in whether or not members of internals 
> want to adopt namespaces,
> I hope that the final outcome of the poll will be accepted by members of 
> internals
> as what the representative of the majority of the members of internals
> (from diverse backgrounds such as contributors/leaders of userland 
> applications/frameworks/composer libraries written in PHP,
> documentation contributors, PECL authors, php-src maintainers, etc. (all of 
> which I expect are also end users of php))
> want to use as a naming choice in future datastructure additions to PHP.
> (and I hope there is a clear majority)
>
> -
>
> Are there any other suggestions to consider for namespaces to add to the 
> straw poll?
>
> Several suggestions that have been brought up in the past are forbidden by 
> the accepted policy RFC 
> (https://wiki.php.net/rfc/namespaces_in_bundled_extensions)
> and can't be used in an RFC.
>
> - `Spl\`, `Core\`, and `Standard\` are forbidden: "Because these extensions 
> combine a lot of unrelated or only tangentially related functionality, 
> symbols should not be namespaced under the `Core`, `Standard` or `Spl` 
> namespaces.
>   Instead, these extensions should be considered as a collection of different 
> components, and should be namespaced according to these."
> - More than one namespace component (`A\B\`) is forbidden
> - Namespace names should follow CamelCase.

Besides the namespace thing (collection is fine imho). What is the
reason to have it final?

For collection in general, would it make sense to have a common
interface representing the minimum expected API? If possible, then
algorithm specific on top? a bit like we have with the traversable
interface and related.

best,
-- 
Pierre

@pierrejoye | http://www.libgd.org

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

Re: [PHP-DEV] [VOTE] User Defined Operator Overloads

[Pierre Joye]

Hi Nikita,

On Tue, Jan 4, 2022 at 12:38 AM Nikita Popov  wrote:
>
> On Mon, Jan 3, 2022 at 1:14 AM Jordan LeDoux 
> wrote:
>
> > Hello internals,
> >
> > I've opened voting on
> > https://wiki.php.net/rfc/user_defined_operator_overloads. The voting will
> > close on 2022-01-17.
> >
> > To review past discussions on this RFC and the feature in general, please
> > refer to:
> >
> > - https://externals.io/message/116611 | Current RFC discussion
> > - https://externals.io/message/115764 | Initial RFC discussion
> > - https://externals.io/message/115648 | Pre-RFC discussion and
> > fact-finding
> >
> > Jordan
> >
>
> Voted No on this one. I did support the previous proposal on this topic,
> but I don't like the changes that this iteration has introduced relative to
> the previous proposal.
>
> The part that I dislike most (and that I consider an exclusion criterion
> regardless of any other merits of the proposal) is the introduction of a
> new "operator +" style syntax. I found the motivation for this choice given
> in the RFC rather weak -- it seems to be a very speculative
> forward-compatibility argument, and I'm not sure it holds water even if we
> accept the premise. There's nothing preventing us, from a technical
> point-of-view, from allowing the use of some keyword only with magic
> methods. On the other hand, the cost of this move is immediate: All tooling
> will have to deal with a new, special kind of method declaration.
>
> I'm also not a fan of the OperandPosition approach, though I could probably
> live with it. The previous approach using static methods seemed more
> natural to me, especially when it comes to operators that do not typically
> commute (e.g. subtraction).

I hesitated too, however I think we can't escape this feature. Like it
was for the annotation, we need to find a compromise.

Your points are valid so I wonder if the RFC could be modified and get
to the point we could reach that compromise. There will be the
oppositions for the features as a whole, however I am optimistic about
our abilities to get there this time rather than wait yet again a few
years for something we know we will have anyway.

Best.
-- 
Pierre

@pierrejoye | http://www.libgd.org

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

Re: [PHP-DEV] Surveying interest regarding CMake

[Pierre Joye]

On Tue, Jan 4, 2022, 2:17 AM Pierre Joye  wrote:

>
>
> On Tue, Jan 4, 2022, 1:35 AM Horváth V.  wrote:
>
>> On 2022. 01. 03. 18:17, Christoph M. Becker wrote:
>>  > Oh, that would be an issue.  We can't use Cygwin builds; MinGW builds
>>  > might be okayish, though.  ICU ships a VS solution file
>>  > (source/allinone/allinone.sln) which works fine.  I don't know
>>  > whether using that would be okay for Conan.
>>
>> No need to worry about that, it's just a way to coerce ICU's build
>> system into behaving well on Windows. Conan uses Msys2 as a build
>> environment for projects with *nix lock-in, which produces native
>> binaries without the cygwin shenanigans.
>>
>
> what does it mean exactly here?
>
> it uses msys for autoconf and co support but actually uses vc? or it
> relies on gcc and co?
>


rt*m :)

it can use whatever is needed and prioritization of cmd in the paths is
supported, neat  :)

https://docs.conan.io/en/latest/systems_cross_building/windows_subsystems.html

>

Re: [PHP-DEV] Surveying interest regarding CMake

[Pierre Joye]

On Tue, Jan 4, 2022, 1:35 AM Horváth V.  wrote:

> On 2022. 01. 03. 18:17, Christoph M. Becker wrote:
>  > Oh, that would be an issue.  We can't use Cygwin builds; MinGW builds
>  > might be okayish, though.  ICU ships a VS solution file
>  > (source/allinone/allinone.sln) which works fine.  I don't know
>  > whether using that would be okay for Conan.
>
> No need to worry about that, it's just a way to coerce ICU's build
> system into behaving well on Windows. Conan uses Msys2 as a build
> environment for projects with *nix lock-in, which produces native
> binaries without the cygwin shenanigans.
>

what does it mean exactly here?

it uses msys for autoconf and co support but actually uses vc? or it relies
on gcc and co?

Re: [PHP-DEV] [VOTE] User Defined Operator Overloads

[Pierre]

Le 03/01/2022 à 17:12, Larry Garfield a écrit :

Also, people keep talking about edge cases.  In my experience, "are these two 
objects equal" (for some object-specific definition of equal) is very much *not* an 
edge case.  I may have less use for overloading % as I don't use advanced math that much, 
but I compare things all the frickin' time and that would be incredibly useful day to day.


I forgot to answer to that, specifically. I'd much more prefer to have 
an explicit `equals(object $other): bool` (magic or not, really I do not 
care) single method for equality only, that'd be great. In that sense, I 
much preferred specific RFC about `__equalsTo()` or `__compareTo()` 
alone that a huge generic operator overload RFC. I think both could 
actually be separated, it wouldn't be that weird.


Best regards,

--

Pierre

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

Re: [PHP-DEV] [VOTE] User Defined Operator Overloads

[Pierre]

Le 03/01/2022 à 17:12, Larry Garfield a écrit :

On Mon, Jan 3, 2022, at 9:52 AM, Pierre wrote:


I personally tend to agree with everything that Marco said. Especially
regarding the fact that it's adding huge complexity to the language
itself for mostly edge cases.

I'd argue there's many much more valuable features that could be added
to PHP before operator overload, such as generics, rationalized
collection API and scalar objects with methods for example (which all
could be magnificent tools for improving the operator overload RFC).

Those are all independent of operator overloading.  There's zero reason one 
needs to come before/after any other.  Everyone wants generics, but they're 
really hard or Nikita would have implemented them already.  This is a 
non-argument.

Also, people keep talking about edge cases.  In my experience, "are these two 
objects equal" (for some object-specific definition of equal) is very much *not* an 
edge case.  I may have less use for overloading % as I don't use advanced math that much, 
but I compare things all the frickin' time and that would be incredibly useful day to day.


I think you read it too quickly. Anyway it was just examples, my point 
is not specifically about generics, but about the fact that operator 
overloading has been hugely controversial, and independently of the fact 
that I think this is a very well documented RFC, I still don't like it 
and express my opinion, I probably would not use those, but I eventually 
will be step debugging into some, and god, I don't wish I'll have to, 
really, I hate magic and non verbose code. Nevertheless, I have to 
admit, if I had the right to vote, I would abstain because it still a 
feature a lot of people want.


Best regards,

--

Pierre

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

Re: [PHP-DEV] [VOTE] User Defined Operator Overloads

[Pierre]

Le 03/01/2022 à 16:00, Marco Pivetta a écrit :
I'd probably use `$ts1->subtract($ts0)`, which doesn't seem to be that 
unreadable, and there is no need to abbreviate it to "diff" either.
Whether it needs to be static methods or instance methods depends on 
the wished API design.


What this RFC aims at is a mathematical language, inside another 
general purpose language: for complex expressions, I'd probably run it 
in a subsystem dedicated to this instead.


See for example:

 * https://en.wikipedia.org/wiki/Expression_(mathematics) (I'm 
literally just picking a complex example - don't even know how to read 
that properly)
 * and its textual representation in 
https://en.wikipedia.org/w/index.php?title=Expression_(mathematics)=edit=1 
<https://en.wikipedia.org/w/index.php?title=Expression_(mathematics)=edit=1>


```php
$expression = <<<'MATH'
f(a)+\sum_{k=1}^n\left.\frac{1}{k!}\frac{d^k}{dt^k}\right|_{t=0}f(u(t)) 
+ \int_0^1 \frac{(1-t)^n }{n!} \frac{d^{n+1}}{dt^{n+1}} f(u(t))\, dt.

MATH;

$result = $userlandExpressionEngine->evaluate(
    $expression,
    [
 // ... bind parameters here 
    ]
);
```

Heck, I can probably ask the `$userlandExpressionEngine` to render 
that monstrosity for me (see attachment).


Note that we do this stuff constantly for SQL, yet we haven't designed 
a system for embedding SQL into the language, and still, SQL is used 
many magnitudes more than all what was discussed in this RFC.


Yes, strings are problematic to some degree, but it's still better 
than increasing language complexity for a very edge case.


Alternatively, a better way to embed other languages can be used, 
which would be much more useful for things like Twig, Blade, PHPTal, 
SQL, etc: In haskell, this is done via Template Haskell, which many 
like, and many loathe, but is still useful for type-safe operations 
with a different language than the "main" one: 
https://wiki.haskell.org/A_practical_Template_Haskell_Tutorial#Shakespearean_Templates


In addition to all the above, I just noticed that the entire 
reflection API in the RFC requires major BC breaks in the reflection 
API... sigh.


Marco Pivetta


Hello,

I personally tend to agree with everything that Marco said. Especially 
regarding the fact that it's adding huge complexity to the language 
itself for mostly edge cases.


I'd argue there's many much more valuable features that could be added 
to PHP before operator overload, such as generics, rationalized 
collection API and scalar objects with methods for example (which all 
could be magnificent tools for improving the operator overload RFC).


I'm not against explicit method call, it's both readable and navigable, 
whereas operator overload tend to magically hide what the code really does.


Best regards,

--

Pierre

Re: [PHP-DEV] Surveying interest regarding CMake

[Pierre Joye]

good evening Horváth,

On Thu, Dec 30, 2021, 11:49 PM Horváth V.  wrote:

> Like I said in another e-mail, I wish to work on my host OS and this is
> something that would need to be done either way. It won't take me long
> either and PHP has been chugging along nicely so far without CMake.
>
> vcpkg has more dependencies missing than Conan and Conan has the
> advantage of providing pre-built binaries. For vcpkg, Open LDAP is
> missing, Cyrus SASL is missing, Bison is missing, Flex is missing, etc.
>

excellent,  Conan it is then  :)




> After New Year's, I will get to grinding out the dependencies that are
> missing in Conan and depending on how fast my PRs are accepted to CCI, I
> may be able to start working on PHP itself in February. Most of the time
> will be taken up by adjusting documentation, PHP provided tooling for
> extensions and gathering feedback from existing extension developers, so
> there is no reason to hurry.
>
> I think I will create a summary issue on the Conan Center Index
> repository with checkboxes to track my progress. Please look forward to
> that and consider subscribing to that issue if you are interested.
>


I will definitely follow it and see what can be done in pickle to support
it as well as the legacy build system.


thank you for pushing it forward, much needed  :)

best,
Pierre

Re: [PHP-DEV] Surveying interest regarding CMake

[Pierre Joye]

On Wed, Dec 29, 2021, 8:02 PM Christoph M. Becker  wrote:

> On 29.12.2021 at 13:38, Horváth V. wrote:
>
> > Just a quick update on this in between the holidays.
> >
> > There are indeed quite a few of the libraries provided in the php-src's
> > Windows SDK that are missing from Conan Center Index, which is the
> > default remote when fetching dependencies using Conan.
> >
> > I have submitted a recipe for WinEditLine and it is pending review by
> > the Conan team. I am basically done with OpenLDAP's recipe as well, but
> > it needs Cyrus SASL as a dependency, which does not build on Windows
> > using the CCI recipe yet.
> >
> > Ironically, many of PHP's dependencies use Autotools as their build
> > tool, which makes it practically impossible to build them cross
> > platform, so I have to rewrite things in terms of CMake :)
>
> Right!  This is why I suggested to postpone Windows support for now. :)
>
> The core dependencies for Windows builds are currently hosted at
> ; some can be built using
> .  Of course, it would
> preferable to be able to build all the libs with CMake, instead of the
> current mix of self made or provided Makefiles, Visual Studio solutions,
> and what not.
>

I would rather separate external libs challenges from the php cmake move.
CMake macros allow all kind of detection anyway, pkgconfig or custom.


 Conan looks good while I never tried it. There are other, *nix only, or
win and unix, ie vcpkg which has all php deps afair.

Also cmake is for php, I would prefer to move away from our custom builds
scripts for external libs on windows,  very hard to maintain and not
scalable.


best,

Re: [PHP-DEV] Drop support for libmysql with mysqli

[Pierre Joye]

On Sat, Dec 25, 2021, 10:29 PM Remi Collet  wrote:

> Le 24/12/2021 à 18:32, Kamil Tekiela a écrit :
> > Hi Internals,
> >
> > I would like to propose dropping support for libmysql from mysqli and ask
> > for opinions on how this could be best achieved.
>
> +1 to drop support for libmysql.
>

+1 too while the ones maintaining it may have something to say :)

P.S. one more point, IIRC License is not compatible
> with php one (GPL) despite there is a FOSS exception
> for Linux.
>

+libmysql, just in case :)

best,
Pierre

>

Re: [PHP-DEV] Re: PHP-FPM process management woes

[Pierre Joye]

On Thu, Dec 23, 2021 at 5:32 AM Christoph M. Becker  wrote:
>
> On 22.12.2021 at 22:44, Jakub Zelenka wrote:
>
> > After thinking about this a bit more I think we would still need some way
> > to provide the current functionality of the MINIT if that's moved on child
> > level. The problem with not having such step is that opcache shm would be
> > then segmented between children - each child process would have its own shm
> > so it means that it would likely break things like opcache_reset that would
> > work only for a single child but wouldn't have any impact on other
> > children.
>
> I think the children could still re-attach to OPcache (like on Windows),
> and that might not even be that bad as on Windows (where ASLR can break
> that).  However, forking late might break preloading (not sure), and
> generally re-attaching isn't the nicest solution.

I remember some similar issues a while back. I wonder if it could make
sense to separate these two flows.

The MINIT is critical to many extensions, not doing fancy things like
OpCache or similar. Would it be possible to split them? One actual
MINIT (as per doc, once per process) and one for more fancy stuff like
what is done in OpCache (or apcu afair)? I can't think of another way
to make the MINIT/SHUTDOWN API behave as it should while being
designed before fpm came to life. Or we let the ext developers handle
it themselves by providing some helpers function about the current
stage the ext is in (root process or childs) but that will be painful
to do and port.

Best,
-- 
Pierre

@pierrejoye | http://www.libgd.org

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

Re: [PHP-DEV] Surveying interest regarding CMake

[Pierre Joye]

On Tue, Dec 21, 2021, 5:24 AM Christoph M. Becker  wrote:

> On 20.12.2021 at 23:01, Horváth V. wrote:
>
> > On 2021. 12. 20. 17:19, Pierre Joye wrote:
> >
> >> We may switch to vcpkg distributions, [...], or the current autoconf
> >> php js port works too.
> >
> > Could you elaborate on what you mean by these?
> >
> > The reason why I prefer Conan here is because they provide pre-built
> > binaries for common setups, so that makes builds go faster for the
> > majority of the cases. I'm not against having a vcpkg manifest either
> > way, since that's just a simple JSON file at the root of the project,
> > but that will result in duplication and one more thing to maintain.
>
> I assume that Pierre was referring to the Windows dependency libraries.
>
> Anyhow, I suggest to defer the Windows support; it appears to be more
> important to have a CMake based build system working for other platforms
> first, and then we can still figure out how to make that useable on
> Windows, too.  In other words, eating the elephpant one bite at a time. :)
>


actually better to do it together or closely.

Cross compilation works, or miltiplarform too. But doing it late is a pain.

Also, I did not check which platforms are currently supported by cmake but
it was the main reason back then to stick to autotools.

And btw, vcpkg is only about dropping our own builds for all libraries
needed.  :)


best,
Pierre

>

Re: [PHP-DEV] Surveying interest regarding CMake

[Pierre Joye]

On Tue, Dec 21, 2021, 5:02 AM Horváth V.  wrote:

> On 2021. 12. 20. 17:19, Pierre Joye wrote:
> > We may switch to vcpkg distributions, [...], or the current autoconf
> > php js port works too.
>
> Could you elaborate on what you mean by these?
>
> The reason why I prefer Conan here is because they provide pre-built
> binaries for common setups, so that makes builds go faster for the
> majority of the cases. I'm not against having a vcpkg manifest either
> way, since that's just a simple JSON file at the root of the project,
> but that will result in duplication and one more thing to maintain.
>


I meant the current autoconf port (using js) on windows works perfectly
with vcpkg.

best,

Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)

[Pierre Joye]

On Tue, Dec 21, 2021, 6:37 AM Andreas Hennings  wrote:

>
> In a class Matrix, you might want to implement three variations of the
> * operator:
> - Matrix * Matrix = Matrix.
> - Matrix * float = Matrix.
> - Matrix * Vector = Vector.
> Same for other classes and operators:
> - Money / float = Money
> - Money / Money = float
> - Distance * Distance = Area
> - Distance * float = Distance
>

these are bad examples and nightmare to maintain. I think even more with
lovely typed languages. Matrix*float are better implemented as method here.

>

Re: [PHP-DEV] Surveying interest regarding CMake

[Pierre Joye]

On Fri, Dec 17, 2021, 10:23 PM Kalle Sommer Nielsen  wrote:

> Hi
>
> Den fre. 17. dec. 2021 kl. 01.09 skrev Horváth V. <
> friendlyan...@hotmail.com>:
> > Yes, gradually phasing the current build system out is the most
> > pragmatic choice, although it will incur some extra maintenance cost for
> > the time it's still in use, but it's better to do something sooner than
> > later. This will also allow php-src to drop the Windows SDK altogether
> > that was recently moved to the GH org, because Microsoft stopped
> > maintenance.
>
> I feel it is important to clarify something here. The Windows SDK is
> still supported by Microsoft. The Binary SDK for PHP by Microsoft
> which is the SDK that manages dependencies and provides cross MSVC
> environment build scripts is no longer supported.
>
> You can still build PHP on Windows without the Binary SDK but you will
> have to manage the build depedencies in all their flavors manually
> without this Binary SDK for PHP.
>

We may switch to vcpkg distributions, which supports cmake out of the box
as well, or the current autoconf php js port works too.

best,

>

Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)

[Pierre]

Le 16/12/2021 à 05:01, Jordan LeDoux a écrit :

This is not a use case I highlighted because it's one that would be
difficult to support with this RFC. But as you say, it could be a good
future expansion. In particular, putting a query builder object into core
with some more advanced overloads built in may be the best way to
accomplish this, particularly if it is built with the idea in mind that the
entities themselves may also have overloads.

I can certainly add it to the future scope of this RFC however.

--

RE: The operator keyword and operator implementations being non-callable.

This was a limitation that I purposely placed on the operator keyword, as I
didn't like the idea of allowing syntax of the style `$obj->{'+'}();` or
`$obj->$op();` and I wanted developers to clearly understand that they
shouldn't treat these as normal methods in the vast majority of
circumstances. However, it seems this is one of the largest sticking points
for those who would otherwise support the RFC. To that end, I'm considering
removing that restriction on the `operator` keyword. If I were to do that,
you'd no longer need to wrap the operator in a closure to call it, though
the parser would still have problems with `$obj->+(...);`

I suppose my question then would be, is this an acceptable compromise on
the operator keyword? It removes one of the more annoying hurdles that
Danack mentioned and that others have pointed out, but retains much of the
benefits of the keyword that I expressed in my last email.

Jordan


Hello,

I'm not an internals hacker nor someone who can vote, but here is my 
opinion about operator overloading: I don't like it. Nevertheless, if it 
has to be done, I'd like it to be less challenging for PHP newcomers or 
everyday developers.


An operator is not much more than a function shortcut, gmp examples 
prove that point quite well. I don't see why it is necessary to create a 
new syntax. It seems in the discussion that the magic method ship has 
sailed, but I'd much prefer it.


I don't see why a user wouldn't be able to call an operator 
method/function outside of the operator context. It has a signature: 
left operand and right operand are its parameters, and it has a return 
type. The engine internally will just call this function as userland 
code could do.


I think that adding a new syntax for it, and allowing weird function 
names which are the operator symbols will probably create some mind fuck 
in people's mind when reading the code. I like things being simple, and 
I'd love operator overloads to be simple functions, no more no less, not 
"a new thing". The more PHP syntax grows the more complex it is to learn 
and read.


Regarding the naming debate about operator names being different 
depending upon the context, I agree, but I don't care, if operators have 
a name in the engine, I'd prefer methods to carry the same name even if 
it yields a different name in the domain semantics of the object: if you 
are the low level operator function developer, you know what you are 
doing furthermore you can still comment code. If you're the end user, 
you will read the domain API documentation, not the code itself in many 
cases.


If the names are a problem, why not registering those using an attribute 
? If I remember well it was mentioned somewhere in the mail thread, it 
would provide a way to explicitly register any method, with any name, as 
being an operator implementation, sus userland could keep both syntax 
and use the one they wish (i.e. $newNumber = $number->add($otherNumber); 
or $newNumber = $number + $otherNumber. It's not insane to keep this 
possibility open, on the contrary, it'd leverage the fact that operator 
overloading in some context is just a shiny eye candy way of writing 
some domain function shortcut.


That's my opinion and I don't if it worth a penny, but in my mind, an 
operator is a function, and there's no reason that it'd be a different 
thing.


Regards,

--

Pierre

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

Re: [PHP-DEV] Re: Finishing AVIF support in getimagesize()

[Pierre Joye]

Good evening,

On Wed, Dec 8, 2021, 6:40 PM Christoph M. Becker  wrote:

> On 01.12.2021 at 00:52, Ben Morss via internals wrote:
>
> l
>
> Thanks for your and your colleague's work!  It's highly appreciated.
>
> Anyhow, a respective PR[1] has been submitted now, and I'm in favor of
> bundling libavifinfo.  I'm not too concerned regarding the additional
> size of the PHP binaries which would result by linking it in, but if
> others are, we could still introduce a configuration option (e.g.
> `--with-libavifinfo`).
>
> Thoughts?  Objections to bundling libavifinfo at all?
>
> [1] <https://github.com/php/php-src/pull/7711>
>

On a general principle, I understood that bundling libs should be avoided.

I am not totally sure aviinfo is stable enough to be bundle either way.

The format will  be widely used in a near future so i would rather allow it
if libavinfo js available rather than  bundling it.

best,
Pierre

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

Re: [PHP-DEV] Allowing NULL for some internal functions

[Pierre Joye]

On Thu, Dec 2, 2021, 10:20 PM Sara Golemon  wrote:

I'm not hard against this idea.  The interpretation of null in these
> contexts as being equivalent to empty string isn't unreasonable.  I guess
> the only objection I could have would be an academic one and I can't really
> defend that.  So yeah, sure... why not?
>
> I would say that such applications should consider unifying their own
> types.  $a = $_GET['q'] ?? '';   Is there a place in the application where
> empty string and null would have been distinct? i.e. Is a search for
> nothing different from not searching?
>


I wonder what is the technical benefit from that?

I do feel we are moving to a strict typed language. If that is what is
desired, then let decide it clearly and move forward to rhst direction.

best,
Pierre

>

Re: [PHP-DEV] Fork microsoft/php-sdk-binary-tools to PHP org on GH

[Pierre Joye]

Hi Christoph,

On Wed, Dec 1, 2021, 5:48 PM Christoph M. Becker  wrote:

> Hi all,
>
> since Microsoft won't support PHP 8 and beyond, it appears to be
> reasonable to fork the microsoft/php-sdk-binary-tools[1] to the PHP org
> account on Github.  The PHP-SDK is required to build PHP on Windows[2],
> and at least some adaptions to newer PHP versions need to be done[3],
> and there is a PR for building for arm64[4], which may be rejected by
> Microsoft.
>
> Thoughts?  Objections?
>

yes please.

And get ride of the CLA while being  at it.


best,
Pierre

>

Re: [PHP-DEV] Need Update regarding PHP Travis CI Execution

[Pierre Joye]

Hi Nikita,

On Thu, Nov 25, 2021 at 3:47 PM Nikita Popov  wrote:

> Travis is working again.

In the meantime, I asked AWS if it is ok to share GD's graviton box
with php, all good.

If we don't have one, happy to add you there. GH Actions already in
place, only need to set up two accounts (I never did but should be
smooth :).

best,
-- 
Pierre

@pierrejoye | http://www.libgd.org

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

Re: [PHP-DEV] Need Update regarding PHP Travis CI Execution

[Pierre Joye]

Hi Nikita,

On Wed, Nov 24, 2021, 6:55 PM Nikita Popov  wrote:

> On Wed, Nov 24, 2021 at 12:42 PM Chandranana Naik <
> chandranana.n...@ibm.com>
> wrote:
>
> >
> > Hi Team,
> >
> > Recently Travis builds have stopped running for PHP.
> > We only see Cirrus and appveyor CI builds,  however travis.yml exists in
> > the github repo.
> >
> > Could you please update if Travis builds will be started again or if
> there
> > are plans to disable Travis CI support ?
> >
>
> Hi,
>
> I've sent a support request to Travis to extend us additional open-source
> credits, so hopefully this will be running again soon.
>
> Generally though, I would recommend you to migrate from Travis CI to GitHub
> Actions. The PHP project itself uses Travis CI for testing non-x86
> platforms only, which are generally not available on other CI providers.


what we did for GD. Also adding arm is simple as the gh ci bot works on arm.

For ppc and other there is a gh bot port typescript and this is the one we
use. Only need to install it instead of gh one, gh website parts remain the
same.

Best,
Pierre

Re: [PHP-DEV] PHP 8 Release Announcement Page

[Pierre]

Le 19/11/2021 à 10:10, Kamil Tekiela a écrit :

I would suggest option number 5. Leave it as it is. Many people are still
not aware that PHP 8 has been released.
If that's not possible, then we should keep the page (opt 3), otherwise we
will be breaking links to it, e.g. on Stack Overflow.
Adding PHP 8.1 alongside would be great, but we already have upgrade pages,
so I'm not sure the effort is worth it.


Hello,

I do not agree, PHP 8 release page was really nice (even for me daily 
reading internals) and I think it could be a nice tradition to keep.


8.1 does bring lots of nice stuff, which deserve a nice presentation.

Regards,

--

Pierre

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

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Pierre Joye]

On Tue, Nov 16, 2021 at 4:11 PM Lynn  wrote:
>
>
>
> On Tue, Nov 16, 2021 at 4:52 AM Pierre Joye  wrote:
>>
>>
>> My vote will change to yes as soon as the change is an opt-in instead of an
>> opt-out for the 8.x lifetime.
>>
>
> What is the point of this change if it's an opt-in? Projects that are still 
> relying on dynamic properties today and "have no time" to fix them now, won't 
> have time in 3 years either. Please let us have nice things today instead of 
> years from now :)

If it is an opt-in (like Larry proposes f.e.), you will have them
today as well.

Best,
-- 
Pierre

@pierrejoye | http://www.libgd.org

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

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Pierre Joye]

Hi,

On Tue, Nov 16, 2021, 4:40 AM Matthew Brown 
wrote:

> On Fri, 12 Nov 2021 at 08:08, Nikita Popov  wrote:
>
> > Hi internals,
> >
> > I've opened the vote on
> > https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will close
> > 2021-11-26.
> >
> > Regards,
> > Nikita
> >
>
>
> I encourage people to vote "yes" on this, if you want PHP to be better
>

My vote will change to yes as soon as the change is an opt-in instead of an
opt-out for the 8.x lifetime.

best,
Pierre

>

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Pierre Joye]

On Sun, Nov 14, 2021, 11:42 PM Rowan Tommins 
wrote:

> On 14/11/2021 11:48, Pierre Joye wrote:
> > Also I do see it as a kind of strict mode addition and the depreciation
> as
> > well could be strict mode only.
>
>
> A quick reminder that PHP has no "strict mode". It has a "strict_types"
> declaration, which is probably misnamed, and should be something like
> "scalar_types=error" vs "scalar_types=coerce".
>
> yes, wrong word.
>

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

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Pierre Joye]

Hi Nikita,

On Fri, Nov 12, 2021, 11:34 PM Nikita Popov  wrote:

FWIW I think we should always deprecate things as soon as possible, to give
> people the maximum amount of awareness and time to address the issue before
> the actual removal occurs.


I voted no however I agree on this part, with a slight different view on
how it may be done.

> Meanwhile, 8.2 should include the
> > AllowDynamicProperties attribute so folks can start preparing.
> >
>
> Given how attributes in PHP work, this doesn't make sense to me. You can
> already use #[AllowDynamicProperties] in your code right now, without any
> special support from PHP. Only static analyzers / IDEs need to know that
> they shouldn't complain about it even on versions where it does not
> technically exist.



I agree with other that it should be allowed by default.

Also I do see it as a kind of strict mode addition and the depreciation as
well could be strict mode only.

It could make things too complicated, so only off by default would be an
acceptable compromise to me.

best
Pierre

Re: [PHP-DEV] fpassthru should get an optional length argument

[Pierre]

Le 30/10/2021 à 11:39, Hans Henrik Bergan a écrit :

ref https://bugs.php.net/bug.php?id=39135 ,
i was thinking about how to implement HTTP Range requests/HTTP 206 Partial
Content in userland php,
  and ofc it's possible to implement using fread() loops, but it'd be easier
(and faster? presumably) to implement if fpassthru() natively supported a
$max_bytes=null argument,

an example of where it would be useful:


Hello,

Can't you use fseek() and stream_copy_to_stream() to achieve what you're 
trying to do without consuming memory ?


Regards,

--

Pierre

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

[PHP-DEV] Re: Bugsnet

[Pierre Joye]

Hi Joe,

On Sun, May 9, 2021, 1:49 PM Joe Watkins  wrote:

> Morning internals,
>
>
> Having moved our workflow to github, now seems to be the time to seriously
> consider retiring bugsnet for general use, and using the tools that are
> waiting for us - Github Issues.
>

yes! yes! yes!

and we could you projects/roadmap too together with gh APIs and the RFC.

>

Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties

[Pierre]

Le 13/10/2021 à 14:42, Rowan Tommins a écrit :

On 13/10/2021 10:17, Guilliam Xavier wrote:

Off-topic:

    if ( class_exists('\\WeakMap') ) {


People should stop using a leading slash in FQCN *strings*. 
\Foo::class is "Foo", not "\Foo".  It might work generally but that's 
asking for problems (e.g. for autoloaders).


(Sorry.)



Hah, good point. I should probably just have just used ::class anyway 
(in which case the leading backslash is the quickest way of the sample 
code being pasteable into some other file):


if ( class_exists(\WeakMap::class) ) {

There's probably a bunch of other style no-noes in that example, but I 
did at least test it worked. :)



Regards,


I am surprised that:

if ( class_exists(\WeakMap::class) ) {

Actually works when the class does not exist.

It's not really surprising, I mean the FQDN::class in the end only 
resolve to a simple string no matter that the class exists or not, but, 
I'm being the devil's advocate here, there are use case were you would 
want the engine to crash when you explicitly reference/use a non 
existing class, even when it's only its name.


I'm sorry this is off-topic.

--

Pierre

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

Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties

[Pierre]

Le 13/10/2021 à 11:17, Guilliam Xavier a écrit :

Off-topic:

if ( class_exists('\\WeakMap') ) {
People should stop using a leading slash in FQCN *strings*.  \Foo::class is
"Foo", not "\Foo".  It might work generally but that's asking for problems
(e.g. for autoloaders).

(Sorry.)

And why not ? using the FQDN is 100% valid, autoloaders should take care 
of this, not the end user.


For what it worth, I'm using both, depending upon context, both can make 
sense.


Regards,

--

Pierre

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

Re: [PHP-DEV] BC breaking changes in PHP 8.1

[Pierre Joye]

On Sun, Sep 26, 2021, 7:42 PM Jordi Boggiano  wrote:

>
> > I'm surprised that is_resource() returns false for resource objects,
> > does anyone knows why it wouldn't return true in such case ?
> >
> > This is a very weird behavior, I'd expect it to return true, moreover
> > this is the most annoying detail of this BC break, in my opinion.
> >
> > I have lots of code using is_resource() but I usually don't bother
> > checking for type (maybe I'm doing it wrong). But I'd also expect
> > get_resource_type() to be deprecated somehow and return
> > backward-compatible values for converted resources to objects.
>
> Right, having is_resource return true for resourcey objects would have
> prevented all resource-related errors I ran into with php8.0 migration I
> believe. That'd be a welcome improvement/fix for 8.1.
>

that was proposed but purity won if I remember correctly.

That's kind of defeat the initial goal (attempt) of yearly releases. Now I
feel like we introduced more, small or big, bc in minor releases in the
name of purity. That counter balance the yearly release with no bc from a
migration pace pov.

best,
Pierre

>

Re: [PHP-DEV] [RFC] Locale-independent case conversion

[Pierre Joye]

Hi Tim,

On Thu, Sep 23, 2021 at 1:32 PM Tim Starling  wrote:
>
> Please consider my RFC for locale-independent case conversion.
>
> https://wiki.php.net/rfc/strtolower-ascii

very good one, thanks :)


> https://github.com/php/php-src/pull/7506

> The RFC and associated PR ended up going some way beyond the original
> scope, because for consistency, it's best if everything has the same
> concept of case folding. I saw this as an opportunity to clean up a
> common kind of locale-dependence in PHP which was previously inconsistent.

Good patch, I am commenting here as other or more discussions may be
better here.

I wonder if either JIT could be used for the intrinsics support,
adding neon, sse[2-4.2] or avc256/512 (the latter would basically
allow most common strings to be converted in one go.

If not, maybe split implementation however runtime cpu support would
be better. Many distributions built with SSE2 flags but are actually
ran on much recent CPUs, same for ARM (ie. graviton/neon f.e.).
Thoughts?

Maybe Dmitry has a better idea :)

Best,
-- 
Pierre

@pierrejoye | http://www.libgd.org

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

Re: [PHP-DEV] BC breaking changes in PHP 8.1

[Pierre]

Le 22/09/2021 à 16:24, Matthew Weier O'Phinney a écrit :

On Wed, Sep 22, 2021 at 9:01 AM G. P. B.  wrote:


On Wed, 22 Sept 2021 at 14:30, Matthew Weier O'Phinney <
mweierophin...@gmail.com> wrote:

As somebody who's been contributing to and maintaining OSS libraries
forever (since 2002), the pace of change of PHP is, frankly, ridiculous. I
can keep up with patches. I can keep up with new features. But BC breaks
EVERY YEAR just creates churn. I've spent most of the past 18 months doing
nothing but ensuring libraries work on new PHP versions. I then get users
angry that they aren't getting new features; if I don't update to the
latest PHP version, I get other users angry they can't use the library on
the newer PHP version. And with new PHP versions every year... I
essentially have to update every 2-3 years regardless, and will lose users
if I don't do it every year.

Figure out what the BC breaks are going to be, and do them all at once.
It's far easier for the ecosystem to adapt to a big drop of BC breaks every
3-5 years than it is every year.

Again, I DO like the resource objects feature. But getting a few here and
there over many minor releases is a lot of breakage to track and adapt to.
And that's just the tip of the iceberg.


Hello,

I fully understand your situation, but I want to mitigate, I do maintain 
a few OSS tools (and much more internal code where I work for) and I 
experienced those PHP upgrades as well (one project when from PHP 5.6 to 
7.4 and its platform code served as a basis for a new one using 8.0, for 
example, but I have many), and it never was such a pain. Laminas is a 
huge framework thought, so it seems more likely that you experience this 
pain*10 compared to me. Nevertheless, I have an opposite opinion, I 
think that until now, PHP has did an extremely good job in not making 
too much BC breaks, and keeping those BC breaks easy to deal with.


Regards,

--

Pierre

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

Re: [PHP-DEV] BC breaking changes in PHP 8.1

[Pierre]

Le 22/09/2021 à 15:29, Matthew Weier O'Phinney a écrit :

Yesterday, I opened an issue regarding a change in the pgsql extension (
https://bugs.php.net/bug.php?id=81464).

PHP 8.0 introduced the concept of "resource objects". Where previously we
would have resources, and use `get_resource_type()` when we needed to
differentiate various resources, resource objects give us immutable objects
instead that allow us to type hint. Personally, I think this is wonderful!

The rollout for 8.0 was incomplete, however, and only touched on something
like 4-6 different resource types. Still, a good start.

With PHP 8.1, we're seeing the addition of more of these, and it was
encountering one of those changes that prompted the bug I previously linked
to.

Here's the issue: while overall, I like the move to resource objects,
introducing them in a MINOR release is hugely problematic.

Previously, you would do constructs such as the following:

 if (! is_resource($resource) || get_resource_type($resource) !==
$someSpecificType) {
 // skip a test or raise an exception
 }

Resource objects, however:

- Return `false` for `is_resource()` checks.
- Raise a warning for `get_resource_type()` checks, and/or report the
resource object class name — which differs from the previous resource names
in all cases.


Hello,

I'm surprised that is_resource() returns false for resource objects, 
does anyone knows why it wouldn't return true in such case ?


This is a very weird behavior, I'd expect it to return true, moreover 
this is the most annoying detail of this BC break, in my opinion.


I have lots of code using is_resource() but I usually don't bother 
checking for type (maybe I'm doing it wrong). But I'd also expect 
get_resource_type() to be deprecated somehow and return 
backward-compatible values for converted resources to objects.


Regards,

--

Pierre

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

Re: [PHP-DEV] Adding `final class Deque` to PHP

[Pierre Joye]

On Tue, Sep 21, 2021, 11:56 PM Mike Schinkel  wrote:

> > On Sep 21, 2021, at 3:45 AM, Pierre Joye  wrote:
> >
> > On Tue, Sep 21, 2021 at 11:21 AM Mike Schinkel 
> wrote:
> >
> >> Honestly, at first I confused `Deque` with `Dequeue` and was wondering
> why we would name a class with a verb?  It wasn't until Rowan's comment
> that I realized `Deque` is an abbreviation.
> >>
> >> Which begs the question: how many other PHP developers will know
> computer science terms like this well enough to know `Deque` is a noun when
> they see it, and more importantly how many PHP developers will think to
> search for `Deque` when they need a queue?
> >
> > Unlike the Vector name which is really confusing as it is not a
> > vector, Deque is actually relatively known for anyone needing a double
> > ended queue. It even comes first in google search, wikipedia or java
> > implementations, which matches this implementation.
>
> Being able to google what Deque means is one thing, but thinking to search
> for it when you don't know it exists *and* you don't know that Deque is the
> term you would need to be searching for.
>
> > We expect our
> > users to know all weird names of different patterns, I trust them to
> > be able to learn what a Deque is. :)
>
> So we expect PHP developers to have a computer science background? Maybe
> you are assuming everyone minimally has your expertise?  Have we as a group
> decided to forsake beginners?



It is not what I was trying to explain.

However if one looks at the php documentation looking for specific things
like these, the Deque will be there.

So I am not expecting anyone to have a CS background (btw, I don't),
however I do have a minimal trust in users reading the docs and doing a
minimum of research.

best,

Re: [PHP-DEV] Adding `final class Deque` to PHP

[Pierre Joye]

On Tue, Sep 21, 2021 at 11:21 AM Mike Schinkel  wrote:

> Honestly, at first I confused `Deque` with `Dequeue` and was wondering why we 
> would name a class with a verb?  It wasn't until Rowan's comment that I 
> realized `Deque` is an abbreviation.
>
> Which begs the question: how many other PHP developers will know computer 
> science terms like this well enough to know `Deque` is a noun when they see 
> it, and more importantly how many PHP developers will think to search for 
> `Deque` when they need a queue?

Unlike the Vector name which is really confusing as it is not a
vector, Deque is actually relatively known for anyone needing a double
ended queue. It even comes first in google search, wikipedia or java
implementations, which matches this implementation. We expect our
users to know all weird names of different patterns, I trust them to
be able to learn what a Deque is. :)

best,
-- 
Pierre

@pierrejoye | http://www.libgd.org

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

Re: [PHP-DEV] Adding `final class Deque` to PHP

[Pierre]

Le 20/09/2021 à 15:46, tyson andre a écrit :

Hi Pierre,
I'm not certain what you mean by "normalize".
https://www.merriam-webster.com/dictionary/normalize mentions


At least please try to make it serious, I think you understood what I 
meant. I'm in no place in arguing about technical details about how it 
should be implemented because the C language is not a place where I 
shine and I trust people like you for doing it best.


Nevertheless, my only point was, please put all data structures 
altogether, and please, just don't throw them in global namespace. 
Otherwise, as we said in french "ça va être un sacré bordel là dedans" 
(actually, it already is "un sacré bordel").


I'll let someone better in english than me translate, I'm not a native 
english speaker I could get it wrong.



If you also mean all datastructure RFCs should be combined into a single RFC,
I'd considered combining the Vector RFC with https://wiki.php.net/rfc/deque,
but decided against combining the RFCs in this instance, because of:


No, not necessarily, they don't need to be in the same RFC, having one 
per data structure is probably the way to go you'll maximize chances 
that each one pass vote. Nevertheless, many RFC's exist and if there's 
many other to come, no matter in which order they'll happen and no 
matter at which pace, they still can be seen as a "whole", and a 
namespace is a in my opinion still a good idea.


I won't debate on the rest, because you are much more both involved and 
technically competent than I am, and as being someone stupid, I need 
things to be well-organized to find them easily, that's the only 
constructive argument I have to bring to this discussion.


Regards,

--

Pierre

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

Re: [PHP-DEV] Adding `final class Deque` to PHP

[Pierre]

Le 20/09/2021 à 02:03, tyson andre a écrit :

Hi internals,

I've created a new RFC https://wiki.php.net/rfc/deque to add a `final class 
Deque`


Hello,

It seems that you are writing more than one RFC to add many data 
structures. I love that you're doing that, but I suggest that you'd 
normalize them all and place all new classes in a single new dedicated 
namespace.


Regards,

--

Pierre

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

Re: [PHP-DEV] RFC: Add `final class Vector` to PHP

[Pierre Joye]

Hi Tyson,

On Sat, Sep 18, 2021, 10:46 PM tyson andre 
wrote:

> Hi Peter Bowyer,
>
>
> Many of php's names are based on the naming choices in libraries made in
> C/C++.
> So using https://cplusplus.com/reference/vector/vector/ for my RFC
> https://wiki.php.net/rfc/vector
> seems like the most natural naming choice,
> and would make it easier for people with backgrounds in that family of
> languages to find the functionality they're looking for.
>

I do and as mentioned before it makes it confusing and harder because of
the use of zval and not specific type like in c++.  A zval is not a php
userland type.

C++ initialized a vector using the type:

vector  myvalues;


then all elements must be of type int.

This proposal breaks this already.

I expect having a second `Stack` would be confusing and make it hard to
> remember which is the efficient one.
> (Especially since stacks typically don't include specialized resizing
> methods)
>

Yes, as it isn't a stack either ;)

I have no idea how you could name, sorry,  but definitely not a vector.



> Also, your comment is ambiguous. Are you saying that you personally object
> to the name,
> or that you're fine with the name but think that the comments by
> Larry/Chris/Pierre in this email thread are representative of voters.
>


Maybe representative of what vectors are and how they are used.

Vectorization is a key to programming now like multi threading or
parraelism a few years back. Vectorization is an old principles as
processors gain in power in the last year, this the way raw performance
scale even more with adding more cores.

Now, having a fixed array named Vector in php would be a big mistake and
actually very confusing.

best,
Pierre

>

Re: [PHP-DEV] RFC: Add `final class Vector` to PHP

[Pierre Joye]

Hi Tyson,

On Sat, Sep 18, 2021, 10:21 AM tyson andre 
wrote:

>
> This proposal already has a fixed-sized type - that type is `mixed` (or
> `zval` internally), like ArrayObject, WeakMap, etc. already have in their
> values.
> (Similar to how basic Java collections (e.g. ArrayList​) are all
> collections of `Object` after generic type erasure.)
>


Thanks for the clarification.

So the name of this proposal is misleading. They are not vector.

I am not sure php needs another type of fixed array at this stage. So -1
here overall.

best,
Pierre

>

Re: [PHP-DEV] RFC: Add `final class Vector` to PHP

[Pierre Joye]

Good morning,

Not sure you care or read my reply but I had to jump in one more time here :)

On Sat, Sep 18, 2021 at 8:49 AM tyson andre  wrote:

> setSize is useful in allocating exactly the variable amount of memory needed 
> while using less memory than a PHP array.
> `setSize($newSize, 0)` would be much more efficient and concise in 
> initializing the value.
>
> - Or in quickly reducing the size of the array rather than repeatedly calling 
> pop in a loop.

I would rather not reduce it at all, but use the vector_size and keep
it. User land set its max size but a realloc/free should not be
necessary and counter productive from a perf point of view. If one
uses it in a daemon, it can always be destroyed as needed.

> > To echo Pierre, a Vector needs to be of a single guaranteed type.
> > Yes, this gets us back to the generics conversation again, but I presume 
> > (perhaps naively?) there are ways to address this question without getting 
> > into full-blown generics.
>
> Yep, as you said, this type is mixed, just like the SplFixedArray, 
> ArrayObject, values of SplObjectStorage/WeakMap, etc.
> Generic support is something that's been brought up before, investigated, 
> then abandoned.
>
> My concerns with adding StringVector, MixedVector, IntVector, FloatVector, 
> BoolVector, ArrayVector (confusing), ObjectVector, etc is that
>
> - I doubt many people would agree that there's a wide use case for any
>   specific one of them compared to a vector of any type.

I am lost here. This is the main usage of Vector. For linear
arithmetic like dot product, masking, add/sub/mul/div of vector etc. I
do not see any other usage per see for all the things I have
implemented or saw out there. Additionally, f.e., a string is a vector
already on its own, I am not sure a vector of vectors makes sense ;).

>   This would be even harder to argue for than just a single Vector type.
> - Mixes of null and type `T` might make sense in many cases (e.g. optional 
> objects, statistics that failed to get computed, etc) but would be forbidden 
> by that
> - It would be a bad choice if generic support did get added in the future.

These are special cases for general purposes of vectors. Implementing
vectors focusing on these special cases rather than the general
purpose (vectorization) would be a strategic mistake. I mentioned it
before, but please take a look at the numpy's Vector f.e., with
python's operator overload, what has been done there is simply
amazing, bringing vector processing/arithmetic a huge boost in
performance, even with millions of entries (14 to 400x speed boost
compared to classic array, even fixed).

> > But really, a non-type-guaranteed Vector/List construct is of fairly little 
> > use to me in practice, and that's before we even get into the potential 
> > performance optimizations for map() and filter() from type guarantees.
>
> See earlier comments on `vec`/Generics not being actively worked on right now 
> and probably being a far way away from an implementation that would pass a 
> vote.

Generics!=Vector. But I hope that's not the way we are heading here :)

> As for optimizations, opcache currently doesn't optimize individual global 
> functions (let alone methods), it optimizes opcodes.
> Even array_map()/array_filter() aren't optimized, they call callbacks in an 
> ordinary way.
> E.g. https://github.com/php/php-src/pull/5588 or 
> https://externals.io/message/109847 regarding ordinary methods.
>
> Aside: In the long term, I think the opcache core team had a long-term plan 
> of changing the intermediate representation to make these types of 
> optimizations feasible without workarounds like the one I proposed in 5588

You are fully correct here, I see a lack of the engine devs
involvement (not complaining, just a state of the affairs :) in such
RFC where this kind of feature could greatly benefit PHP. Well
planned, this is a huge addition to PHP.

It is also why I am convinced that doing it right for Vectors (as a
start) and thinking forwards to JIT and ops overloading (internally or
userland) to allow smooth and nice vectorization (as some parts use
them already internally f.e.) will bring PHP up to speed with the
competition. If we don't, we just have something that would be similar
to what anyone could do in userland with more flexibility.

Best,
-- 
Pierre

@pierrejoye | http://www.libgd.org

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

Re: [PHP-DEV] RFC: Add `final class Vector` to PHP

[Pierre Joye]

Hi Tyson,

Back on my laptop so I will answer my question myself as I read the
source code. Please, really, that should be part of the RFC content.
Half of the questions here are about APIs, goals, etc. RFC should be
specifications as much as possible.

On Fri, Sep 17, 2021 at 12:43 PM Pierre Joye  wrote:
>
> Hello Tyson,
>
> Vector support would be very good. JIT can do a lot with them if we
> have a clean Vector implementation, or even without JIT.

Teds\Vector is named as Vector however I am afraid it is not, it is a
fixed array implementation. A vector, as in all other languages are,
for the definition, , fixed or variable sizes, of element of the same
type, The same type is absolutely key here.The reason to require the
same type is the core principle of vector (and vectorization),
structure of arrays rather than array of structs. The latter are hard
(or pointless) to parallelize and hard to optimize. An easy way to
play with Vector would be to try out numpy's Vector, which is by far
one of the best (and fastest) scripting language implementations of
Vector.

I did not spend enough time on the code, but I would by deconstructing:

typedef struct _teds_vector_entries {
size_t size;
size_t capacity;
zval *entries;
} teds_vector_entries;

to  different types (or using multiple entries with a zval_type entry.
ie. for a zval float Vector:

typedef struct _teds_vector_entries {
size_t size;
size_t capacity;
double float;
} teds_vector_entries;

Alternatively, common C port of C++ Vector do something along this line:

typedef struct _cVector{
unsigned int size;
unsigned int cnt_elements;
unsigned int element_size;
void *elements;
} cVector;

where the initialization is:

void cVectorInit (cVector *array, unsigned int element_size); where
element_size is sizeof(double) f.e.

so any append, truncate, etc. are aware of the size to be
(re)allocated, if needed.

The only addition to handle zval would be:

typedef struct _cVector{
unsigned int size;
unsigned int cnt_elements;
zval_enum type zval_type;
unsigned int element_size;
void *elements;
} cVector;

Doing so will drastically help to finally have a simple, by usage and
implementation/api, way to implement vectorization using PHP.

I would also like to suggest having it in the engine somehow, if it is
not possible to have JIT jump in here if it is not an actual type in
the engine. While it is possible to have intrinsics implementations in
any extension, it won't be as good or efficient as an engine type with
JIT support.

Also, as it stands, I do not think it can be called a Vector. So I am
not too keen for it as I don't think we need another SplFixed*Array
implementation, as simple as it could be. The RFC needs some work
anyway before any vote can be taken.

In any case, if the above would be something you may consider (to
implement an actual vector), I can help and would be happy too if you
need/like to.

Best,
-- 
Pierre

@pierrejoye | http://www.libgd.org

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

Re: [PHP-DEV] RFC: Add `final class Vector` to PHP

[Pierre]

Le 17/09/2021 à 14:54, tyson andre a écrit :

Aside: https://github.com/TysonAndre/pecl-teds#iterable-functions
starts doing that, but evaluating eagerly instead of using generators.
I still don't think there's enough functionality yet to re-propose that.

Nice to know this, I wasn't aware it even existed, I'll have a look.

I know this vector proposal is not about that, but nevertheless, in my
opinion, it must start preparing the terrain for this, or all other RFC
in the future will only create new isolated data structures and make the
SPL even more inconsistent.

It's possible, but I don't know what others think.

1. https://www.php.net/manual/en/class.ds-collection.php actually seems fairly 
universal, but out of scope, and I don't know if people would json encode a 
SplMaxHeap. Right now that isn't implemented and the value is always `{}`
2. `add($value)/remove($value)/contains[Value]($value)` is limited to some 
structures - Only containsValue() would apply to ArrayObject/SplObjectStorage. 
The others wouldn't work since you'd need to know the keys as well.
That's true, vector is a bit aside of what we'd expect from a full blown 
collection API, it's a very basic structure in the end so it can 
probably live on its own.

Also,

- Union type/intersection type support exists, so allowing any generic 
collection interface is less urgent.
That's right, but I don't think that union/intersection types solve the 
generic collection problem, you'd still have to match for specific class 
names or interfaces if methods are not rationalised in a single API.

- equals() may work, though infinite recursion (or the way it is or isn't 
detected) in circular data structures is a potential objection, especially with 
lack of stack overflow detection - php just crashes/segfaults without a useful 
method when it runs out of stack space.

For the ones that are universal, 
Countable/ArrayAccess/IteratorAggregate/Traversable already exist.
Yes, they exist, but I wouldn't place IteratorAggregate as being part of 
the interface, it's about implementation, but right. Anyway altogether 
they form a very poor API covering a very small surface and I'd imagine 
those becoming a legacy thing if a new API was introduced.

Also, as you said, this RFC is not about that.
Requiring that anyone systematically overhaul existing data structures before 
adding any new data structures
seems like it would significantly delay or discourage any future additions of 
data structures.

In the immediate future, an RFC only doing that would not have much short-term 
benefit to users - it would also have short-term drawbacks for what I consider 
not enough benefit,
if adopting that interface made libraries drop support for older php versions.


I think your point is legit, and a part of me agrees with you, probably 
having some data structure before thinking about rationalisation is 
something that would make people move forward. Nevertheless it's always 
very difficult to change things once they're here, and the whole problem.


I crave so deeply for a complete, easy to use, well documented and 
standard collection API that I always jump on such RFC's to tell people 
"stop using DS, stop using Doctrine Collections, stop using "[name it 
here] collection", please everyone, let's design, implement and use the 
single and same one, so that we will never have to support them all 
(them being the 1,000 existing duplicated library in userland) in our 
framework or business code.


Thanks a lot for your answer and you time, despite the fact I still 
think that designing a collection first can still be done, having the 
vector type/class in core is a great idea.


Regards,

--

Pierre

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

Re: [PHP-DEV] Make strtolower/strtoupper just do ASCII

[Pierre Joye]

Hi Tim,

hope you are well :)


On Fri, Sep 17, 2021, 5:07 PM Tim Starling  wrote:

>
> We could add a global mode, although that would prevent constant
> propagation, if that's what you mean by adding them to the optimizer.
> Or we could add variant functions like locale_strtolower() and
> locale_strtoupper(). But I think I would want to hear from someone who
> uses locale-dependence so I can understand what their needs are. I
> guess the RFC will sort that out.
>


may I suggest a function rather than a ino setting?

it has the advantage to be contextual and allows the user to enable/disable
it before calling some library api they may not be able to(or don't want
to) patch.

str_use_locale(bool) f.e.?

and at some point it can be false by default and later on removed.


best,
Pierre

>

Re: [PHP-DEV] RFC: Add `final class Vector` to PHP

[Pierre]

Le 17/09/2021 à 04:09, tyson andre a écrit :

Hi internals,

I've created a new RFC https://wiki.php.net/rfc/vector proposing to add `final 
class Vector` to PHP.


Hello,

That's nice, and I like it, but like many people I will argue about the 
API itself.


One thing is that there's many methods in there that would totally fit 
generic collection common interfaces, and in that regard, I'd be very 
sad that it would be merged as is.


I think it's taking the problem backwards, I would personally prefer that:

 - This RFC introduces the vector into a new Collection namespace, or 
any other collection/iterable/enumerable related namespace, that'd 
probably become the birth of a later to be standard collection API.


 - Start thinking about a common API even if it's for one or two 
methods, and propose something that later would give the impulsion for 
adding new collection types and extending this in order to be become 
something that looks like a really coherent collection API.


If this goes in without regarding the greater plan, it will induce 
inconsistencies in the future, when people will try to make something 
greater. I'd love having something like DS and nikic/iter fused 
altogether into PHP core, as a whole, in a consistent, performant, with 
a nice and comprehensive API (and that doesn't require to install 
userland dependencies).


I know this vector proposal is not about that, but nevertheless, in my 
opinion, it must start preparing the terrain for this, or all other RFC 
in the future will only create new isolated data structures and make the 
SPL even more inconsistent.


Regards,

--

Pierre

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

Re: [PHP-DEV] RFC: Add `final class Vector` to PHP

[Pierre Joye]

Good afternoon Christian,

On Fri, Sep 17, 2021 at 3:07 PM Christian Schneider
 wrote:
>
> Am 17.09.2021 um 04:09 schrieb tyson andre :
> > I've created a new RFC https://wiki.php.net/rfc/vector proposing to add 
> > `final class Vector` to PHP.
>
>
> First of all: I don't have a strong opinion on a Vector class being useful or 
> necessary.
>
> But I have two comments about this RFC:
> 1) Using the very generic name Vector without any prefix/namespace seems 
> dangerous and asking for BC breaks.
> 2) I don't like that this class is final. The reasons given in 
> https://wiki.php.net/rfc/vector#final_class 
> <https://wiki.php.net/rfc/vector#final_class> seem unconvincing to me and 
> restrict the usage of Vector in a way which makes me question the usefulness 
> to a big enough part of the PHP community.
>
> These two reasons combined would make me reject the RFC at the current stage.

I think it is more in a draft stage for discussions.

To be more precise with my earlier reply, I only see such additions as
useful if it is an actual Vector as known in other languages and
widely used the last years in ML and other similar areas like data or
image processing.

To me a vector is useful if it allows vectorized operations, as in
SIMD, AltVec, CUBA etc. Some refs:

https://users.ece.cmu.edu/~franzf/teaching/slides-18-645-simd.pdf
https://indico.cern.ch/event/238763/attachments/401939/558861/HP-intel_mic_optimization.pdf

These two refer to Intel architecture but ARM (especiall v9 with Neon,
MIPS, ppc and maybe soon riscV does support such operations as well.
It is amazingly well suited for raw performance increase. I can
imagine having annotations and/or specific optimization for vectors of
scalar processing. It requires a bit of (re)thinking, but it is
totally worth it.

Generic multiple data types vectors are less useful for such things
and SplFixedArray does it already, if I understand the RFC, as it
stands now, correctly.

best,
-- 
Pierre

@pierrejoye | http://www.libgd.org

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

Re: [PHP-DEV] RFC: Add `final class Vector` to PHP

[Pierre Joye]

Hello Tyson,

Vector support would be very good. JIT can do a lot with them if we
have a clean Vector implementation, or even without JIT.

What is your base inspiration for Vector? I do like the pretty
standard C++ Vector implementation:

https://www.cplusplus.com/reference/vector/vector/

Where a Vector is initalizied with:

$myIntVector = vector;

What is key for performance is also the alloc/realloc/free strategy.
In C++ (or most C or other languages custom) gives control to the
creators to define max size, capacity, etc.

If a non typed Vector is the goal, then I am less in need of it, still
good to have but not as good as a clear pure Vector support :).

Also I think it will be very good to have more details about what this
RFC proposes in the RFC. It is kind of hard to follow right now, with
all external links. RFCs are better if they act as a real
specification :)

Best,
Pierre

On Fri, Sep 17, 2021 at 9:10 AM tyson andre  wrote:
>
> Hi internals,
>
> I've created a new RFC https://wiki.php.net/rfc/vector proposing to add 
> `final class Vector` to PHP.
>
> PHP's native `array` type is rare among programming language in that it is 
> used as an associative map of values, but also needs to support lists of 
> values.
> In order to support both use cases while also providing a consistent internal 
> array HashTable API to the PHP's internals and PECLs, additional memory is 
> needed to track keys 
> (https://www.npopov.com/2014/12/22/PHPs-new-hashtable-implementation.html - 
> around twice as much as is needed to just store the values due to needing 
> space both for the string pointer and int key in a Bucket, for non-reference 
> counted values)).
> Additionally, creating non-constant arrays will allocate space for at least 8 
> elements to make the initial resizing more efficient, potentially wasting 
> memory.
>
> It would be useful to have an efficient variable-length container in the 
> standard library for the following reasons:
>
> 1. To save memory in applications or libraries that may need to store many 
> lists of values and/or run as a CLI or embedded process for long periods of 
> time
>(in modules identified as using the most memory or potentially exceeding 
> memory limits in the worst case)
>(both in userland and in native code written in php-src/PECLs)
> 2. To provide a better alternative to `ArrayObject` and `SplFixedArray` for 
> use cases
>where objects are easier to use than arrays - e.g. variable sized 
> collections (For lists of values) that can be passed by value to be read and 
> modified.
> 3. To give users the option of stronger runtime guarantees that property, 
> parameter, or return values really contain a list of values without gaps, 
> that array modifications don't introduce gaps or unexpected indexes, etc.
>
> Thoughts on Vector?
>
> P.S. The functionality in this proposal can be tested/tried out at 
> https://pecl.php.net/teds (under the class name `\Teds\Vector` instead of 
> `\Vector`).
> (That is a PECL I created earlier this year for future versions of iterable 
> proposals, common data structures such as Vector/Deque, and less commonly 
> used data structures that may be of use in future work on implementing other 
> data structures)
>
> Thanks,
> Tyson
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>


-- 
Pierre

@pierrejoye | http://www.libgd.org


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

Re: [PHP-DEV] DateTimeZone silently falls back to UTC when providing seconds

[Pierre]

Le 13/09/2021 à 14:06, Andreas Heigl a écrit :

Hey

What use-case does it serve to allow offsets that are not reflected in 
the TZDB? 


Yes there are use cases:

 * Your TZDB is obsolete, your hardware and OS is obsolete, but the
   prod is still running (it happens more than you think).
 * You don't care about the TZ name and just use offsets (it happens
   also, happened to me not so long ago I needed to convert dates with
   arbitrary offset from some storage).
 * You fetch dates from a storage which doesn't care about time zone
   names (hello any SQL database), for example pgsql doesn't store
   offsets only UTC time, but it accepts arbitrary offsets as input,
   regarding output dates converted to the explicitly asked time zone
   or client connection time zone (so actually you this is not a valid
   use case, but I wanted to highlight that pgsql accepts any arbitrary
   offset).
 * You fetch broken dates with broken timezone from a broken storage,
   but you have to deal with those dates one way or another.

There as many good reasons for accepting arbitrary offset that there are 
offsets on each, so basically that 24*60 good reasons.


That's my opinion, as being confronted with dates problems quite often.

Just for fun, some pgsql random select:

db=# select timestamp with time zone '2021-09-13 14:24:00+03:15' at time 
zone 'utc';

  timezone
-
 2021-09-13 11:09:00

Regards,

--

Pierre

Re: [PHP-DEV] Adding a way to disable the stat cache

[Pierre Joye]

Hi,




On Tue, Sep 7, 2021, 5:49 PM Kamil Tekiela  wrote:

> It's WSL2
> uname -r
> 5.4.72-microsoft-standard-WSL2
>

no need to test on wsl2, that's a dockerized linux.


best,
Pierre

>

Re: [PHP-DEV] [RFC] Move RNG functions ext/random

[Pierre Joye]

Hi Go,

Awesome, excellent work and will make the whole thing easier :)

+1 already!

best,

On Tue, Sep 7, 2021 at 3:29 AM Go Kudo  wrote:
>
> Hi internals.
>
> As a result of the exchange in the following thread, it seems appropriate
> to separate the proposals.
>
> In line with this, we have created a proposal to first clean up the
> existing RNG-related functionality and move it from ext/standard to
> ext/random.
>
> https://wiki.php.net/rfc/random_ext
>
> Hopefully this will get a good response.
>
> Regards,
> Go Kudo



-- 
Pierre

@pierrejoye | http://www.libgd.org

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

Re: [PHP-DEV] Adding a way to disable the stat cache

[Pierre Joye]

On Mon, Sep 6, 2021, 10:50 PM Christian Schneider 
wrote:

> Am 06.09.2021 um 16:46 schrieb Pierre Joye :
> > Also as someone mentioned here afterwards, instead of removing it
> > straight away, I would go with the flag first, less risky :)
>
> Out of curiosity: Do you think disabling the stat cache could be harmful?
>

only for performance on windows TS. I think still too much use apache with
mod php I think.


If no, why make it an option?
> If yes, should we be allowing it?
>

yes, off by default first?


best
Pierre