January 20, 2023

On Friday, 20 January 2023 at 11:28:23 UTC, thebluepandabear wrote:

>

Hi,

In Java/C# you can create purely static classes.

These are classes whose methods are all static, the classes cannot be derived from or instantiated:

static class Algo {
    void drawLine(Canvas c, Pos from, Pos to) { ...... };
}

Class in use:

Algo.drawLine(new Canvas(), new Pos(5, 3), new Pos(7, 9));

But why not have drawLine just be a free function?

import bluepandastuff.algo;

auto canvas = new Canvas();

drawLine(canvas, Pos(5, 3), Pos(7, 9));

// Or, using UFCS:
canvas.drawLine(Pos(5, 3), Pos(7, 9));

I turned Pos into a struct, seems like a typical value type to me.

January 20, 2023
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

January 20, 2023
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
January 22, 2023

On Friday, 20 January 2023 at 11:28:23 UTC, thebluepandabear wrote:

D is not java/C#, it's better than that!


// api.d

void draw(){}


// app.d

import API = api;


void main()
{
    API.draw();
}

January 23, 2023

On Sunday, 22 January 2023 at 18:30:59 UTC, ryuukk_ wrote:

>

On Friday, 20 January 2023 at 11:28:23 UTC, thebluepandabear wrote:

D is not java/C#, it's better than that!


// api.d

void draw(){}


// app.d

import API = api;


void main()
{
    API.draw();
}

Sorry don't like that solution specifically. That's because it is a procedural implementation, not an OOP-style one. I don't know how much of the D community writes procedurally but I'm personally an OOP-type of guy.

January 23, 2023

Something interesting.

I know that D has C++ SFML bindings, although they are unmaintained.

I was interested to see how they would 'implement' the C++ namespaces of SFML, and - boy was I surprised.

Reading through DSFML, I see final abstract class getting used to implement SFML's Keyboard namespace:

final abstract class Keyboard at https://github.com/Jebbs/DSFML/blob/master/src/dsfml/window/keyboard.d

It seems like using final abstract is the best solution.

January 23, 2023
>

// app.d

import API = api;

void main()
{
API.draw();
}

Another thing that I don't like about that solution, is that it doesn't 'force' the user to write in a namespace-like style.

C++ namespaces force you to (I believe), and so does static class from Java/C#.

D is both an object oriented and procedural language, I would honestly love to see some sort of namespace or static class feature come into the language. I know that it's controversial here, but I would honestly think it would help develop the language in a good way. But that's just my opinion.

January 23, 2023
> 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.
January 23, 2023
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?
January 23, 2023
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.