Hi Tim,
> I agree here. While I'm totally in favor of using namespaces in core, it > should be done somewhat consistently. If the proc_* functions are in the > global namespace, then so should the resource object. > While I don't necessarily want to add a dedicated namespace for Process (or whatever name we settle on), I don't agree with the reasoning: the resource to opaque object migration project is just a first step, afterwards, a new object oriented API could be added (as you already noted), and later on, the procedural one should be deprecated. That's why I think this kind of consistency is not important in this case. Please note that many such opaque objects have been added to namespaces recently (e.g. FTP\Connection, IMAP\Connection, LDAP\Connection etc.). so we already have some precedent. I agree with the rest of your answer though. My favourite name is Process and I am fine with ProcessHandle as well. The latter name was proposed by Nicolas in a private conversation. In my opinion, a straw poll should decide the naming question. I honestly don't think that the change needs any more discussion/an RFC, as it doesn't cause any larger BC break than some of the other resource migrations we performed since PHP 8.0 -- and there were a lot of them: resources of around 20 extensions got converted to proper objects among curl, openssl, and pgsql just to mention some. I'd argue that at least ext/curl is more widespread than proc_* functions are. Regards, Máté
