Hi Rowan,
> On Aug 23, 2024, at 2:39 AM, Rowan Tommins [IMSoP] <[email protected]> wrote:
> On 23 August 2024 00:15:19 BST, Mike Schinkel <[email protected]> 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