On Sun, 16 Jun 2024 at 19:09, Rowan Tommins [IMSoP]
<imsop....@rwec.co.uk> wrote:
>
> On 16/06/2024 16:24, Andreas Hennings wrote:
>
> For a function call, the namespace is usually only visible in the
> imports list at the top of the file.
>
>
> This is one of those interesting cases where the language itself is flexible,
> but people are used to a specific style: a use statement can import any level
> of namespace, to provide as much or as little context as needed in a
> particular piece of code.
>
> namespace Acme\Artistry\Color {
> function fromRgb($red, $green, $blue) { /*...*/ }
> }
>
> namespace My\Own\Application {
> use Acme\Artistry\Color;
>
> // ...
> $color = Color\fromRgb(1,2,3);
> // ...
> }
>
>
> Maybe that's rare in practice, but it's always tricky to judge how much the
> language should account for such habits - see also "every class needs a new
> file", and my pet hate "deprecation notices get promoted to errors".
Yes, the possibility for namespace part imports exists.
Unfortunately these namespace imports usually need to be set up
manually, whereas the regular class or function import has better
automatic support from the IDE.
Also, namespace fragments are often more generic than function names,
so more likely to need a custom alias.
>
>
> The class name that is part of a static method call hints at an object
> type, whereas for a namespace fragment it may not be really clear what
> it describes.
> In a static factory call, like `Color::fromRgb($red, $green, $blue)`,
> I would argue that having the class name as part of the call improves
> DX.
>
>
> This example seems slightly off: if the static method is on the class it is a
> factory for, that class clearly isn't completely static.
There are two separate argument tracks here.
The `Color::fromRgb($red, $green, $blue)` has a nice DX, and justifies
the eixstence of static methods in general.
This also aligns with Larry's argument about "named constructors", or
the more general "type context".
Then, you may rename the instantiable part of the class, while leaving
the static factories in place.
You end up with an all-static class.
Or you already start with different implementation classes like
RgbColor and HexColor, all implementing ColorInterface, but you want
one centralized place for static factories.
I personally prefer to call this `Color` instead of `ColorFactory`.
For me `ColorFactory::create()` would give me a ColorFactoryInterface
object, not a ColorInterface object.
>
> Presumably what we're actually talking about is something like
> "ColorFactory::fromRgb(...)" - or maybe "GraphicsFactory::colorFromRgb(...)",
Basically yes.
> where you might well want to abbreviate to "colorFromRgb(...)".
I assume you mean as a procedural function?
Technically that would be possible.
But I still like to keep the `Color::` part which is suggestive of the
`ColorInterface`, even when the class `Color` itself is not really
instantiable.
A namespace fragment or a function prefix is not as suggestive that
this produces a ColorInterface object
>
>
> Your points are generally well made, I just wanted to point out there are
> some nuances in that particular area.
Thanks.
