On 1/22/23 16:21, thebluepandabear wrote:

> Again, stuffing it into a module is not the same thing as a namespace.

That is correct but it is also one answer of D's to namespaces. There are others. For example, structs and classes provide namespacing as well.

> 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.

I agree with Adam here. The language should provide solutions and the programmer should pick appropriate ones.

Later you added that you were talking about library design. There is no problem in the library providing an awesome and very usable API but the programmers still picking some other method that works better for them.[1]

I would like to add to your C++ examples:

  Keyboard::Key.A    // Fine
  Key.A              // Fine
  foo                // Fine

That last line can exactly be the same as the previous two in C++.

OOP is always a solution where it makes sense. I've been very happy with writing free-standing functions and dumb data types that the functions operate on... until... some invariant matters. Then I make the function a member, etc.

Perhaps because I don't buy into the "everything is a class" anymore, I am very happy with D's approach. Mostly structs and functions for me. But I use classes as well when they make sense.

Having said all that, I realize that your asking specifically for static classes made me think of a solution around classes. However, doesn't D has the equivalent in structs? Isn't the following what you are looking for?

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

Now the user is forced to use it like this:

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

or this:

  Algo().drawLine(/* ... */);

but that can be @disabled.

Ali

[1] It is interesting that limiting the programmer in some way seems to help with language marketing. And D is deficient in that marketing move because it does the opposite: Gives the programmer choices. I tried to show this point on this slide: https://youtu.be/0JL9uT_XGZE?t=701 The point "not taking anything away from the programmer" can be seen as a marketing issue.

On Monday, 23 January 2023 at 00:36:36 UTC, thebluepandabear wrote:

>
> 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.

If you really want to, you can mostly force a namespace use like this:

```
// mylib/package.d
module mylib;
public static import mylib.impl.funcs;

// mylib/impl/funcs.d
module mylib.impl.funcs;

void foo() { }
```

Now when users import mylib, the public static import means hey call mylib.foo. Just don't bother documenting the impl subpackage and only those who look at the source will even know it exists.

I went through this same process when I first came to D years ago. D's modules *are* namespaces, and I wanted a way to force them. Eventually, I got over it. There's no reason to force a namespace. Namespaces are intended to disambiguate conflicting symbols. So let the users use them that way. There's no need to force them to type out the namespace all the time. It's certainly not an OOP vs. procedural issue, as namespaces have nothing to do with OOP.

> symbols. So let the users use them that way. There's no need to force them to type out the namespace all the time. It's certainly not an OOP vs. procedural issue, as namespaces have nothing to do with OOP.

Thanks, appreciate your perspective.

On Wednesday, 25 January 2023 at 15:43:46 UTC, ryuukk_ wrote:
>
> using static class and static function is not "OOP way" of doing things, it's a hack to mimic procedural style because Java doesn't have proper modules / scoping
>
> mimicking the shortcomings of Java is a bad idea imo
>
> D empowers you to write simple yet effective code, you should give it a try and embrace it

Classes (and this includes static classes) are 'one' means of encapsulation.

Encapsulation is related to, but independent of, object-oriented programming.

That is, you can do OOP without classes, and you can use classes and not do OOP.

So classes also 'empower' programmers ;-)

and btw. OOP also empowers programmers ;-)

There is no convincing argument that I have heard, ever, as to 'the one correct way' to go about dividing a program into independent parts.

On Saturday, 28 January 2023 at 23:19:35 UTC, ProtectAndHide wrote:
> On Wednesday, 25 January 2023 at 15:43:46 UTC, ryuukk_ wrote:
>>
>> using static class and static function is not "OOP way" of doing things, it's a hack to mimic procedural style because Java doesn't have proper modules / scoping
>>
>> mimicking the shortcomings of Java is a bad idea imo
>>
>> D empowers you to write simple yet effective code, you should give it a try and embrace it
>
> Classes (and this includes static classes) are 'one' means of encapsulation.

I hate a world with the classes. I can do almost anything I want without the classes. The software world soared above C without classes.

SDB@79

> I hate a world with the classes. I can do almost anything I want without the classes. The software world soared above C without classes.
>
> SDB@79

As I said in my email to you -- each to their own.

There's no point in arguing about whether OOP is the best method of doing things or procedural is, it's up to the person's personal preferences.

Personally, I like interfaces, I like abstract classes, I like inheritance, I like polymorphism. A lot of things can be done with pure structs, but sometimes that extra OOP stuff is needed too.

On Saturday, 28 January 2023 at 23:19:35 UTC, ProtectAndHide wrote:

> That is, you can do OOP without classes

How so? Every OOP definition includes classes (encapsulation + inheritance).

On Monday, 30 January 2023 at 06:09:56 UTC, RTM wrote:
> On Saturday, 28 January 2023 at 23:19:35 UTC, ProtectAndHide wrote:
>
>> That is, you can do OOP without classes
>
> How so? Every OOP definition includes classes (encapsulation + inheritance).

I didn't say you should do it, just that you can do it ;-)

The OO languages make it 'non-ugly' for you to do it.

But there is always 'an ugly way' to do it too:

http://www.cs.rit.edu/~ats/books/ooc.pdf