Hi

Am 2025-05-06 22:04, schrieb Rob Landers:
I think these are fundamental problems (if they are a problem at all) with how PHP currently does namespaces and names.

I don't think that this is a fundamental problem of namespaces and names. Ilija solved the naming conflict issue in his file-private class proposal.

I'm curious if you would vote "no" for namespace visibility as well?

I cannot answer this question. PHP doesn't have namespace visibility and whether or not I would be in favor of a proposal depends greatly on the proposed semantics. In the current nested classes RFC, the proposed semantics for `private` classes are inconsistent with how `private` in PHP currently behaves, which makes it unacceptable to me.

For everyone else who voted "no"; I would sincerely love to know the reason. Even if you just email me directly; it would really help me understand what can be improved in any future RFCs.

I unfortunately didn't have the time to follow the discussion and think about the RFC in depth. Besides the `private` semantics, the autoloading impact is also a no for me, since to be able to properly use nested classes, a composer update would be required, so that composer’s autoloading implementation becomes aware of nested classes to properly load them. This means that if a package uses nested classes, it will *silently* be broken until the *consumer* updates their composer installation. I don't think it is currently possible to define a minimum composer version as part of a package’s dependencies.

Best regards
TIm Düsterhus

Reply via email to