On 1/20/23 07:01, torhu wrote:

> But why not have drawLine just be a free function?

Exactly.

If I'm not mistaken, and please teach me if I am wrong, they are practically free functions in Java as well. That Java class is working as a namespace. So, the function above is the same as the following free-standing function in D, C++, C, and many other languages:

  void Algo_drawLine(Canvas c, Pos from, Pos to) { ...... };

Ali

On Fri, Jan 20, 2023 at 01:32:22PM -0800, Ali Çehreli via Digitalmars-d-learn wrote:
> On 1/20/23 07:01, torhu wrote:
> 
> > But why not have drawLine just be a free function?
> 
> Exactly.
> 
> If I'm not mistaken, and please teach me if I am wrong, they are practically free functions in Java as well. That Java class is working as a namespace.

Exactly. Every time you see a static singleton class, you're essentially looking at a namespace. Only, in OO circles non-class namespaces are taboo, it's not OO-correct to call them what they are, instead you have to do lip service to OO by calling them static singleton classes instead.  And free functions are taboo in OO; OO doctrine declares them unclean affronts to OO purity and requires that you dress them in more OO-appropriate clothing, like putting them inside a namesp^W excuse me, static singleton class.

;-)


> So, the function above is the same as the following free-standing function in D, C++, C, and many other languages:
> 
>   void Algo_drawLine(Canvas c, Pos from, Pos to) { ...... };
[...]

That way of naming a global function is essentially a poor man's^W^Wexcuse me, I mean, C's way of working around the lack of a proper namespacing / module system. In D, we do have a proper module system, so you could just call the function `drawLine` and put it in a file named Algo.d, then you can just use D's symbol resolution rules to disambiguate between Algo.drawLine and PersonalSpace.drawLine, for example. :-P


T

-- 
Public parking: euphemism for paid parking. -- Flora

> That way of naming a global function is essentially a poor man's^W^Wexcuse me, I mean, C's way of working around the lack of a proper namespacing / module system. In D, we do have a proper module system, so you could just call the function `drawLine` and put it in a file named Algo.d, then you can just use D's symbol resolution rules to disambiguate between Algo.drawLine and PersonalSpace.drawLine, for example. :-P
>
>
> T

Again, stuffing it into a module is not the same thing as a namespace. The user can just bypass this by writing `drawLine`, there's nothing in the language currently that would 'force' the user to write in a namespace-like/static-class-like fashion, and that's the biggest problem.

On Monday, 23 January 2023 at 00:21:12 UTC, thebluepandabear wrote:
> there's nothing in the language currently that would 'force' the user

Why do you hate freedom?

On Monday, 23 January 2023 at 00:27:29 UTC, Adam D Ruppe wrote:
> On Monday, 23 January 2023 at 00:21:12 UTC, thebluepandabear wrote:
>> there's nothing in the language currently that would 'force' the user
>
> Why do you hate freedom?

It's not a freedom issue, it's a library-design issue. Some libraries want to incorporate a namespace-like design to force the user to be more 'explicit' with what they want.

SFML has a `Keyboard` namespace which has a `Key` enum.

The user is 'forced' (although I am not sure if this is the case since it's C++) to use the `Keyboard.` declaration before using the `Key` enum. Looking at code block 1 and 2, which makes more sense?

```C++
Keyboard::Key.A
```

```C++
Key.A
```

The first one does, because looking at the second one, the person who will read the code might be confused what 'Key' means, is it a car key, a set of keys for unlocking something, etc?

Now, the user doesn't have to use the library if they don't want to. There will be plenty of libraries out there that don't have namespaces.

I haven't been programming for a long time, but most of the other languages I used had such a namespace feature. Kotlin has something called an `object` which is essentially a namespace and it is great. The benefits of adding a namespace-like feature outweigh its costs, imo.