On Sat, Jun 29, 2024, at 11:41, Mike Schinkel wrote:
>> On Jun 28, 2024, at 7:45 AM, Rob Landers <[email protected]> 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