On Wed, Jun 11, 2025, at 08:31, Dmitry Derepko wrote:
> I see.
>
> The first thought is about extending the class definition: along with
> functions hashtable we would add virtual functions HT and lookup for the
> function will be another HT lookup.
>
> image.png
>
> That for sure is better than trap for cpu, but enlarge memory usage at the
> moment.
>
>
> ---
>
> Moreover, it allows us to keep both static and dynamic functions.
>
> function class::func(){} // static extension class:func()
> function class->func(){} // dynamic function $class->func()
>
>
>
> ---
>
> this functions can be found dynamically and it seems alright:
>
> // a.php
> use Models\User;
>
> function User::getName(){}
>
> // new User->getName is available here
>
> // b.php
>
> use Models\User;
>
> // new User->getName is NOT available here, because a.php wasn't loaded and
> here User::getName isn't available
>
> // c.php
>
> namespace Stuff;
>
> include 'a.php';
>
> // new User->getName here you can do it, because a.php was loaded and
> functions table was adjusted with getName function
>
> // d.php
>
> use Stuff\Smth;
> use Tools\Smth2;
>
> // if it's an app entrypoint
> // autoloader loads c.php because of Smth file is found there
> // c.php loads a.php
> // the extension function User::getName is also available here
>
> // either is this file an entrypoint or not
> // it stores the extension function in the class definition
> // so Smth2 now can use the extension function, because it was loaded "by
> parent"
>
> > Very much not. The `use` construct has no bearing on autoloading
> > currently. Autoloading happens only for classes and class-like things
> > (interfaces, traits, enums). If a function is not found, PHP just crashes.
> > Various solutions to this have been discussed over the years, none of
> > which ever made it as far as a vote.
>
> Is this covered by the texts above?
>
> > In fairness, I think with universal opcache, preloading, and the increasing
> > use of persistent processes, just skipping autoloading for functions and
> > front-loading them via composer.json's "files" block is fine for the 80%
> > case. But it feels like I am in the minority on that position.
>
> That's what we have now. Can't see any problems.
>
>
> On Tue, Jun 10, 2025 at 11:11 PM Larry Garfield <[email protected]>
> wrote:
>> On Tue, Jun 10, 2025, at 2:45 PM, Dmitry Derepko wrote:
>> > Thanks for participating, Larry.
>> >
>> > On Mon, Jun 9, 2025 at 10:29 PM Larry Garfield <[email protected]>
>> > wrote:
>> >> 2. Please link to a PR of your actual implementation. In context it
>> >> looks like your branch comparison link is to the version you said didn't
>> >> work, so it's not that helpful.
>> >
>> > Correct, I don't have another one. This is big feature, I need a lot of
>> > time to implement it. I don't want to waste my time if we decide that
>> > RFC won't pass at all.
>>
>> Understood.
>>
>> >> 3. The biggest question that has come up in the past (Ilija and I have
>> >> discussed it at length) is, naturally, autoloading. How if at all do you
>> >> address that?
>> >
>> > In the original message I mentioned `use extension` construction. This
>> > should be enough for solution, isn't it?
>>
>> Very much not. The `use` construct has no bearing on autoloading currently.
>> Autoloading happens only for classes and class-like things (interfaces,
>> traits, enums). If a function is not found, PHP just crashes. Various
>> solutions to this have been discussed over the years, none of which ever
>> made it as far as a vote.
>>
>> I toyed with the idea of having extension functions compile to a static
>> method on a class as a way around this, but of course then you end up with a
>> file-per-function, and the file name has to match not the function name, but
>> whatever mangled class name gets generated. Not at all intuitive.
>>
>> In fairness, I think with universal opcache, preloading, and the increasing
>> use of persistent processes, just skipping autoloading for functions and
>> front-loading them via composer.json's "files" block is fine for the 80%
>> case. But it feels like I am in the minority on that position.
>>
>> >> 4. The other big question was determining when to match a given "method"
>> >> call to an extension function, when the type of a variable is not always
>> >> known at compile time. How did you address this?
>> >
>> > Cannot understand the passage, could you explain more?
>>
>> <?php
>> // index.php
>>
>> function Point.area(): int {
>> return $this->x & $this->y;
>> }
>>
>> function doStuff($p) {
>> // At compile time, we don't know that $p is a Point. In fact, it may not
>> be.
>> // The function will allow any value here, even a non-object, so it
>> doesn't know
>> // if this should be compiled to Point__area($p) or left as is.
>> print $p->area();
>> }
>>
>> The only way I could think of to handle that is to have a method call "trap"
>> similar to class autoloading, that when hit checks at runtime "hey, this
>> method didn't exist, but is there a `use`d function that would match based
>> on the runtime type of this value?" But Ilija felt that would be
>> prohibitively slow. It would certainly be slower than just a
>> function/method call since the trap takes time.
>>
>> And then we get into questions of inheritance, and, well, it gets even
>> messier fast.
>>
>> One possibility that we riffed on during the pipes discussion (mostly off
>> list, I think) was using +> for some combination of extension functions and
>> Elixir-style first-arg pipe passing, so that $p+>area() would signal to the
>> engine (compile time or runtime) that area() wasn't a method but a function
>> that should get $p passed to it. That would solve the "trap" problem, but
>> still doesn't address autoloading, the lack of compile time type knowledge,
>> or how to differentiate between Point.area(), ShapeInterface.area(),
>> Rect.area(), etc.
>>
>> --Larry Garfield
>
>
> --
> Best regards,
> Dmitrii Derepko.
> @xepozz
How does it handle late binding? (This is when a class extends/implements a
class that doesn’t exist yet; so the compiler postpones actually creating the
class until runtime when it can run the autoloader, if needed) should these
functions also late bind in that case?
— Rob
