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
