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

[Flávio Heleno]

On Thu, May 9, 2024 at 7:51 AM Niels Dossche 
wrote:

> On 08/05/2024 15:40, Gina P. Banyard wrote:
> > Hello Internals,
> >
> > I would like to formally propose my idea for exit() as a function
> brought up to the list on 2024-02-24 [1] with the following RFC:
> > https://wiki.php.net/rfc/exit-as-function
> >
> > There have been some slight tweaks to the implementation, namely that
> the transformation from a "constant" to a function is done at compile time
> and we do not hook into the behaviour of constants any longer.
> >
> > Let me know what you think.
> >
> > Best regards,
> >
> > Gina P. Banyard
> >
> > [1] https://externals.io/message/122483
>
> Hi Gina
>
> Thanks for proposing this, I'm in favor of this change because this
> creates more consistency.
>
> Kind regards
> Niels
>

Hi all,

Is there a list of other "functions" that are handled as "constants"?

-- 
Atenciosamente,

Flávio Heleno

Re: [RFC] OOP API for cURL extension

[Flávio Heleno]

On Wed, Feb 14, 2024 at 10:44 PM Sara Golemon  wrote:

> Good afternoon folks, I'd like to open discussion on adding OOP APIs to
> the cURL extension.
> https://wiki.php.net/rfc/curl-oop
>
> This has been a long standing bug-bear of mine, and I think its time has
> come.
>
> try {
>   (new \CurlHandle)->setOpt(YOUR_VOTE, true)->exec();
> } catch (\CurlHandleException $ex) {
>   assert(false); // Why not?!
> }
>
> -Sara
>

Although I do not have voting karma, that'd be a +1 from me!

-- 
Atenciosamente,

Flávio Heleno

Re: [PHP-DEV] Apply strict_types to internal functions

[Flávio Heleno]

On Wed, Aug 30, 2023 at 7:14 AM Saki Takamachi  wrote:

> I accidentally wrote the name in Japanese and it looks weird, so I'll
> resend it, sorry.
>
> I also skimmed over past discussions.
>
> I've found that having full control over `strict_types` globally is not a
> good idea. This is because it can break the behavior of many libraries, and
> developers don't always respond appropriately to this fix.
>
> So I came up with the following idea.
> Allows a new value of 2 for strict_types.
>
> However, since magic numbers make the code difficult to read, I thought it
> would be a good idea to also provide strings that can serve as constants
> and aliases.
>
> This could provide new options to users while safely maintaining backwards
> compatibility.
>
> example:
> ```
> // weak
> declare(strict_types=0);
> declare(strict_types='weak');
> declare(strict_types=STRICT_TYPE_MODE_WEAK);
>
> // strict
> declare(strict_types=1);
> declare(strict_types='strict');
> declare(strict_types=STRICT_TYPE_MODE_STRICT);
>
> // strict with internal func
> declare(strict_types=2);
> declare(strict_types='strict_with_internal_func');
> declare(strict_types=STRICT_TYPE_MODE_WITH_INTERNAL_FUNC);
> ```
>
> I need more time to come up with a better name.
>
> Saki
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
I'm not entirely sure if this is 100% related, but it seems to be.

If you don't declare "strict_types" and pass a Stringable instance as the
first argument to json_decode, it works as expected [1].

On the other hand, when you declare "strict_types" and pass a Stringable
instance as the first argument to json_decode, it fails [2].

Fatal error: Uncaught TypeError: json_decode(): Argument #1 ($json) must be
> of type string, strcls given
>

[1] https://3v4l.org/TXAUi
[2] https://3v4l.org/uEhbM

-- 
Atenciosamente,

Flávio Heleno

Re: [PHP-DEV] Default values for php.ini environment variables

[Flávio Heleno]

I don't have voting rights, but this is a very positive addition IMO.


On Thu, Jul 13, 2023 at 10:27 AM Derick Rethans  wrote:

> Hi,
>
> coming forth out of an Xdebug issue
> (https://bugs.xdebug.org/view.php?id=2174) I made a pull request so that
> it is possible to use a fallback value in environment variables in INI
> files, such as in:
>
> xdebug.start_with_request = ${PHP_XDEBUG_START_WITH_REQUEST:-default}
>
> This is a syntax that bash also supports.
>
> Ilija pointed out an already existing PR
> (https://github.com/php/php-src/pull/11351) which had been extensively
> reviewed. Its author never seem to have emailed the list, so here I am.
> I would like to see this in PHP 8.3, and don't see the need for an RFC.
>
> If there are no objects, I'll merge this in the next few days.
>
> cheers,
> Derick
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

-- 
Atenciosamente,

Flávio Heleno

Re: [PHP-DEV] ??= and function calls

[Flávio Heleno]

Great catch Ilija!

Do you mind sharing how did you stumble upon it?

Thank you!

On Wed, Jul 5, 2023, 06:31 Dmitry Stogov  wrote:

> On Wed, Jul 5, 2023 at 1:15 AM Ilija Tovilo 
> wrote:
>
> > Hi everyone
> >
> > I recently discovered some unfortunate behavior of the coalesce
> > assignment operator (??=) in combination with function calls. Here's
> > the TL;DR:
> >
> > foo()['bar'] ??= 42;
> >
> > Currently, this code calls foo() twice. This seems rather unexpected.
> > The technical reason as to why this happens is not straight-forward,
> > but I will attempt to explain below. The behavior was not specified in
> > the RFC (https://wiki.php.net/rfc/null_coalesce_equal_operator) and is
> > completely untested, and as such I don't believe it is by design. My
> > proposal is to change it so that foo() is only called once.
> >
> > This is what is happening in detail.
> >
> > ??= is special in that it needs to evaluate the lhs (left hand side)
> > twice. At first, we need to check if the offset exists, then
> > conditionally execute the rhs (right hand side), re-fetch the offset
> > and assign the rhs value to it. The reason for the re-fetching of the
> > offset is that the evaluation of the rhs may invalidate the offset.
> > This is explained in the following blog post:
> >
> >
> https://www.npopov.com/2017/04/14/PHP-7-Virtual-machine.html#writes-and-memory-safety
> > Essentially, the offset may be a pointer into an array element or
> > object property. If the rhs frees the array or object, or grows the
> > array causing a reallocation (meaning it is moved to some other place
> > in memory), the pointer is no longer valid. For this reason, PHP makes
> > sure no user code may execute between the fetching of an offset and
> > the assignment to it. Normally, that just means evaluating the rhs
> > before fetching the offset. In this case, we need to evaluate the lhs
> > first to know if we even should evaluate the rhs.
> >
> > Naively evaluating the lhs again poses a problem for expressions with
> > side-effects. For example:
> >
> > $array[$x++] ??= 42;
> >
> > We do not want to re-evaluate the entire expression because $x++ will
> > lead to a different array offset the second time around. The way this
> > is solved is by "memoizing" any compiled expression in the lhs that is
> > *not* a variable, meaning not part of the offset that may be
> > invalidated. Internally, a variable is considered anything that may be
> > written to, i.e. local variables ($foo), properties ($foo->bar,
> > Foo::$bar), array offsets ($foo['bar']), and function calls (foo(),
> > $foo->bar(), Foo::bar(), $foo(), as they may return a modifiable
> > reference). The fact that function calls are included in that list
> > leads to the problem presented above. It is not actually necessary to
> > exclude them from memoization because their result may not be
> > invalidated.
> >
> > Another inconsistency is that function call arguments will be
> > re-evaluated, but only if they are not part of some other expression.
> >
> > a. foo(bar())['baz'] ??= 42;
> > b. foo(bar() + 0)['baz'] ??= 42;
> >
> > a calls both foo() and bar() twice. b however calls foo() twice but
> > bar() only once. That is because the expression bar() + 0 is *not*
> > considered a variable and as such gets memoized.
> >
> >
> This is definitely a bug in the original implementation.
> In case a function is evaluated twice and returns different values, we
> check one value, but assign to another.
>
>
> > I propose to unconditionally memoize calls (in all forms) when they
> > appear in the lhs of a coalesce expression. This will ensure that
> > calls are only executed once, including function arguments and the lhs
> > of method calls. Consequently, the assignment will be performed on the
> > same offset that was previously tested, even if the expression
> > contains a function call with side-effects.
> >
> > The implementation for this change is simple:
> > https://github.com/php/php-src/pull/11592
> >
> > Let me know if you have any concerns. I'm planning on merging this for
> > master if there is consensus on the semantics.
> >
>
> +1
>
> Thanks. Dmitry.
>
>
> > Ilija
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >
> >
>

Re: [PHP-DEV] RFC Idea - json_validate() validate schema

[Flávio Heleno]

On Wed, Mar 1, 2023 at 9:23 AM juan carlos morales <
dev.juan.mora...@gmail.com> wrote:

> Jakub, wow, great to know this. thanks for writting.
>
> Ok, then  I will assume that this feature will come from you
> sometime in future.
>
> Since json_validate() was announced ... I have being receiving
> messages (a lot) about providing the ability to use JSON SCHEMAS as
> well, hopefully we will have this in PHP in 8.4 (this will be a
> shock!)
>
> Question ... are you planning to incorporate this by enhancing
> json_validate() ???
>
> El mié, 1 mar 2023 a las 9:07, Jakub Zelenka () escribió:
> >
> > On Wed, Mar 1, 2023 at 11:44 AM juan carlos morales <
> dev.juan.mora...@gmail.com> wrote:
> >>
> >> Hello Internals.
> >>
> >> I am thinking about improving the json_validate() function developed
> >> for php 8.3.
> >>
> >> The actual descriptions goes like this:
> >>
> >> json_validate(string $json, int $depth = 512, int $flags = 0): bool
> >>
> >> I am thinking about enhancing this function to also be able to
> >> validate against a JSON SCHEMA, giving us something like this:
> >>
> >> json_validate(string $json, int $depth = 512, int $flags = 0, string
> >> $json_schema = null): bool
> >>
> >> so, if the string is a valid JSON and also respects the schema ... then
> TRUE.
> >>
> >> What do you think ?
> >>
> >
> > I'm actually working on this. Currently developing the schema parsing in
> pure C implementation in my play C tool called jso. You can see progress
> here: https://github.com/bukka/jso/commits/next . The plan is to develop
> it inside jso and then port it to jsond and then propose it for json ext
> inclusion (that's how I developed the current parser). There is a lot of to
> do as JsonSchema is quite complex (composition, JSON pointers, stream
> integration for external pointers and more tricky bits) so this won't
> likely be ready for 8.3 but should be ready for 8.4. I plan to introduce
> some smaller things for 8.3 like better error reporting (error location
> which I have already working in jso) and some other small additions. By the
> way, the schema support won't be useful just for validation but also for
> decoding and possibly encoding (sort of replacement for JsonSerializable).
> Especially for decoding it can be further extended to allow class mapping.
> We could also provide automatic generation of schema from class and support
> attributes. I plan to propose all of this later as well but that might take
> some time.
> >
> > Regards
> >
> > Jakub
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Great addition folks, looking forward to it!

If there is anything that I can do to help, please let me know!

-- 
Atenciosamente,

Flávio Heleno

Re: [PHP-DEV] Official Preprocessor

[Flávio Heleno]

On Fri, Feb 3, 2023 at 6:19 AM Olle Härstedt  wrote:

> 2023-02-02 15:19 GMT+01:00, someniatko :
> > Hi Internals
> >
> > The main gist:
> > --
> >
> > I suggest to introduce an official type-checker / static analyser /
> > preprocessor / transpiler for PHP, somewhat similar to TypeScript in
> > the JavaScript world, which will allow to introduce the features
> > otherwise impossible for the PHP world, at the cost of including an
> > additional transpilation step.
> >
> > The reasoning:
> > --
> >
> > You all know there are a lot of problems with the language, especially
> > large gaps with the current type system, which have large community
> > demand to overcome, but still cannot be solved due to the paradigm
> > chosen by PHP. And the paradigm is to be statically typed (to some
> > extent), but dynamically checked language, which limits the number of
> > available options due to performance reasons.
> >
> > The introduction of static types have gradually eliminated the need of
> > using external means of communicating the types (phpdoc @param and
> > @return annotations), replacing them with native language constructs,
> > making the language more expressive and enterprise-ready. However,
> > there are a lot of things still missing, like types of arrays,
> > including lists, hash-maps and structure-like arrays, and of course
> > generic classes and functions. These are still covered nowadays with
> > external means like phpdoc annotations and static analysers / type
> > checkers to validate them. This leaves PHP in the odd mixture of
> > native types and externally validated annotations via comments.
> >
> > Paradigm of a dynamically checked language also leaves out the problem
> > of type-checking before running the code. Even though the types are
> > defined statically, you still have to physically run the code, with
> > all possible execution paths, to catch a type error. To avoid that you
> > still would have to use an external typechecker / static analyser,
> > even if PHP could cover 100% of type demand natively.
> >
> > Python solves this problem nicely I think. It is dynamically typed,
> > but it allows a special syntax for static types and also has a
> > separate static type checker. I think this is really a good approach
> > and it would be great if PHP followed this path for the beginning, but
> > we have what we have already.
> >
> > There were attempts to create preprocessors for PHP (like PHP++ IIRC),
> > which allowed features like generics, but they did not gain enough
> > popularity, weren't baked by large enough companies, didn't make their
> > way to major IDEs support. I believe the only solution is to make an
> > official one.
> >
> > Therefore, I suggest the following thing:
> > 1. Introduce a new #declare directive which will mark the file as
> > requiring pre-processing.
> > 2. Let PHP introduce special features that only work in such
> > "pre-processing required" files, such as typed lists and generics.
> > 3. Implement a static type-checker in PHP that will verify those typed
> > lists and generics are indeed used in a valid way.
>
> No need to waste resources implementing a new one when we already have
> two very competent already: Psalm and Phpstan? Or why is those not
> enough for your use-case?
>
> "The greatest enemy to a perfect solution is a good enough solution
> already in place." ;)
>
> Olle
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Why not follow the steps of other projects that have been created
independently from the core and,
at some point, gained enough support/traction that were incorporated into
it?

Re: [PHP-DEV] [RFC] [Discussion] Typed class constants

[Flávio Heleno]

On Fri, Feb 3, 2023 at 11:34 AM Máté Kocsis  wrote:

> Hi Alexandru, Mark,
>
>
> > 1. Why is object type not supported? I can't see a real reason and also
> > there is no explanation why.
> >
>
> Sorry for this, mentioning object as unsupported was an artifact from the
> original version of the RFC which
> was created back then when constants couldn't be objects. After your
> comments, I removed the object type
> from the list. Thank you for catching this issue!
>
>
> > 2. In the examples for illegal values, it would be good to explain why
> > they are not legal.
> >   I don't understand why "public const ?Foo M = null;" wouldn't be legal.
> >   I think "?Foo" should work the same as "Foo|null" that would be legal.
> >
> > It was there due to the same reason as above. I removed this example now.
>
> I had updated the RFC page, but it looks like the changes were reverted in
> > December 2022. The updated version I was working on was:
> > https://wiki.php.net/rfc/typed_class_constants?rev=1648644637
>
>
> Yeah, the original author of the RFC was surprised to find your changes in
> his RFC (https://github.com/php/php-src/pull/5815#issuecomment-1356049048
> ),
> so he restored his original version.
> Next time, please either consult with the author of an RFC if you intend to
> modify the wording, or you can simply create a brand new RFC - even if it's
> very similar to the original one (just don't
> forget to add proper references).
>
> The updated RFC looks good, thanks for working on it. You may want to
> > review the revised version I had worked on for implementation ideas, and
> > review the previous conversations.
> >
>
> I also saw your proposal, but to be honest, I'm not that fond of the idea.
> This doesn't mean though that you shouldn't create a new RFC or an
> implementation, as others may find it useful. If you kick off
> the project, I'll surely try to review your work.
>
> Regards,
> Máté Kocsis
>

Typed constants is a great addition, thanks Máté!

Re: [PHP-DEV] RFC: rules for #include directives

[Flávio Heleno]

On Wed, Jan 18, 2023 at 4:17 PM Tim Düsterhus  wrote:

> Hi
>
> On 1/18/23 18:51, Kamil Tekiela wrote:
> > As you said yourself, this refactoring has no practical effect on
>
> It has no practical effect *yet*. The headers need to be untangled first
> before actual optimization can happen.
> > Or maybe have all
> > ZEND headers included with a single header?
>
> That would go against the goal of reducing compile times. Much of the
> time spent when compiling C is parsing megabytes of source code, because
> deeply nested and/or unnecessary includes will bloat the amount of code
> the toolchain will need to go through.
>
> Let me give a simple example:
>
> We have the following headers:
>
> a.h: 1 MB.
> b.h: Includes a.h and is itself 100 kB in size.
> c.h: Includes a.h and is itself 100 kB in size.
>
> foo.c: Includes b.h and c.h, but c.h is not actually used. Is itself 300
> kB in size.
>
> Now when compiling foo.c, a total of 2.5 MB of source code need to be
> parsed, because a.h is included twice. If the unused include for c.h is
> removed, then it will only be 1.4 MB in total. This multiplies quickly
> for more complex include chains. I'd like to point to this commit once
> more:
>
>
> https://github.com/haproxy/haproxy/commit/340ef2502eae2a37781e460d3590982c0e437fbd
>
> Removing two headers in a single file reduced the total compile by
> roughly 10%!
>
> Here's two more similar commits:
>
>
> https://github.com/haproxy/haproxy/commit/e5983ffb3adbf71a8f286094b1c1afce6061d1f3
>
> https://github.com/haproxy/haproxy/commit/1db546eecd3982ffc1ea92c2f542a3b01ce43137
>
> Best regards
> Tim Düsterhus
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Tim,

This may be a silly question, but in that case, wouldn't #ifdef guards keep
the compiler from including/parsing a.h twice?

When a.h is *not* required by any of b.h, c.h nor foo.c, I agree that it
should *not* be included at all, but when any of them,
or even if all of them requires it, the guards should be enough to avoid
redundant work afaik.

Or am I missing anything here?

Re: [PHP-DEV] [RFC][Dynamic class constant fetch]

[Flávio Heleno]

On Fri, Nov 4, 2022 at 12:08 PM someniatko  wrote:

> > What's convenient about `Foo::{$bar}` vs `constant(Foo::class . '::' .
> > $bar)`? I'm a bit confused by this :|
> >
> > Is it the few keystrokes added?
>
> Even if ignoring syntax / convenience bikeshedding, I find it a really
> valuable addition to the language self-consistency. It's symmetrical
> to the already existing syntax of dynamic property fetch and dynamic
> method calls. One could argue that it's dynamic, too much magic and
> bad, but then we should either deprecate those features, or if not,
> have this symmetry. The Principle of Least Amusement and human pattern
> recognition overall with thank you.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
I agree with @someniatko, it makes PHP more consistent, which IMHO
is always positive and one of the usually criticized points (lack of
consistency
throughout parameter order, naming convention etc).

Re: [PHP-DEV] Experimental features

[Flávio Heleno]

On Wed, Oct 5, 2022 at 8:16 AM Deleu  wrote:

> On Wed, Oct 5, 2022, 7:54 AM juan carlos morales <
> dev.juan.mora...@gmail.com>
> wrote:
>
> >
> > Apply a PECL strategy to try experimental features might not be the
> > convenient way always, for example, if we create a new ... sensitive
> > ... ini setting that affects the behavior of PHP somehow, then ...
> > maybe applying the PECL strategy might not be the most confortable way
> > to approach it, OR ... what about a new sensitive funtion in a "core
> > extension" like JSON?
> >
>
> Just to build up on this. I feel like Extensions are maybe a technical /
> development feature that may have the power to address the issue, but from
> a "Product" (PHP language as the product) this isn't the best. Anything
> behind extensions add a significant entry burden and reduce the reach for
> users of the product, be it for lack of trust, knowledge or lack of
> infrastructure that allows such changes.
>
> >
>

Deleu & Juan,

Thanks for clearing this up!

A product approach could be something interesting to explore. I'm more than
happy to join and help anyway I can.

-- 
Atenciosamente,

Flávio Heleno

Re: [PHP-DEV] Experimental features

[Flávio Heleno]

On Tue, Oct 4, 2022, 17:43 David Rodrigues  wrote:

> I wanted to suggest the possibility of introducing experimental features to
> PHP.
>
> This is an old thread I guess, but I think it's good to reevaluate the
> situation from time to time, as other languages already do this to some
> extent and PHP doesn't. Some platforms/languages (Node, Kotlin) and
> libraries (React) bring features natively in an experimental way.
>
> I wanted to propose that we bring this idea into PHP, so we wouldn't have
> to wait for new major/minor versions (eg. 9.0 or 8.2, 8.3) to try out these
> new features, and so when these versions arrive, they'll already be quite
> polished, avoiding patches sometime later due to wider usage of users.
>
> My idea is to have two levels of experimental features:
>
> (1) Via declare(), when the feature affects how PHP can act when reading
> the file itself. Eg. declare(experimental_operator_override =
> true), Something that happens with Kotlin, for example, when we use some
> experimental annotations like contracts. These declarations work "per
> file", so whenever it is necessary to use it, it must be declared.
>
> (2) Via experimental identifier name. Eg. experimental_json_validate() or
> Experimental::json_validate(), like in Kotlin and also in React.
>
> Experimental features can only be brought into a minor version (eg. PHP
> 8.1.12) when it is minimally refined and practically ready to use. It would
> be "kind of" an expected final version, no new patches are expected (we
> hope), unless something really went unnoticed.
>
> Despite this, experimental features may not exist until the next
> major/minor release if its practical inefficiency is found or if the
> concept is shown to be invalid. So it should always be a "use with care".
>
> However, if an experimental feature is successful, it becomes final at the
> next major/minor or major/minor+1. The experimental version becomes an
> alias during some future versions until it is removed entirely. This is the
> time for users to adapt their code and for IDEs to help us find them.
>
> With this, we can understand whether users are making use of a certain
> feature or not, make improvements on it, etc.
>
> I notice that many good features are rejected because they are believed to
> be bad for PHP or can be confusing, but without any practical testing.
> Experimental features can make this analysis more grounded in practical
> data than just possibilities.
>
> However, this also doesn't mean that any idea can become an experimental
> feature, but ideas that have a good foundation and a good discussion before
> it. The difference is that the feature can be tested in practice before
> being totally rejected, and approved features can be delivered ahead of
> time to refine before the next version is released, allowing users to try
> them out more easily.
>
>
> Atenciosamente,
> David Rodrigues
>

Hi David,

Could this be done through extensions instead of having to develop a new
process/support code?

When json support was first introduced into php, it was done as an
extension and then, after a while, incorporated into the core.

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

[Flávio Heleno]

On Thu, Dec 9, 2021, 18:56 Christoph M. Becker  wrote:

> On 09.12.2021 at 20:59, Flávio Heleno wrote:
>
> > On Thu, Dec 9, 2021 at 4:46 PM Nikita Popov 
> wrote:
> >
> >> On Wed, Dec 8, 2021 at 12:41 PM Christoph M. Becker 
> >> wrote:
> >>
> >>> On 01.12.2021 at 00:52, Ben Morss via internals wrote:
> >>>
> >>>> Earlier this year, I added support for AVIF images
> >>>> <https://github.com/libgd/libgd/pull/671> to libgd
> >>>> <https://github.com/libgd/libgd>. My ultimate goal was to bring
> >> support
> >>> for
> >>>> this new image format to PHP, so that the world's top CMSs could let
> >>> sites
> >>>> serve AVIFs. A few of you kindly guided me as I made my first
> >>> contributions
> >>>> to the PHP codebase, propagating libgd's new AVIF support
> >>>> <https://github.com/php/php-src/pull/7026> into PHP's bundled gd
> fork,
> >>>> and adding
> >>>> AVIF awareness <https://github.com/php/php-src/pull/7091> to non-gd
> >>>> functions like getimagesize() and imagecreatefromstring().
> >>>>
> >>>> Unfortunately, when I worked on getimagesize(), AVIF experts advised
> >> that
> >>>> there was no compact, reliable way to determine the size of an AVIF
> >> image
> >>>> without relying on an external library like libavif. We decided
> >>>> <https://github.com/php/php-src/pull/5127#issuecomment-799825277>
> that
> >>> it
> >>>> was useful to return the information that a given image was an AVIF,
> >> but
> >>>> simply to return 0 for the actual dimensions and other details. The
> >> user
> >>>> would simply need to decode the image to determine this information.
> >>>>
> >>>> Of course, users would really like
> >>>> <https://github.com/php/php-src/pull/5127#issuecomment-976241397> to
> >> use
> >>>> getimagesize() to return the actual size. So a colleague has kindly
> >>>> created standalone
> >>>> code <https://aomedia-review.googlesource.com/c/libavifinfo/+/148321>
> >>> (that
> >>>> doesn't depend on libavif) to do this, with the goal of adding it to
> >> PHP.
> >>>>
> >>>> The code comprises several hundred lines. But - it works, and it works
> >>> well.
> >>>>
> >>>> Would it be ok to submit a PR containing this code to add this
> >>>> functionality? Or does someone have a superior approach?
> >>>
> >>> 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>
> >>>
> >>
> >> Assuming no licensing concerns, bundling libavifinfo sounds reasonable.
> The
> >> library is small, our avif functionality is incomplete without it, and
> we
> >> can't expect this to be available as a system library at this time.
> >> Although I'm not a core contributor, my 2c is that even with libavifinfo
> > bundled, a configuration option is
> > very welcome, the same way we have for png, jpeg, xpm and webp.
>
> Whether AVIF support should be included for ext/gd is already
> configurable.  This is solely about the getimagesize(fromstring) and
> image_type_to_* functions which are part of ext/std.  We do not have
> configuration options for these for the other image formats either.
>
> --
> Christoph M. Becker
>

Got it! I was refering to the general avif support, glad to see that it's
already there =)

>

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

[Flávio Heleno]

On Thu, Dec 9, 2021 at 4:46 PM Nikita Popov  wrote:

> On Wed, Dec 8, 2021 at 12:41 PM Christoph M. Becker 
> wrote:
>
> > On 01.12.2021 at 00:52, Ben Morss via internals wrote:
> >
> > > Earlier this year, I added support for AVIF images
> > > <https://github.com/libgd/libgd/pull/671> to libgd
> > > <https://github.com/libgd/libgd>. My ultimate goal was to bring
> support
> > for
> > > this new image format to PHP, so that the world's top CMSs could let
> > sites
> > > serve AVIFs. A few of you kindly guided me as I made my first
> > contributions
> > > to the PHP codebase, propagating libgd's new AVIF support
> > > <https://github.com/php/php-src/pull/7026> into PHP's bundled gd fork,
> > > and adding
> > > AVIF awareness <https://github.com/php/php-src/pull/7091> to non-gd
> > > functions like getimagesize() and imagecreatefromstring().
> > >
> > > Unfortunately, when I worked on getimagesize(), AVIF experts advised
> that
> > > there was no compact, reliable way to determine the size of an AVIF
> image
> > > without relying on an external library like libavif. We decided
> > > <https://github.com/php/php-src/pull/5127#issuecomment-799825277> that
> > it
> > > was useful to return the information that a given image was an AVIF,
> but
> > > simply to return 0 for the actual dimensions and other details. The
> user
> > > would simply need to decode the image to determine this information.
> > >
> > > Of course, users would really like
> > > <https://github.com/php/php-src/pull/5127#issuecomment-976241397> to
> use
> > > getimagesize() to return the actual size. So a colleague has kindly
> > > created standalone
> > > code <https://aomedia-review.googlesource.com/c/libavifinfo/+/148321>
> > (that
> > > doesn't depend on libavif) to do this, with the goal of adding it to
> PHP.
> > >
> > > The code comprises several hundred lines. But - it works, and it works
> > well.
> > >
> > > Would it be ok to submit a PR containing this code to add this
> > > functionality? Or does someone have a superior approach?
> >
> > 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>
> >
>
> Assuming no licensing concerns, bundling libavifinfo sounds reasonable. The
> library is small, our avif functionality is incomplete without it, and we
> can't expect this to be available as a system library at this time.
>
> Regards,
> Nikita
>

Although I'm not a core contributor, my 2c is that even with libavifinfo
bundled, a configuration option is
very welcome, the same way we have for png, jpeg, xpm and webp.

As *cmb* said, thanks for your and your colleague's work!

-- 
Atenciosamente,

Flávio Heleno

Re: [PHP-DEV] [RFC] $this return type

[Flávio Heleno]

On Tue, Sep 7, 2021 at 10:27 AM Sebastian Bergmann 
wrote:

> Am 07.09.2021 um 12:28 schrieb Nikita Popov:
> > I have some reservations about this (which basically come down to $this
> not
> > being a proper "type", so should it be in the type system?) but I can see
> > the practical usefulness, so I think it's worth discussing this.
>
> I am not conviced that there is enough value in this to introduce syntax
> for it, but if at all, then please not "$this" as the name for a type.
>
> Off the top of my head, I think that "same" could make sense.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Hi all,

I'm sorry if I'm being naive, or simply put dumb, but the main difference
that we're trying
to achieve with having "$this" (or variations of it) as a valid return type
as opposed to simply
using "self" is to ensure that the underlying code is actually doing a
"return $this" rather
than returning any other valid "self" instance (such as "return new
self();")?

-- 
Atenciosamente,

Flávio Heleno

Re: [PHP-DEV] [RFC] Deprecate partially supported callables

[Flávio Heleno]

On Thu, Sep 2, 2021 at 12:46 PM Nikita Popov  wrote:

> On Thu, Sep 2, 2021 at 5:06 PM Côme Chilliet <
> come.chill...@fusiondirectory.org> wrote:
>
> > Le Thu, 2 Sep 2021 16:32:32 +0200,
> > Nikita Popov  a écrit :
> >
> > > Hi internals,
> > >
> > > Currently, there are some callables that are accepted by the "callable"
> > > type, but which cannot be used with $callable() syntax. This RFC
> proposes
> > > to deprecate support for such "callables":
> > >
> > > https://wiki.php.net/rfc/deprecate_partially_supported_callables
> >
> > It took me some time to understand that this was not a proposal to remove
> >  support for all array/string representation of callables.
> > This should be made clearer if possible, maybe even list the callable
> kinds
> >  which will not be deprecated.
> >
>
> Yeah, I definitely have no intention of deprecating string/array callables
> in general. If something works in $callable(), then it's going to continue
> working. Added the following note:
>
> > Normal "function", "Foo::method", ["Foo", "method"] and [new Foo,
> "method"] style callables are unaffected by this change.
>
> Regards,
> Nikita
>

With this, PHP walks another step towards a much needed cleanup.

>From me this is a more than welcome change.

-- 
Atenciosamente,

Flávio Heleno

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

[Flávio Heleno]

On Wed, Aug 25, 2021 at 7:46 AM Rowan Tommins 
wrote:

> On 25/08/2021 11:02, Nikita Popov wrote:
> > I'd like to propose the deprecation of "dynamic properties", that is
> > properties that have not been declared in the class (stdClass and
> > __get/__set excluded, of course):
> >
> > https://wiki.php.net/rfc/deprecate_dynamic_properties
>
>
> This is a bold move, and in principle seems sensible, although I'm
> slightly scared how many places will need fixing in legacy code bases.
>
> I have a couple of concerns with using stdClass as the opt-in mechanism:
>
> * The name of that class already leads to a lot of confusion about its
> purpose - it's not actually "standard" in any way, and new users seeing
> it as a base class are even more likely to mistake it as some kind of
> "universal ancestor". Would it be feasible to introduce an alias like
> "DynamicObject" which more clearly defines its role?
>
> * Adding a parent to an existing class isn't always possible, if it
> already inherits from something else. Perhaps the behaviour could also
> be available as a trait, which defined stub __get and __set methods,
> allowing for the replacement of the internal implementation as you've
> described?
>
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Although not having voting karma, I'm +1 on this.

I've always preferred explicit over implicit code as it makes the learning
path to newcomers a lot easier to grasp.

When we talk about legacy code, more frequently than not is that legacy
code is unlikely to run on the latest version of PHP,
thus I'm not entirely sure if that's a super strong argument against it,
but I may be missing something.

-- 
Atenciosamente,

Flávio Heleno

Re: [PHP-DEV] Unwrap reference after foreach

[Flávio Heleno]

On Fri, Aug 13, 2021 at 11:20 AM Claude Pache 
wrote:

>
> > Le 13 août 2021 à 15:28, Nikita Popov  a écrit :
> >
> > Hi internals,
> >
> > I'd like to address a common footgun when using foreach by reference:
> > https://wiki.php.net/rfc/foreach_unwrap_ref
> >
> > This addresses the issue described in the big red box at
> > https://www.php.net/manual/en/control-structures.foreach.php. While
> this is
> > "not a bug" (as our bug tracker can regularly attest), it's rather
> > unexpected, and we could easily avoid it...
> >
> > Regards,
> > Nikita
>
>
> Hi,
>
> I don’t like the split of semantics between simple and complex variables.
> It makes the language more inconsistent, therefore more difficult to reason
> about.
>
> On the other hand, using a complex variable as reference in that context
> should be very rare outside obfuscation code contests.
>
> Therefore, I suggest to deprecate (and later remove) the ability to use of
> a complex variable as reference in that context. That would solve the
> inconsistency issue.
>
> —Claude
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Hi,

I know I don't have an actual vote (voting karma it is), but it's a +1 from
me as well.

I like Trevor's suggestion of scoping variables within loops and this would
be a first step towards it.