Re: [Concept] Flip relative function lookup order (global, then local)

Hi Rowan, > On Aug 23, 2024, at 2:39 AM, Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> wrote: > On 23 August 2024 00:15:19 BST, Mike Schinkel <mike@newclarity.net> wrote: >> Having to prefix with a name like Foo, e.g. Foo\strlen() is FAR PREFERABLE to _\strlen() >> because at least it provides satiating information rather than the empty calories of a cryptic >> shorthand. #jmtcw, anyway. > > I knew I'd regret keeping the example short. Realistically, it's not a substitute for > "\Foo\strlen", it's a substitute for > "\AcmeComponents\SplineReticulator\Utilities\Text\strlen". And similarly, I too regret keeping my answer short. I was assuming what I omitted would be obvious. (And I am not being snarky, I literally thought about including this next but then felt I did not need to. Hindsight!) So, long namespaces is why PHP has the use statement, making references in functions short and sweet, e.g: namespace \AcmeComponents\SplineReticulator\Utilities\Text use \AcmeComponents\SplineReticulator\Utilities\Text function Foo():int { return Text\strlen("Hello World"); } (Of course, that is a lot of redundant boilerplate.) > Another option would be to find a shorter keyword than "namespace" to put it in > front. "ns\strlen(...)" is an obvious step from what we have currently, but it's not > very obvious what it means, so maybe there's a different word we could use. So rather than all that boilerplate, and rather than yet another special set of characters developers would need to learn and remember — and tooling would need to adjust to — we could instead easily add an automatic use statement for every namespace, as long as no existing use statement conflicts with it. An automatic use would then give us the following, which provides a strong information sent and is really consistent with the nature of the PHP language: namespace \AcmeComponents\SplineReticulator\Utilities\Text function Foo():int { return Text\strlen("Hello World"); } The above of course could result in BC breaks IF there happened to be existing code that referenced Text\strlen() where Text was a top-level namespace, AND that code was not remediated when this change takes place. However, I am guessing those collisions would be pretty rare as both the namespace and the symbol would have to match to be in conflict. > Having a syntax for "relative to current" is incredibly common in other path-like > syntaxes. The most common marker is ".", and ".\foo" is literally how you'd > refer to something in the current directory under DOS/Windows. But unfortunately, we don't have > "." available, so I wondered if "_" would feel similar enough. I'll be honest, the association with the relative path of .\ did not occur to me when you presented _\ so after you stating this I pondered if from that perspective. However, frankly, I am not sold on that perspective. Something about it does not feel right. I can't currently give any more objective arguments than that, so I will just leave it as #jmctw. I will say if we were going with relative path, I think \\strlen() would be preferable to _\strlen(). Subjectively \\ is easier for me to "see" and thus does not look so out of place to me. OTOH the objective arguments for \\ over _\ are it is much easier to type: slash+slash vs. shift-underscore+nonshift-slash. There is a precedent in URIs with //, albeit not exactly equivalent. And finally, it also does not use a sigil that could be better used elsewhere in some as-yet-to be agreed or envisioned future use. #fwiw -Mike