On Sun, 16 Jun 2024 at 19:09, Rowan Tommins [IMSoP]
<[email protected]> 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.