On Sat, Jun 29, 2024, at 11:41, Mike Schinkel wrote: >> On Jun 28, 2024, at 7:45 AM, Rob Landers <rob@bottled.codes> wrote: >>> Fast forward a bit - PHP 5.3, and the introduction of namespaces were >>> introduced to deal with the overloaded symbol tables. They are a bit a >>> hotwire as (if I'm not mistaken, it's been a couple years since I read the >>> discussion on it) they just quietly prepend the namespace string in front >>> of the name of all new symbols declared in the namespace for use elsewhere. >>> As a result, PHP namespaces don't do some of the things we see in the >>> namespaces of other languages (looking at Java and C# here). For example, >>> privacy modifiers within a namespace aren't a thing. >> >> This would be nice to have ... maybe. But namespace have been around, what, >> 10-15 years? I think if someone wanted to "fix" it, it would have been fixed >> by now. >> Or not. >> >> Never underestimate the power of inertia for maintaining a less than ideal >> status-quo, especially when the decision to change has to be approved by a >> 2/3rd vote of committee. 🤷♂️ >> > -Mike
I disagree that it is inertia, as there is quite a bit of flexibility and robustness in the current way things are. If you've ever had to get access to "internal" methods/fields in other languages, there are quite a few hoops. - Java: as of 11.0 or maybe 8.0 -- it's been awhile since I've had to do this, but you have to create a class in the target "namespace" and expose whatever you need. - C#: you have to use reflection to gain access to it. Right now, in PHP, you just "use it" and deal with the consequences of doing so. It's great when you need to work around a bug in a library and very little friction. As a library author, I want *some* friction, but I also don't want to force people to come to me and open a PR just for their use-case (hence why I almost never make classes final as well). — Rob
