Re: [PHP-DEV] [RFC][Draft] Sealed Classes

[Saif Eddin Gmati]

 On Sun, 25 Apr 2021 22:56:26 +0100 Chase Peeler  
wrote 

 > On Sun, Apr 25, 2021 at 11:36 AM Mike Schinkel  wrote: 
 >  
 > > 
 > > 
 > > > On Apr 24, 2021, at 7:39 PM, David Gebler  wrote: 
 > > > 
 > > > I don't love this idea, I'm not very fond of the final keyword, either; 
 > > 
 > > I'll start by saying the final keyword caused me a tremendous amount of 
 > > heartache because it was used on a class in a framework that I badly, 
 > > badly 
 > > needed to extend. 
 > > 
 > > But even so, I recognize why they used it, and I still don't have a great 
 > > argument for how they could address the reasons they used it some other 
 > > way. 
 > > 
 > > > I've always believed annotations (or attributes in PHP these days) are a 
 > > > better of way of indicating you, as an author of a class, did not write 
 > > it 
 > > > with inheritability in mind or intended than restricting language 
 > > features 
 > > > through syntactic constructs. 
 > > > 
 > > > The RFC says "when you have a class in your code base that shares some 
 > > > implementation detail between 2 or more other objects, your only 
 > > protection 
 > > > against others making use of this class is to add `@internal` 
 > > > annotation, 
 > > > which doesn't offer any runtime guarantee that no one is extending this 
 > > > object", to which I ask - why do you need this guarantee? What does it 
 > > > qualitatively add? If I make a judgement that I want to extend your 
 > > > class 
 > > > or implement your interface, I can just delete the sealed keyword from 
 > > your 
 > > > code and carry on. So it doesn't actually offer any guarantee at all 
 > > > that 
 > > > I'm not extending the type. 
 > > 
 > > Actually, it does offer such a guarantee.  It guarantees if you are using 
 > > a non-forked version of the original developer's (OD's) library or 
 > > framework then that class won't be extended. When someone pulls the 
 > > original non-forked version from its source repository — such as when 
 > > using 
 > > Composer — then that code will be (effectively) guaranteed not to be 
 > > extended. 
 > > 
 > > OTOH, if you do delete the sealed (or final) keyword you have then forked 
 > > the code, in a defacto manner if not a literal one. If you use a forked 
 > > version of the code, you now own the maintenance of that code and any bugs 
 > > that are generated by your forked changes in using code. The original 
 > > developer has no moral, ethical or even contractual obligation to care 
 > > about the breakage you cause. 
 > > 
 >  
 > I'd argue that if the original developer made clear that you shouldn't 
 > extend a class, then they still have no moral, ethical, or even contractual 
 > obligation to care about the fact you've used the object in a way they were 
 > clear was not supported. 
 >  
 > I'm with David on this one. I can understand the need to enforce a 
 > final/sealed concept for core functionality implemented in C which might do 
 > some funny things under the hood. I don't think that should be extended to 
 > userland. If you want to warn someone, that's fine. But don't totally 
 > prohibit them. 
 >  
 > Given the ability for composer to pull from forked repos and the easy of 
 > keeping a forked repo in sync with it's upstream version, creating a fork 
 > just to remove a sealed/final designation isn't that difficult to do. 
 >  
 >  
 > > 
 > > Hypothetical example:  You fork the code, remove sealed/final, then 
 > > subclass the code and add a method, let's call it ToString(). And you 
 > > write 
 > > your application to use ToString(). Now the OD releases a new minor 
 > > version 
 > > and they also add a ToString() method. Applications using your fork 
 > > probably cannot use the new version of the OD's library because when the 
 > > library calls ToString() your version is called. So you have to update 
 > > your 
 > > application to use the new version of the library and once again remove 
 > > sealed/final. 
 > > 
 > > AND, if your code is instead another add-on library, now users of your 
 > > add-on library will also have to fix their code too.  Which could 
 > > potentially be a large number of users if your add-on is successful. 
 > > 
 > > So not using final or sealed can result in some really hairy and possibly 
 > > impossible to fully resolve backward compatibility concerns for developers 
 > > who publish libraries and/or frameworks. 
 > > 
 > > > The best it can achieve is to indicate your 
 > > > intentions, which I believe can be adequately done today through an 
 > > > attribute, no addition to the language needed. 
 > > 
 > > Still, I concur with your concerns.  Developers too often implement final 
 > > classes in libraries and frameworks without fully addressing all the 
 > > use-cases and/or adding enough extensibility points because it makes their 
 > > lives easier.  Because of that final — and sealed, if added — can make the 
 > > life of an application developer a living hell. 
 > > 

Re: [PHP-DEV] [RFC][Draft] Sealed Classes

[Saif Eddin Gmati]

 > personally I'm okay with using an attribute, but using a keyword for type 
 > system related features seems like a better fit. 
 >  
 >  
 >  
 > I have added it to the alternative syntax list, which would have a separate 
 > vote. 
 >  
 >  
 >  
 > https://wiki.php.net/rfc/sealed_classes#syntax 
 >  
 >  
 >  
 >  
 >  
 >  
 >  
 >  
 >  On Sat, 24 Apr 2021 16:24:03 +0100 Matthew Brown 
 >  wrote  
 >  
 >  
 >  
 >  
 > > On Apr 24, 2021, at 10:43 AM, Levi Morrison via internals 
 > > <mailto:internals@lists.php.net> wrote: 
 > > 
 > > On Sat, Apr 24, 2021 at 8:04 AM Benjamin Eberlei 
 > > <mailto:kont...@beberlei.de> wrote: 
 > >> 
 > >>> On Sat, Apr 24, 2021 at 2:56 PM Pierre <mailto:pierre-...@processus.org> 
 > >>> wrote: 
 > >>> 
 > >>> Le 24/04/2021 à 12:55, Saif Eddin Gmati a écrit : 
 > >>>> Hello Internals, 
 > >>>> 
 > >>>> I'm sending this email to open discussion about sealed classes, 
 > >>>> interfaces, and traits feature for PHP 8.1. 
 > >>>> 
 > >>>> I have create a Draft RFC here: 
 > >>>> https://wiki.php.net/rfc/sealed_classes 
 > >>>> <https://wiki.php.net/rfc/sealed_classes> 
 > >>>> 
 > >>>> A major concern for few people have been the syntax, in which it 
 > >>>> introduces 2 new keywords into the languages, therefor, i have added a 
 > >>>> section about alternative syntax which could be used to avoid this 
 > >>>> problem. 
 > >>>> 
 > >>>> Regards, 
 > >>>> 
 > >>>> Saif. 
 > >>> 
 > >>> Hello, 
 > >>> 
 > >>> And why not using an attribute, such as in HackLang ? 
 > >>> 
 > >> 
 > >> +1 on this, I said the same on the "never/noreturn" RFC. There is a much 
 > >> less invasive way to add new keywords/flags to functions by using 
 > >> attributes. 
 > >> 
 > >> Imho this decouples new features from the language and reduces the "risk" 
 > >> of adding them to the language. That should increase the likeliness of it 
 > >> getting accepted in my opinion. 
 > > 
 > > I think an attribute may be appropriate here because sealed types act 
 > > like normal types, except we restrict who can extend them. 
 > > Additionally, we have to provide data about which types can extend the 
 > > sealed type, so it's not just a simple on/off type behavioral switch 
 > > (which I think is an antipattern for attributes based on my experience 
 > > in other languages that have them). 
 > > 
 > > This is different from a return type `never`. A function which never 
 > > returns cannot meaningfully have any return type at all -- using 
 > > `void` or some other type with an attribute would be a lie. 
 > > Additionally, there isn't any meta-data to associate with the `never`. 
 > > I hope this comment doesn't digress into a conversation about `never`; 
 > > that isn't my point. I'm trying to provide more justification about 
 > > when I think attributes are appropriate, because I think they may be 
 > > appropriate here and I think it's useful to show how `never` is 
 > > different. 
 > > 
 > > -- 
 > > PHP Internals - PHP Runtime Development Mailing List 
 > > To unsubscribe, visit: https://www.php.net/unsub.php 
 > > 
 >  
 > Yeah I second this — I think an attribute might be more appropriate here, 
 > and I obviously didn’t feel that way about the “never” RFC. 
 >  
 > One big benefit of a keyword over an equivalent attribute is that when you 
 > see `#[Sealed(...)]` you have to check use statements above to ensure it 
 > refers to the actual ‘Sealed’ attribute. 
 >  
 > What if PHP reserved double-underscore-prefixed attributes for engine use 
 > (and treated them as fully-qualified)? Hack does this currently, so you 
 > always know what a `<<__Sealed(Foo::class, Bar::class)>>` attribute will do, 
 > regardless of use statements. 
 >  
 > Best wishes, 
 >  
 > Matt 
 > -- 
 > PHP Internals - PHP Runtime Development Mailing List 
 > To unsubscribe, visit: https://www.php.net/unsub.php


Note: i have removed the choice for `#[Sealed(...)]` attribute syntax, while i 
don't mind it, i don't see a valid point for using attributes, other features ( 
e.g final classes ) use modifiers, and so should `sealed` as it is more 
comparable to `final` than other stuff people usually use attributes for ( e.g: 
#[Assert\Length(min: 2)], #[ORM\Entity], #[ApiResource] .. etc ).

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

Re: [PHP-DEV] [RFC][Draft] Sealed Classes

[Saif Eddin Gmati]

 On Sun, 25 Apr 2021 08:39:37 +0100 Olle Härstedt  
wrote 

 > > In practice, I think all of the use cases for sealed classes are 
 > > ADT-esque. 
 > > As I noted before, combining sealed classes with Nikita's 
 > > new-in-expressions 
 > > RFC would allow for this (also using my short-functions RFC for this 
 > > example, although that's a nice-to-have): 
 > > 
 > > sealed class Maybe permits Some, None { 
 > > 
 > >   public const None = new None(); 
 > > 
 > >   static public function Some($x) => new Some($x); 
 > > 
 > >   public function value() => throw new NotFoundException(); 
 > > 
 > >   public function bind(callable $c) => static::None; 
 > > } 
 > > 
 > > final class None extends Maybe {} 
 > > 
 > > final class Some extends Maybe { 
 > >   private $val; 
 > >   private function __construct($x) { $this->val = $x; } 
 > > 
 > >   public function value() => $this->val; 
 > > 
 > >   public function bind(callable $c) => new static($c($this->val)); 
 > > } 
 >  
 > Yes, the Maybe/Option type is a good example! Because you know there 
 > will never be another extension. But it's worth noting that whenever 
 > you do *not* know that, these concepts suffer, even in functional 
 > programming, by the same issues as I mentioned before with regard to 
 > maintainability - you can't easily extend it without touching old code 
 > (there are attempts to fix this by making algebraic datatypes 
 > extensible, but it didn't get widely adopted AFAIK). Also see this 
 > thread about the expression problem: 
 > https://stackoverflow.com/a/871375/2138090 
 >  
 > Disregarding the limitations of maintainability, the real power of 
 > algebraic datatypes is of course the pattern matching functionality 
 > seen in OCaml and Haskell. I'm leaning towards tagged unions + pattern 
 > matching have more to offer PHP than sealed classes (and even more so 
 > when pattern matching can be extended with guard clauses and catching 
 > exceptions). The RFC author(s) might want to extend the RFC to reflect 
 > the relation to tagged unions, and how they overlap (or not)? 
 >  
 > Olle 
 >  
 > -- 
 > PHP Internals - PHP Runtime Development Mailing List 
 > To unsubscribe, visit: https://www.php.net/unsub.php 
 >  
 > 

As mentioned in a previous email ( 
https://news-web.php.net/php.internals/114134 ), there's many differences 
between ADTs and Sealed classes,
and in my opinion that's enough to have them both in the language as personally 
i have use cases where ADTs won't work.

examples:
- `sealed class UnionType permits ArrayKeyType, NumType` ( 
https://github.com/azjezz/psl/tree/1.7.x/src/Psl/Type/Internal )
- `sealed interface ExceptionInterface permits Exception` ( 
https://github.com/azjezz/psl/blob/1.7.x/src/Psl/Type/Exception ) - applies to 
all components in library
- `sealed class Exception permits AssertException, CoercionException` ( 
https://github.com/azjezz/psl/blob/1.7.x/src/Psl/Type/Exception )
- `sealed class ResourceHandle permits 
Psl\Filesystem\Internal\ResourceFileHandle` ( 
https://github.com/azjezz/psl/blob/asio/src/Psl/IO/Internal / 
https://github.com/azjezz/psl/tree/asio/src/Psl/Filesystem/Internal )

This is just a list of top of my head, the protection `sealed` offers is at the 
same level of `final`, expect it allow me to use inheritance internally without 
allowing the end users to do so.

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

Re: [PHP-DEV] [RFC][Draft] Sealed Classes

[Saif Eddin Gmati]

> Doesn't this violate the principle: It should be possible to add new features 
> without touching old code? 



This depends on which syntax is picked, both `for` and attribute syntax will be 
completely BC.



using `sealed`+`permits` or `permits` only will result in these keywords being 
reserved, so classes named `Sealed` or `Permits` will not work in PHP 8.1.

 

> Isn't namespace-internal access a better feature for the same purpose? That 
> is, only allows a class to be extended within the same namespace. 



No, this is a different feature, sealed classes can permit classes in a 
completely different namespace, and restrict inheritance to a per-defined list 
of classes.



If we would allow inheritance in the same namespace, it's extremely easy to get 
around it:



```

namespace Lib {

  abstract class MyProxy implements PrivateFooInterface {}

}



namespace App {

  class MyFooImplementation extends \Lib\MyProxy {

    // ...

  }

}

```



while it is possible to get around sealed, or even final keywords ( 
https://github.com/dg/bypass-finals/blob/master/src/BypassFinals.php ), 
bypassing private classes/interface is much easier, and doesn't require any 
hacks.











 On Sat, 24 Apr 2021 16:52:20 +0100 Olle Härstedt  
wrote 



2021-04-24 12:56 GMT, Pierre <mailto:pierre-...@processus.org>: 
> Le 24/04/2021 à 12:55, Saif Eddin Gmati a écrit : 
>> Hello Internals, 
>> 
>> I'm sending this email to open discussion about sealed classes, 
>> interfaces, and traits feature for PHP 8.1. 
>> 
>> I have create a Draft RFC here: 
>> https://wiki.php.net/rfc/sealed_classes 
>> <https://wiki.php.net/rfc/sealed_classes> 
>> 
>> A major concern for few people have been the syntax, in which it 
>> introduces 2 new keywords into the languages, therefor, i have added a 
>> section about alternative syntax which could be used to avoid this 
>> problem. 
>> 
>> Regards, 
>> 
>> Saif. 
 
1) Doesn't this violate the principle: It should be possible to add 
new features without touching old code? 
 
2) Isn't namespace-internal access a better feature for the same 
purpose? That is, only allows a class to be extended within the same 
namespace. 
 
Olle 
 
-- 
PHP Internals - PHP Runtime Development Mailing List 
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Draft] Sealed Classes

[Saif Eddin Gmati]

personally I'm okay with using an attribute, but using a keyword for type 
system related features seems like a better fit.



I have added it to the alternative syntax list, which would have a separate 
vote.



https://wiki.php.net/rfc/sealed_classes#syntax








 On Sat, 24 Apr 2021 16:24:03 +0100 Matthew Brown 
 wrote 




> On Apr 24, 2021, at 10:43 AM, Levi Morrison via internals 
> <mailto:internals@lists.php.net> wrote: 
> 
> On Sat, Apr 24, 2021 at 8:04 AM Benjamin Eberlei 
> <mailto:kont...@beberlei.de> wrote: 
>> 
>>> On Sat, Apr 24, 2021 at 2:56 PM Pierre <mailto:pierre-...@processus.org> 
>>> wrote: 
>>> 
>>> Le 24/04/2021 à 12:55, Saif Eddin Gmati a écrit : 
>>>> Hello Internals, 
>>>> 
>>>> I'm sending this email to open discussion about sealed classes, 
>>>> interfaces, and traits feature for PHP 8.1. 
>>>> 
>>>> I have create a Draft RFC here: 
>>>> https://wiki.php.net/rfc/sealed_classes 
>>>> <https://wiki.php.net/rfc/sealed_classes> 
>>>> 
>>>> A major concern for few people have been the syntax, in which it 
>>>> introduces 2 new keywords into the languages, therefor, i have added a 
>>>> section about alternative syntax which could be used to avoid this 
>>>> problem. 
>>>> 
>>>> Regards, 
>>>> 
>>>> Saif. 
>>> 
>>> Hello, 
>>> 
>>> And why not using an attribute, such as in HackLang ? 
>>> 
>> 
>> +1 on this, I said the same on the "never/noreturn" RFC. There is a much 
>> less invasive way to add new keywords/flags to functions by using 
>> attributes. 
>> 
>> Imho this decouples new features from the language and reduces the "risk" 
>> of adding them to the language. That should increase the likeliness of it 
>> getting accepted in my opinion. 
> 
> I think an attribute may be appropriate here because sealed types act 
> like normal types, except we restrict who can extend them. 
> Additionally, we have to provide data about which types can extend the 
> sealed type, so it's not just a simple on/off type behavioral switch 
> (which I think is an antipattern for attributes based on my experience 
> in other languages that have them). 
> 
> This is different from a return type `never`. A function which never 
> returns cannot meaningfully have any return type at all -- using 
> `void` or some other type with an attribute would be a lie. 
> Additionally, there isn't any meta-data to associate with the `never`. 
> I hope this comment doesn't digress into a conversation about `never`; 
> that isn't my point. I'm trying to provide more justification about 
> when I think attributes are appropriate, because I think they may be 
> appropriate here and I think it's useful to show how `never` is 
> different. 
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List 
> To unsubscribe, visit: https://www.php.net/unsub.php 
> 
 
Yeah I second this — I think an attribute might be more appropriate here, and I 
obviously didn’t feel that way about the “never” RFC. 
 
One big benefit of a keyword over an equivalent attribute is that when you see 
`#[Sealed(...)]` you have to check use statements above to ensure it refers to 
the actual ‘Sealed’ attribute. 
 
What if PHP reserved double-underscore-prefixed attributes for engine use (and 
treated them as fully-qualified)? Hack does this currently, so you always know 
what a `<<__Sealed(Foo::class, Bar::class)>>` attribute will do, regardless of 
use statements. 
 
Best wishes, 
 
Matt 
-- 
PHP Internals - PHP Runtime Development Mailing List 
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: [RFC][Draft] Sealed Classes

[Saif Eddin Gmati]

A major behavior i wanted to discuss is how should sealed interfaces work, and 
specially around `Throwable` which is currently sealed to only `Error` and 
`Exception`, but allows other interfaces to extend it, and other classes to 
implement it as long as they extend `Error` or `Exception` ( or another class 
that does so ).

As per the current proposal, if `Throwable` is to be declared `sealed`, 
permitting only `Error` and `Exception`, it won't be possible to extend it, 
resulting in a major BC-break, considering that too many libraries extend this 
interface in their own `ExceptionInterface`.

To work around this, there's two solution:

1. don't declare `Throwable` sealed and keep it as a special case.
2. interfaces declared sealed, can be extended by other interfaces, however, 
classes that implement either the sealed interface directly, or via another 
interface, have to extend one of the classes the sealed interface permits.

The second solution will allow declaring `Throwable` sealed, and would bring 
complete consistency between internally sealed symbols, and user land, without 
any BC breaks, and IMHO, it doesn't hurt as at the end, no one will be able to 
implement `Throwable` without extending the permitted classes.

Note: with the second solution, if an interface is sealed and permits only 2 
classes which are final, and you extend that interface into another, there's no 
way you can actually implement your new interface, and i will be as if you just 
declared a final interface.

‐‐‐ Original Message ‐‐‐
On Saturday, April 24, 2021 11:55 AM, Saif Eddin Gmati  
wrote:

> Hello Internals,
> 

> I'm sending this email to open discussion about sealed classes, interfaces, 
> and traits feature for PHP 8.1.
> 

> I have create a Draft RFC here: https://wiki.php.net/rfc/sealed_classes
> 

> A major concern for few people have been the syntax, in which it introduces 2 
> new keywords into the languages, therefor, i have added a section about 
> alternative syntax which could be used to avoid this problem.
> 

> Regards,
> 

> Saif.

signature.asc
Description: OpenPGP digital signature

[PHP-DEV] [RFC][Draft] Sealed Classes

[Saif Eddin Gmati]

Hello Internals,

I'm sending this email to open discussion about sealed classes, interfaces, and 
traits feature for PHP 8.1.

I have create a Draft RFC here: https://wiki.php.net/rfc/sealed_classes

A major concern for few people have been the syntax, in which it introduces 2 
new keywords into the languages, therefor, i have added a section about 
alternative syntax which could be used to avoid this problem.

Regards,

Saif.

signature.asc
Description: OpenPGP digital signature

[PHP-DEV] [RFC][Draft] Sealed Classes

[Saif Eddin Gmati]

Hello Internals,

I'm sending this email to open discussion about sealed classes, interfaces, and 
traits feature for PHP 8.1.

I have create a Draft RFC here: https://wiki.php.net/rfc/sealed_classes

A major concern for few people have been the syntax, in which it 
introduces 2 new keywords into the languages, therefor, i have added a 
section about alternative syntax which could be used to avoid this 
problem.

Regards,

Saif.




> Note: I'm sending this email again using a different mail client as the 
> previous one ended up in spam folder for most people

[PHP-DEV] RFC karma Request

[Saif Eddin Gmati]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello Internals,

I'm requesting karma to open an RFC for sealed classes feature.

wiki username: azjezz
-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsFzBAEBCAAGBQJggxwSACEJELAOCkaz8cFXFiEEOazMpP0wDQTIQG6zsA4K
RrPxwVdBzBAAg7C5m8vqTasy5vnYE3bzblopTOaCmCFWNr1XK0mHTUT/gpBL
hUtkMFeoy5ZvhXv4iRoZOsfi+nucuPl97ikFwuGYF7AQcBkER5+ge2ZmOX4n
xHqtTqhl+u81/DMPynIzKogRQTA+CEPeocM8IS63OCOnijgQWX2jKQSJtWlQ
HpFCVYxamvY1mppTi/kEHO8gGRG96PvufffHaP5A+u3lkdNtJ6BAc8Nbst2S
j8ne1DJ1AI5HlGEXcnkgMlIV2ksjkFGL1v9T6g9flCyPK1zUXR5HsLbhvSGb
Pco1INa76RxKPMKBP7pIa38+AACWn8cOfmzIjsAG4sHI/oCebrpmTUY3QGtl
CRgxKrvO12X27YHjlwtgViu6lXHcTIitho48Y4kh6sU0zCNjZMX5Y+XeSA2b
HmKhs7SCCvQiYnzQXub1cY4f2nFNaVGZPXgQ4hvnHpFhG0n0w+Vcs1U4w8vw
VxA03LDTa+xmEg+qwc5EYHJjYl8UtTMveIAiR1FHKGLAxVXgXVb4dUeWk3Cj
8/V8LCZJY1ou/73/uTy5Tc/uPU8SlZuiDJRZUu61SjwOfOs8SIbddlYPt2nP
ACdG84/hYmxdN7n9o8yfpWHzRV4ntJ4Ls+XzeexQ1Z2vw4VW2raTq7NZu2yL
jMK6nR4uPaQjFwFZZxv/2PkJsRoy8QLIKrY=
=NU5a
-END PGP SIGNATURE-

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

Re: [PHP-DEV] [8.1] Release Manager Election

[Saif Eddin Gmati]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

I would like to introduce myself to those of you who might not know me.

My name is Saif ( also known as "azjezz" ), I'm 21 years old, i have been 
working with PHP for approximately 8 years.

I'm currently employed as a senior developer at [Les 
Tilleuls](https://les-tilleuls.coop/en), before that i worked at Symfony SAS 
for 1 year and 6 months, in total, i have 2 years of professional experience.

I maintain some open source projects ( e.g: 
[PSL](https://github.com/azjezz/psl) ), and help contribute to some other on my 
free time ( e.g: [Symfony](https://github.com/symfony/symfony), 
[Psalm](github.com/vimeo/psalm) ).

I'm mostly interested in type systems, and asynchronous programming.

I have been subscribed to the internals mailing list for few years now ( didn't 
engage much ), but i want to help the community within my powers, and i think i 
can take on this role with the help of the veteran RM.

If you have any additional questions, you can reach me via email, twitter, or 
keybase.

Regards.

GitHub: https://github.com/azjezz
Twitter: https://twitter.com/azjezz
Keybase: https://keybase.io/azjezz

-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsFzBAEBCAAGBQJgcdq1ACEJELAOCkaz8cFXFiEEOazMpP0wDQTIQG6zsA4K
RrPxwVfmgA/9GJ2KhEKBuGoH+W9GwLNjw+BrkmAymmZV1E/mBSSzI3aHmC1s
wLRsqgu6Q9qvReULn9YejhO7CPJNSKiGtvZwcNrZZdMpifhV+LMIpzLPXi0I
/1pON8glFwFJACdA1wfEejJtTlcX5ZtZIL1MZ5sZ6jM+/NTtVp1S8z2Cxwe3
SHWvdrUlH/WI64q4SBPraaHenPIvEhezd4ZUV/xQuPog/aBughXvTjw8ItsT
VYoKs0tWy8WRkGHWg9Y9AhfDaL2kdzdEEytbs7qD0GFrikfrZFJo8vLLxCnm
wW8OR+P4A2Z/Fab8JWt40NCuOGjpBo/G2n+y3WM0XGxiJGKssM3m4QeymkPu
iakn+IE9NsY2cY6p16opUNBDsi/1SCiZUykkMncR4vpKXInpmTdImUykdn2a
fS4qivLBcYPllRUCcjIzXZT7yNq6HSoXOMrwqhHxWIJZv1EA/KotHfoTxT9t
ioTy6Vv6vx/hb/LLlU9X+r+mw+CPRXk/FKmF8a6/anyUvs6JQC1Iw00nrqJl
hurVI4gFn/8yvRdvtgUdZ7LDoQvIAXMJMUHqeTsXOf1ct+WFRT/8eGeBjYRo
eh29ALlgEZd588UqcnLkGcvj8zYjXwSz9JXgcvXUHnc2VwaYb+UC/Q59H52K
VFiKwWb90B5JabF97i4mgwG81CZaGaFvjEc=
=8Xc0
-END PGP SIGNATURE-

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

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] Pure intersection types

[Saif Eddin Gmati]

Personally, I am against the syntax used in the PR for composite
types( even tho i don't have voting powers ).

I would prefer a syntax similar to Hack, where you have to use parentheses to 
make things more explicit.

considering the following Hack code:


interface A {}
interface B {}
interface C {}
interface D {}
interface E {}
interface F {}

function bar(
  ((A & F) | (((A & B) | (C & D)) & E)) $_foo
): void {}


In PHP, i would assuming i can just remove the parentheses and it would work as 
expected:


https://twitter.com/azjezz/status/1373439678045683721 / 
https://twitter.com/azjezz/status/1373647148026322946

Regards,

Saif.


‐‐‐ Original Message ‐‐‐
On Saturday, April 3, 2021 1:22 PM, G. P. B.  wrote:

> On Tue, 23 Mar 2021 at 19:45, Matthew Brown matthewmatt...@gmail.com
> wrote:
>
> > On Tue, 23 Mar 2021 at 05:32, G. P. B. george.bany...@gmail.com wrote:
> >
> > > I'm calling this proposal pure intersection types as there would be no
> > > possibility of mixing intersection and union types, I'm leaving this as a
> > > future scope.
> >
> > Does this miss an opportunity, though? It's useful to be able to write
> > A|null.
>
> Obviously this is less powerful than support for composite types where one
> can use both intersections and unions.
>
> I've tried implementing composite types without grouping here:
> https://github.com/Girgias/php-src/pull/8
> But I'm hitting various issues and I'm far from confident that I'll be able
> to resolve them and add the variance check code before June so that this
> can reasonably get voted in for PHP 8.1.
>
> The end goal is support for composite types but I prefer to land a
> reasonably self contained feature in 8.1 then nothing at all.
> Internals might disagree with this and refuse the feature unless "complete"
> but if that's the case there is still time to "finish" it for another RFC.
>
> If someone else wants to work on adding support for composite types they
> are free to work based on my PR, or collaborate with me.
>
> I've also tidied up the RFC: https://github.com/Girgias/intersection-types
>
> Unless someone shows up to work on composite types, I'll probably bring
> this to a vote next week (if I don't forget about it).
>
> Best regards,
>
> George P. Banyard

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

Re: [PHP-DEV] Release Managers for PHP 8.1

[Saif Eddin Gmati]

Hello Sara,


I would like to volunteer as a newbie RM.

I don't have much experience with php-src it self, but i have been
involved in PHP community as a whole for a while, and would like to try and 
help out.

Regards,

Saif.

https://void.tn


‐‐‐ Original Message ‐‐‐
On Monday, March 1, 2021 6:09 PM, Sara Golemon  wrote:

> This is your early, advance warning that RM selection for the PHP 8.1
> branch will be coming up in April. Please start thinking about whether or
> not you would like to put your hat in the ring. Feel free to volunteer now,
> or any time over the coming weeks. Additional announcements will be
> forthcoming as we approach the selection date. On April 12th
> (provisional), Gabriel or I will announce the list of candidates and, if
> more than two candidates have volunteered, open a vote.
>
> A description of our release process can be found at
> https://github.com/php/php-src/blob/master/docs/release-process.md and
> https://wiki.php.net/rfc/releaseprocess
>
> Notably, at least one of the volunteers must be a "veteran" release manager
> meaning they have participated in at least one release of PHP in the past.
> The other may be an additional veteran, or more ideally, someone new to the
> RM role (in order to increase our supply of veteran RMs). Regardless of
> who is participating, you'll have access to all active release managers to
> help get you up and running.
>
> Let's all make PHP awesome!
> -Sara Golemon and Gabriel Caruso, your PHP 8.0 Release Managers

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

Re: [PHP-DEV] [RFC] noreturn type

[Saif Eddin Gmati]

Hey Matthew,

I have look at the implementation a few days ago, and was patiently waiting for 
the RFC.

a huge +1 from me ( even tho i can't vote ), `noreturn` type would be a great 
addition to PHP type system.


Regards,

Saif.


‐‐‐ Original Message ‐‐‐
On Wednesday, March 10, 2021 7:06 PM, Matthew Brown  
wrote:

> Hey,
>
> Ondřej Mirtes and I present an RFC for the noreturn type:
> https://wiki.php.net/rfc/noreturn_type
>
> The feature already exists in Hack (the primary inspiration) and is
> currently supported by our static analysis tools inside docblocks, and we
> feel there's a good argument for it to be supported by PHP itself.
>
> Thanks,
>
> Matt & Ondřej

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

Re: [PHP-DEV] [RFC] Fibers

[Saif Eddin Gmati]

Hello Aaron,

First, I want to say that I love this proposal and would love to see it land in 
the next PHP release, but I have one question regarding this:


> Promises result in the “What color is your function” problem as described in 
> the introduction of the RFC. Returning promises from functions means that 
> functions calling those functions must also return promises, resulting in the 
> entire call stack needing to return promises.

Hack-Lang provides `HH\Asio\join` function which allows awaiting Awaitables in 
sync code, so you are capable of running multiple async tasks concurrently 
without having to declare the entire call stack as "async" or with an 
"Awaitable" return type, isn't this possible?

```
use namespace HH\Asio;

async function async_task(): Awaitable {
  await Asio\usleep(100);
}

<<__EntryPoint>>
function main(): void {
  $start = microtime(true);

  $async = async {
concurrent {
  await async_task();
  await async_task();
};

return 'hello';
  };

  $result = Asio\join($async);

  printf('Result: %s ( %f )', $result, microtime(true) - $start); // output 
"Result: hello ( 1.010382 )"
}

```

Regards,

Saif.


‐‐‐ Original Message ‐‐‐
On Thursday, December 17, 2020 8:43 PM, Aaron Piotrowski  
wrote:

> Hi Peter,
>
> > On Dec 17, 2020, at 1:23 PM, Peter Stalman sarke...@gmail.com wrote:
> > Hi Aaron, this is very interesting to me. Can I ask why this approach as
> > opposed to other paradigms like promises, coroutines, etc? You mentioned
> > async/await in the future scope, and I assume most of these patterns can be
> > implemented once there is an underlying functionality. Basically, why
> > fibers instead of x?
>
> Promises result in the “What color is your function” problem as described in 
> the introduction of the RFC. Returning promises from functions means that 
> functions calling those functions must also return promises, resulting in the 
> entire call stack needing to return promises.
>
> Fibers are a method of implementing coroutines or interruptible functions. 
> Promises likely would still be used as placeholders in libraries using 
> fibers, but coroutines written using fibers do not have to return another 
> placeholder. Fibers allow async code to be indistinguishable from sync code, 
> as opposed to an approach where async functions must return a promise.
>
> > You also mentioned this isn't really intended to be used directly, but with
> > a library such as AMPHP. IS the expectation that non-blocking I/O
> > functionality like database drivers and file operation be provided by
> > libraries as well?
>
> Since most code written for PHP is blocking, yes, such libraries/frameworks 
> would need to provide functionality such as database drivers. Both AMPHP and 
> ReactPHP already have existing async drivers available for several different 
> popular database systems. AMPHP’s postgres, mysql, and redis drivers already 
> have a version using fibers.
>
> > I hope I don't come off as critical, I am merely curious. Thank you for
> > pushing this forward, as async is something PHP has been lacking and should
> > have IMO to compare favourably to other alternatives that do.
>
> You didn’t com off as critical at all! These were good questions to ask. I 
> too think if PHP is to add support for async code it should compare favorably 
> to other languages. I think fibers offer a distinct advantage to using 
> promise for async code.
>
> Cheers,
> Aaron Piotrowski
>
> 
>
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php

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

Re: [PHP-DEV] [RFC] Attributes v2

[Saif Eddin Gmati]

Really excited to see the discussion about this feature being brought up again, 
thanks for working on this :)

One thing I would suggest is to add a base interface `Attribute` and multiple 
sub-interfaces such as `ClassAttribute`, `MethodAttribute`, and 
`PropertyAttribute` just like hack lang ( 
https://docs.hhvm.com/search?term=HH%20Attribute )

This allows one to declare attributes that can only be used with classes ( e.g 
`ORM\Entity` ), so PHP and check against them at runtime and throws an error 
when an attribute is used in the wrong place.

```php

namespace ORM {

  class Entity implements \ClassAttribute { ... }

}

namespace Foo {
  use ORM;

  <>  // <-- Error
  function bar(): void {}
}
```


I also question whether the following syntax would be supported:

```php
<>
class Use {...}
```



I'm really looking forward to this since it can help bring more features into 
PHP such as :

- https://docs.hhvm.com/hack/attributes/predefined-attributes#__entrypoint
- https://docs.hhvm.com/hack/attributes/predefined-attributes#__memoize
- https://docs.hhvm.com/hack/attributes/predefined-attributes#__sealed


Regards.

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

Re: [PHP-DEV] [RFC] Attributes v2

[Saif Eddin Gmati]

Really excited to see the discussion about this feature being brought up again, 
thanks for working on this :)

One thing I would suggest is to add a base interface `Attribute` and multiple 
sub-interfaces such as `ClassAttribute`, `MethodAttribute`, and 
`PropertyAttribute` just like hack lang ( 
https://docs.hhvm.com/search?term=HH%20Attribute )

This allows one to declare attributes that can only be used with classes ( e.g 
`ORM\Entity` ), so PHP and check against them at runtime and throws an error 
when an attribute is used in the wrong place.

```php

namespace ORM {

  class Entity implements \ClassAttribute { ... }

}

namespace Foo {
  use ORM;

  <>  // <-- Error
  function bar(): void {}
}
```


I also question whether the following syntax would be supported:

```php
<>
class Use {...}
```



I'm really looking forward to this since it can help bring more features into 
PHP such as :

- https://docs.hhvm.com/hack/attributes/predefined-attributes#__entrypoint
- https://docs.hhvm.com/hack/attributes/predefined-attributes#__memoize
- https://docs.hhvm.com/hack/attributes/predefined-attributes#__sealed


Regards.

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