On Mon, Ma0r 17, 2025 at 9:56 AM Rowan Tommins [IMSoP] <imsop....@rwec.co.uk> wrote:
> > > On 17 March 2025 07:11:23 GMT, Rob Landers <rob@bottled.codes> wrote: > > > > Which one it resolves to would depend on how you implement autoloading > > > That's just the same as having the same class defined in two files on disk > - PHP doesn't know which will be used until an autoloader runs. > > From what I understand of the proposal, the calling code won't know > anything different based on it being "nested" or "namespaced", it will just > see a class with a long name with some punctuation in. > > The problem for me is not autoloading, but that you can't have the two classes defined at the same time, while using some other punctuation it would allow it. I believe that there are other operators that we can use, to allow this. > I rather think the other way round: in the short term, a new separator > would save users a bit of pain with autoloading, but in the long run it > will look like a weird anomaly that no other language needs. > > There was much discussion about various ways to solve the problem stated in the RFC, but I think we need to look at it as a broader picture again. I'll share what I've been thinking about in the past week and didn't yet had time to reply here. Right now, PHP only has public classes. For better encapsulation and cohesion, we want to define some new ways to define classes with some limited restrictions or improved access. Taking examples from other languages, we can have two ways to do this: - namespace private classes, or file-private classes - this controls the visibility of the class at the namespace or file level. They’re essentially about managing the scope of classes without changing their fundamental behavior. - nested (inner) classes - this allows a class defined inside another to access private members of its enclosing class, increasing cohesion. And we can have further here just public visibility, or protected/private visibility, for better encapsulation. Given this, I think we could even implement all of these in separate RFCs: - public nested classes - file-private classes - namespace private classes - protected/private nested classes - other-grouping-level-that-will-exist-in-the-future private classes Of all of this, the first, public nested classes are the most simple and would drive cohesion. And maybe we can have only that for now. The other features would be mostly important for encapsulation, with limiting the class visibility. We just need to agree on a separator/operator, and IMHO, it should be clear and distinct from namespace separator, as nested classes are a separate concept. Maybe having a vote on the operator would be enough. (As a note, and this might have been discussed already, but I would prefer to use the term nested class instead of inner class, as in java the inner classes means non-static classes, and I don't think we should go that way.) -- Alex
