Re: [PHP-DEV] Empower Callables with Function Signature Hints

[Saif Eddin Gmati]

Hello Hamza,

I think this is something that has been discussed here before.

function types already exist in HackLang: 
https://docs.hhvm.com/hack/functions/introduction#function-types,

And, if we would follow the same syntax `(function(T, T): T)` or `(callable(T, 
T): T)`, PHP needs to first support parentheses in
type declaration ( grouping ), which currently it doesn't ( i.e: `function 
baz((string|bar) $foo): void {}` becomes valid ).

And just to note, function types are also supported by static analysis tools 
such as Psalm ( 
https://psalm.dev/docs/annotating_code/type_syntax/callable_types/ ) and 
PHPStan ( https://phpstan.org/writing-php-code/phpdoc-types#callables ), so i 
suppose if PHP is to support typed callables, it should take inspiration from 
these tools.

There's also an alternative syntax that was proposed back in 2016 for PHP 7.1, 
but it seems like the RFC was abandoned: 
https://wiki.php.net/rfc/typesafe-callable

Cheers,

Saif.

‐‐‐ Original Message ‐‐‐
On Wednesday, April 7, 2021 11:58 AM, Hamza Ahmad  
wrote:

> Hello Internals,
> I want to request making possible to catch functions with wrong signature
> when passed as callable. In other words, when a function or a method is
> passed as callable value, PHP will first confirm whether the function is of
> the write callable type that the function being executed requires. It will
> help catch silent errors.
> Currently, PHP does following:
> 

> 1.  Confirms whether a callable is valid.
> 2.  Passes the callable value to a function, and the execution starts.
> 3.  If the passed function receives values which's type is different than
> function signature, PHP throws an error.
> 

> 4.  If passed function returns nothing, the variable that wanted a value from
> the passed function receives null.
> 

> 5.  As a result, the unexpected results emerge.
> To resolve this issue, I propose to introduce a mechanism that allows to
> hint callable signatures. To understand the spirit of this request, look 
> at
> the similar functionality that Angel Script Project provides with.
> 

> 6.  One defines a function definition.
> 7.  Use its name to hint the same signature.
> 8.  The compiler alerts about the incorrect signature before passing this to
> a function.
> If I could do this in PHP, I would write like following:
> `funcdef preg_replace_callback_hint(array $matches) : string;`
> If I accidently pass a callable which's signature is different than 
> desired
> function call, the error is caught earlier.
> This message does not suggests syntax; it only points to a problem and
> suggests a solution. Any volunteers that would love to come up with syntax
> and implement this?
> I am curious to see the feedback.
> Regards
> Hamza Ahmad
> 

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



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] [Discussion] Adding return types to internal methods

[Nicolas Grekas]

> For userland, there are already ways to declare the planned return type
>> (aka @return in phpdoc), so we might not need any new way to declare this
>> from the engine pov.
>>
>
> Yes, I think I agree, but I'd be curious about Nikita's opinion as well,
> since he brought up this problem first.
>
>
>> We should replace the SuppressReturnTypeNotice by the TentativeReturnType
>> one right away.
>
> The TentativeReturnType would mean: "I'm going to add a return type to
>> this method in its next major".
>> As a consequence, for child classes of internal methods, this would
>> suppress the notice.
>>
>
> If we get rid of the userland part of my proposal, then I think we can
> really rename SuppressReturnTypeNotice
> to TentativeReturnType.
>

This would mean that the RFC could describe how userland (code analyzers)
should understand the TentativeReturnType when encountering one, without
asking anything from the engine when base userland classes are extended.
For internal classes, the attribute would just mean what you wrote already.
That'd be fine to me.


> As a corollary, adding this attribute should conflict with having a real
>> return type.
>
>
> This is the only questionable part for me, because then this RFC would
> cause more trouble for overriding methods
> which already define a wrong return type: a deprecation notice would
> always be triggered for them on PHP 8.1+
> until return types are fixed or removed. And as we discussed it
> previously, fixing them is not always possible.
> Or is there any specific reason I'm not aware of why you favor this
> behavior?
>

To me, overriding methods that define a wrong return type should remove
their return type as a fix, and replace it with the attribute. Removing a
return type is allowed by LSP, so this should be just fine.

Nicolas

[PHP-DEV] Re: Update on git.php.net incident

[Jan Ehrhardt]

Nikita Popov in php.internals (Tue, 6 Apr 2021 20:28:03 +0200):
>Something I was not aware of at the time is that git.php.net
>(intentionally) supported pushing changes not only via SSH (using the
>gitolite infrastructure and public key cryptography), but also via HTTPS.
>The latter did not use gitolite, and instead used git-http-backend behind
>Apache2 Digest authentication against the master.php.net user database. I'm
>not sure why password-based authentication was supported in the first
>place, as it is much less secure than pubkey authentication.

Password-based authentication on Github is deprecated for some time now
and will be disabled on August 13, 2021. See the timeline in
https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/
-- 
Jan

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

[PHP-DEV] Main.php.net redirection error

[Mail]

main.php.net  ( formerly master.php.net 
 ) redirects me to php.net . Is this 
correct behavior?

[PHP-DEV] Re: timelib inefficiency

[Dmitry Stogov]

Hi Derick,

I saw you have landed the recent updates of timelib to PHP master.
There are few ongoing improvements:

https://github.com/derickr/timelib/pull/103 - an obvious code motion, that
avoid useless "year" calculation

https://github.com/derickr/timelib/pull/104 - an adoption of my old idea,
that prevents unnecessary 64-bit divisions, to new code-base

https://github.com/derickr/timelib/pull/99 - this is the old and the most
important one. It makes **170 times** speed-up on each very usual
timelib_parse_zone() call. The real problem is in timelib_lookup_abbr().
Actually the algorithm of timelib_lookup_abbr() is highly inefficient and
most probably improper, but this simple check just eliminates the need for
the call to timelib_lookup_abbr() for many usual cases. Just this patch
makes more than 3% improvement on the Symfony Demo app (that is not just a
"hello world").

I hope the landing of these improvements won't take another month.

Thanks. Dmitry,

On Thu, Mar 4, 2021 at 4:13 PM Dmitry Stogov  wrote:

> hi,
>
> On Thu, Mar 4, 2021 at 3:30 PM Derick Rethans  wrote:
>
>> Hi,
>>
>> I saw the PRs coming in, I'll reply inline:
>>
>> On Thu, 4 Mar 2021, Dmitry Stogov wrote:
>>
>> >
>> https://github.com/php/php-src/commit/b4e9b1846376f562e27a13572a137ec584c13f58
>>
>> As Nikita already commented, this now seems to introduce flakeyness into
>> tests.
>>
>> > And created 3 pull request for timelib:
>> >
>> > https://github.com/derickr/timelib/pull/98
>>
>> That looks reasonable. I'm currently working on implementing
>> https://github.com/derickr/timelib/issues/14 which will also touch that
>> code, so I'll look at it as part of that work.
>>
>> > https://github.com/derickr/timelib/pull/99
>>
>> Is incorrect, the tzfile 5 man page says:
>>
>> Time zone designations should consist of at least three (3) and
>> no more
>> than six (6) ASCII characters from the set of alphanumerics
>>
>
> timelib (timezonedb.h and fallbackmap.h) doesn't have abbreviation longer
> than 5 characters, but has single char abbreviations.
>
>
>>
>> I am curious to as to why this routine was called so often though, as
>> looking for abbreviations isn't something that should have be be done
>> often.
>>
>
> Every time you parse a time zone name (including a date with timezone) you
> always (except for UTS and GMT) perform a linear search through all entries
> listed in timezonedb.h (1128 string comparisons + 1128*2 lowercasing +
> 1128*2 calls to strlen()), and only then take a look for timezone name,
> that may be already cached.
>
>
>>
>> > https://github.com/derickr/timelib/pull/100
>>
>> This new routine is perhaps faster, but it is also extremely more
>> complex, with little comments. It's unlikely I would want to incorporate
>> it in its current form.
>>
>
> What comments do you like?
> We first guess the year dividing days to 365, then check if our guess is
> right (number of days from the start of the guessed year fits into this
> year), and then continue searching.
> This is like a binary search, but with base 365 and the rule to check the
> leap year.
>
>
>> > Please, verify and merge the timelib patches into PHP.
>> > Please, let me know if this will take time.
>>
>> It will certainly take time :-)
>>
>> > I fixed only the visible, most significant and obvious bottlenecks.
>> > It's possible to improve timelib more...
>>
>> I'm sure it is! The code is 17 years old by now!
>>
>
> yeah, this is the problem. Nobody likes to improve it. I'm interested only
> because it significantly affects PHP performance.
>
> Thanks. Dmitry.
>
>
>>
>> cheers,
>> Derick
>>
>

[PHP-DEV] Empower Callables with Function Signature Hints

[Hamza Ahmad]

Hello Internals,
I want to request making possible to catch functions with wrong signature
when passed as callable. In other words, when a function or a method is
passed as callable value, PHP will first confirm whether the function is of
the write callable type that the function being executed requires. It will
help catch silent errors.
Currently, PHP does following:
1. Confirms whether a callable is valid.
2. Passes the callable value to a function, and the execution starts.
3. If the passed function receives values which's type is different than
function signature, PHP throws an error.
4. If passed function returns nothing, the variable that wanted a value from
the passed function receives null.
5. As a result, the unexpected results emerge.
To resolve this issue, I propose to introduce a mechanism that allows to
hint callable signatures. To understand the spirit of this request, look at
the similar functionality that Angel Script Project provides with.
1. One defines a function definition.
2. Use its name to hint the same signature.
3. The compiler alerts about the incorrect signature before passing this to
a function.
If I could do this in PHP, I would write like following:
`funcdef preg_replace_callback_hint(array $matches) : string;`
If I accidently pass a callable which's signature is different than desired
function call, the error is caught earlier.
This message does not suggests syntax; it only points to a problem and
suggests a solution. Any volunteers that would love to come up with syntax
and implement this?
I am curious to see the feedback.
Regards
Hamza Ahmad

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

Re: [PHP-DEV] Re: [RFC] Autoloader Classmap

[Jordi Boggiano]

Hi Mark,

On 06/04/2021 00:05, Mark Randall wrote:


* I expect 99.% of users will never know it exists, and it will 
instead just be an option for tools like composer that will provide a 
small transparent boost.


I wrote this as feedback in your early round (I don't think you 
answered), and IMO it still stands:


//

The proposed API should really support
multiple maps. Composer has a  prepend-autoloader option which controls
whether the generated autoloader will be prepended or appended when
spl_autoload_register is called. This is required in some cases where
multiple autoloaders coexist. So the ability to add multiple maps,
including optionally prepending them would be a must IMO. The ability to
remove an autoloader and its associated classmap would also be very
welcome so one can unregister things cleanly.

So taking the above in consideration, and keeping consistency with
existing spl_* functions in mind, I would propose an API more like:

    autoload_register_classmap(array $map, bool $prepend = false)
    autoload_unregister_classmap(array $map)

//

Given the current API proposal, I think I would vote no, because I do 
not know how I'd even implement this in Composer without making a mess 
in case multiple autoloaders co-exist (which one can not know about at 
autoload generation time). We'd have to perhaps set the classmap on the 
first autoloader, and if a second autoloader gets created it'd wipe the 
classmap entirely and skip the optimization for safety because it 
becomes unmanageable otherwise.



* It provides a very minor benefit to debugging as you get to skip 
over the autoloading frames which so very often come up during a request.


In development environment we do not recommend using an optimized 
autoloader as it slows down updates/installs and doesn't bring a ton of 
perf benefit, so this argument isn't that strong.


Best,
Jordi

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