www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Non-ugly ways to implement a 'static' class or namespace?

reply thebluepandabear <therealbluepandabear protonmail.com> writes:
Hi,



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));
```

This type of semantics is not possible in D, which sucks.

After scouring the forums, the only workaround seems to be the 
following:

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

This solution seems like a bit of a hack, which is why I don't 
like it.

Alternatively you could create a module, but then it would just 
be a function without a clear type.

Is anyone aware of a non-ugly way to implement a 'static' class 
or namespace?

Regards,
thebluepandabear
Jan 20 2023
next sibling parent reply Ruby The Roobster <rubytheroobster yandex.com> writes:
On Friday, 20 January 2023 at 11:28:23 UTC, thebluepandabear 
wrote:

 Hi,



 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));
 ```

 This type of semantics is not possible in D, which sucks.

 After scouring the forums, the only workaround seems to be the 
 following:

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

 This solution seems like a bit of a hack, which is why I don't 
 like it.

 Alternatively you could create a module, but then it would just 
 be a function without a clear type.

 Is anyone aware of a non-ugly way to implement a 'static' class 
 or namespace?

 Regards,
 thebluepandabear


There is no way to implement that functionality in D.  `final` 
means that the class cannot be extended, and `abstract` requires 
that only an extension of said class can be instantiated.  

without instantiating said class, as functions act on the class 
object.
Jan 20 2023
next sibling parent Ruby The Roobster <rubytheroobster yandex.com> writes:
On Friday, 20 January 2023 at 12:55:37 UTC, Ruby The Roobster 
wrote:

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

 There is no way to implement that functionality in D.  `final` 
 means that the class cannot be extended, and `abstract` 
 requires that only an extension of said class can be 

 a function without instantiating said class, as functions act 
 on the class object.


Also, there is a `static` keyword, but a `static class` can be 
instantiated as a member of the external class.
Jan 20 2023
prev sibling parent reply thebluepandabear <therealbluepandabear protonmail.com> writes:
ll

 a function without instantiating said class, as functions act 
 on the class object.


Ok, thanks.

I think D should implement something similar to `static class` 
but I doubt it will happen.
Jan 20 2023
parent reply Ruby The Roobster <rubytheroobster yandex.com> writes:
On Friday, 20 January 2023 at 13:03:18 UTC, thebluepandabear 
wrote:

 ll

 a function without instantiating said class, as functions act 
 on the class object.


 Ok, thanks.

 I think D should implement something similar to `static class` 
 but I doubt it will happen.


D isn't Java, and never will be.  If you want similar 
functionality, you put the functions in a separate file, and add 
the line to the top of it:

```d
module modulename;
```

and title the file modulename.d.  Then you can use this module as 
a .class file in java by adding

```d
import modulename;
```

to the file that uses it.
Jan 20 2023
parent reply evilrat <evilrat666 gmail.com> writes:
On Friday, 20 January 2023 at 13:17:05 UTC, Ruby The Roobster 
wrote:

 On Friday, 20 January 2023 at 13:03:18 UTC, thebluepandabear 
 wrote:

 ll

 a function without instantiating said class, as functions act 
 on the class object.


 Ok, thanks.

 I think D should implement something similar to `static class` 
 but I doubt it will happen.


 D isn't Java, and never will be.  If you want similar 
 functionality, you put the functions in a separate file, and 
 add the line to the top of it:

 ```d
 module modulename;
 ```

 and title the file modulename.d.  Then you can use this module 
 as a .class file in java by adding

 ```d
 import modulename;
 ```

 to the file that uses it.


Also there is various import options such as renamed import or 
static import(doesn't add module to a scope thus requiring to 
fully qualify it)

static import, can be used to somewhat mimic namespaces, more 
complex scenario would be making a module consisting of public 
imports to group things together, but I don't think it is common 
in D.
https://dlang.org/spec/module.html#static_imports

```d
static import std.stdio;

void main()
{
   // nope, this function will not be resolved, compilation error
   // wrtiteln("hello");

   // ok
   std.stdio.writeln("hello");
}
```
Jan 20 2023
parent Ruby The Roobster <rubytheroobster yandex.com> writes:
On Friday, 20 January 2023 at 13:38:47 UTC, evilrat wrote:

 On Friday, 20 January 2023 at 13:17:05 UTC, Ruby The Roobster 
 ...
 [snip]

 Also there is various import options such as renamed import or 
 static import(doesn't add module to a scope thus requiring to 
 fully qualify it)

 static import, can be used to somewhat mimic namespaces, more 
 complex scenario would be making a module consisting of public 
 imports to group things together, but I don't think it is 
 common in D.
 https://dlang.org/spec/module.html#static_imports

 ```d
 static import std.stdio;

 void main()
 {
   // nope, this function will not be resolved, compilation error
   // wrtiteln("hello");

   // ok
   std.stdio.writeln("hello");
 }
 ```


I never knew that there even WAS a `static import` option.  Good 
to know.
Jan 20 2023
prev sibling next sibling parent reply Hipreme <msnmancini hotmail.com> writes:
On Friday, 20 January 2023 at 11:28:23 UTC, thebluepandabear 
wrote:

 Hi,



 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) { ...... };
 }
 ```



There are 2 solutions for that. One involved doing a private 
implementation:

```d
module drawer.impl;
void drawLine(...)
```

Then, you create another file:

```d
module drawer;
public import Algo = drawer.impl;
```
After that, you can use it as `Algo.drawLine`.


With a single file, you can do:
```d

final class Algo
{
      disable this();
     static:
     void drawLine(...){}
}
```
Jan 20 2023
parent Ruby The Roobster <rubytheroobster yandex.com> writes:
On Friday, 20 January 2023 at 13:38:52 UTC, Hipreme wrote:

 On Friday, 20 January 2023 at 11:28:23 UTC, thebluepandabear 
 wrote:
 ...
 [snip]

 With a single file, you can do:
 ```d

 final class Algo
 {
      disable this();
     static:
     void drawLine(...){}
 }
 ```


This also works, but it dissimilar to Java in that in Java, each 
class gets its own file.
Jan 20 2023
prev sibling next sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 1/20/23 6:28 AM, thebluepandabear wrote:


 This type of semantics is not possible in D, which sucks.


Well, static methods do exactly this.

If you want to disable class creation, then use ` disable this();`, if 
you want to make all methods static, put `static:` at the top of the class.

Note that at this point, the class becomes a namespace. You can use a 
template as a namespace as well, though it can be a bit ugly:

```d
template Algo_ns()
{
    void drawLine(Canvas c, Pos from, Pos to) {...}
}

// need this to avoid the instantiation syntax
alias Algo = Algo_ns!();
```

The benefit here is that other things that classes do (generate 
typeinfo, add to the type system, etc.) would be wasted, so this is not 
done for a template.

-Steve
Jan 20 2023
prev sibling next sibling parent reply torhu <torhu yahoo.com> writes:
On Friday, 20 January 2023 at 11:28:23 UTC, thebluepandabear 
wrote:

 Hi,



 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.
Jan 20 2023
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
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
Jan 20 2023
parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
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
Jan 20 2023
parent reply thebluepandabear <therealbluepandabear protonmail.com> writes:
 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.
Jan 22 2023
next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
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?
Jan 22 2023
parent reply thebluepandabear <therealbluepandabear protonmail.com> writes:
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.
Jan 22 2023
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
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.
Jan 22 2023
parent thebluepandabear <therealbluepandabear protonmail.com> writes:
 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.
Jan 24 2023
prev sibling parent reply Kagamin <spam here.lot> writes:
On Monday, 23 January 2023 at 00:36:36 UTC, thebluepandabear 
wrote:

 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?


Pretty sure you can strip namespaces in any language that has 

their nonqualified names. It even has Keys enum: 
https://learn.microsoft.com/en-us/dotnet/api/system.windows.forms.keys which is
referred to as Keys after stripping the System.Windows.Forms namespace.
Feb 10 2023
parent Kagamin <spam here.lot> writes:
On Friday, 10 February 2023 at 14:17:25 UTC, Kagamin wrote:

 Pretty sure you can strip namespaces in any language that has 

 their nonqualified names. It even has Keys enum: 
 https://learn.microsoft.com/en-us/dotnet/api/system.windows.forms.keys which
is referred to as Keys after stripping the System.Windows.Forms namespace.


An example from KeePass: 
https://github.com/dlech/KeePass2.x/blob/VS2022/KeePass/Util/SendInputExt/SiCodes.cs#L86
Feb 10 2023
prev sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
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.
Jan 22 2023
parent GrimMaple <grimmaple95 gmail.com> writes:
On Monday, 23 January 2023 at 01:28:30 UTC, Ali Çehreli wrote:


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


Then just add `static class`, as it will provide a solution 
without robbing you of another solution. You still can put 
symbols in a module even if `static class` is a thing. `static 
class` doesn't break existing solutions, it just adds things on 
top.



 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.


Good. Now, let people have OOP and "everything is a class" if 
they want to.


 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.


I think it's better to have a widespread commonly known solution 
than hacks that you have to specifically look for. D is guilty 
with having too many hacks that you have to specifically learn 
about.
Feb 08 2023
prev sibling next sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Friday, 20 January 2023 at 11:28:23 UTC, thebluepandabear 
wrote:





```D

// api.d

void draw(){}


// app.d

import API = api;


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

```
Jan 22 2023
next sibling parent reply thebluepandabear <therealbluepandabear protonmail.com> writes:
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

 // 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.
Jan 22 2023
next sibling parent thebluepandabear <therealbluepandabear protonmail.com> writes:
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.
Jan 22 2023
prev sibling next sibling parent Mike Parker <aldacron gmail.com> writes:
On Monday, 23 January 2023 at 00:11:17 UTC, thebluepandabear 
wrote:


 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.


A class full of static methods is not OOP either.
Jan 22 2023
prev sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Monday, 23 January 2023 at 00:11:17 UTC, thebluepandabear 
wrote:

 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

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


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
Jan 25 2023
parent reply ProtectAndHide <ProtectAndHide gmail.com> writes:
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.
Jan 28 2023
next sibling parent reply Salih Dincer <salihdb hotmail.com> writes:
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
Jan 29 2023
parent thebluepandabear <therealbluepandabear protonmail.com> writes:
 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.
Jan 29 2023
prev sibling parent reply RTM <riven baryonides.ru> writes:
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).
Jan 29 2023
next sibling parent reply ProtectAndHide <ProtectAndHide gmail.com> writes:
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
Jan 30 2023
parent RTM <riven baryonides.ru> writes:
On Monday, 30 January 2023 at 08:20:21 UTC, ProtectAndHide wrote:


 But there is always 'an ugly way' to do it too:
 http://www.cs.rit.edu/~ats/books/ooc.pdf


Yep, but it’s not OOP per se, just a form of lowering. First CPP 
implementation was a cross-compiled one.
Jan 30 2023
prev sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 1/29/23 22:09, RTM wrote:

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


 That is, you can do OOP without classes


 How so?


OOP is about putting objects (data) and behavior (functions) together.


 Every OOP definition includes classes


OOP is possible in C, which does not have classes:

   void sing(Animal * animal);

That top-level sing function will do something like this:

   animal->sing(animal);

Every object has their own sing function pointer as a member. (Or one 
can go to a vtbl pointer approach with different pros and cons; I used 
all of this as an interview topic at some point.)

Programming languages just make it easy.


 (encapsulation + inheritance).


Encapsulation is available even in C as well. Inheritance can be 
achieved manually.

And I used C just because it does not provide any special OOP features.

Ali
Jan 30 2023
prev sibling parent thebluepandabear <therealbluepandabear protonmail.com> writes:
 // 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 


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.
Jan 22 2023
prev sibling next sibling parent reply Nick Treleaven <nick geany.org> writes:
On Friday, 20 January 2023 at 11:28:23 UTC, thebluepandabear 
wrote:

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

 This solution seems like a bit of a hack, which is why I don't 
 like it.


Interesting solution if you put `static:` in there.


 Alternatively you could create a module, but then it would just 
 be a function without a clear type.


Why do you want a type?


 Is anyone aware of a non-ugly way to implement a 'static' class 
 or namespace?


Use a struct and put `static:` after the opening brace. That's 
what GC is in core.memory.
Jan 30 2023
next sibling parent reply thebluepandabear <therealbluepandabear protonmail.com> writes:
 Use a struct and put `static:` after the opening brace. That's 
 what GC is in core.memory.


Using a `struct` for a purely static type would still allow the 
user to create instances of that `struct`. To bypass that, you'd 
have to disable the default constructor -- that then becomes 
ugly, hackish code.
Jan 30 2023
parent reply thebluepandabear <therealbluepandabear protonmail.com> writes:
On Monday, 30 January 2023 at 21:50:03 UTC, thebluepandabear 
wrote:

 Use a struct and put `static:` after the opening brace. That's 
 what GC is in core.memory.


 Using a `struct` for a purely static type would still allow the 
 user to create instances of that `struct`. To bypass that, 
 you'd have to disable the default constructor -- that then 
 becomes ugly, hackish code.


Looking at the GC code found   
https://github.com/dlang/dmd/blob/master/druntime/src/core/memory.d, it seems
like they have disabled the default constructor:

```D
struct GC
{
      disable this();
     ...
}
```

Interesting, so maybe there is a use case for a purely static 
type or namespace?

The standard library as well uses `final abstract class` a couple 
of times, which can also be thought as a type of namespace.

All these 'hacks' to workaround a namespace-like feature are ... 
interesting... So maybe such a feature would help the language?

Just askin questions!
Jan 30 2023
parent reply ProtectAndHide <ProtectAndHide gmail.com> writes:
On Monday, 30 January 2023 at 21:54:49 UTC, thebluepandabear 
wrote:

 ...
 Interesting, so maybe there is a use case for a purely static 
 type or namespace?

 The standard library as well uses `final abstract class` a 
 couple of times, which can also be thought as a type of 
 namespace.

 All these 'hacks' to workaround a namespace-like feature are 
 ... interesting... So maybe such a feature would help the 
 language?

 Just askin questions!




(i.e. you mark it as static, or whatever, and all the following 
then applies:
- Is sealed
- Cannot be instantiated or contain Instance Constructors.
- must contain only static members.

btw, it seems 'static' applied to class at the module level, in 
D, means nothing at all??

btw. Discovered that D has support for static constructors, which 
I didn't know.

Below is not that 'ugly', really, but I certainly prefer the 


// cannot inherit from, since it is final.
// cannot instantiate it with 'new', since it is annotated with 
 disable
//
//  NOTE: static here is meaningless and can be removed.
static final class Algo
{
      disable this();

     static this()
     {
         Message =  "Hello!";
     }

     static:

     string Message;

     void drawLine() {};
}
Feb 05 2023
parent reply thebluepandabear <therealbluepandabear protonmail.com> writes:
 {
      disable this();

     static this()
     {
         Message =  "Hello!";
     }

     static:

     string Message;

     void drawLine() {};
 }


It's not a terrible workaround to be honest.

`static class` does have a use when it's nested, so it might 

were added.

Due to the mindset of the current maintainers of the language, I 
doubt we will see such a thing. Maybe in 10-20 years something 
will change and the language will add a static class or namespace 
feature, for now we'll have to deal with modules or using your 
way of creating a `static class`.
Feb 05 2023
next sibling parent reply thebluepandabear <therealbluepandabear protonmail.com> writes:
On Sunday, 5 February 2023 at 10:51:51 UTC, thebluepandabear 
wrote:

 {
      disable this();

     static this()
     {
         Message =  "Hello!";
     }

     static:

     string Message;

     void drawLine() {};
 }


 It's not a terrible workaround to be honest.

 `static class` does have a use when it's nested, so it might 

 class`) were added.

 Due to the mindset of the current maintainers of the language, 
 I doubt we will see such a thing. Maybe in 10-20 years 
 something will change and the language will add a static class 
 or namespace feature, for now we'll have to deal with modules 
 or using your way of creating a `static class`.


I don't like it when people see modules as a replacement for a 
namespace/static class, when that's not the case.

Rust has modules. It also has namespaces.

C++ will be getting modules, it also has namespaces.

When dealing with contexts, or for when you want a clear context 
in your codebase, namespaces can be a life saver, we've seen it 
used in the D library, so there's no excuse for why this 
shouldn't be added, in my opinion.
Feb 05 2023
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 2/5/23 02:57, thebluepandabear wrote:


 When dealing with contexts, or for when you want a clear context in your
 codebase, namespaces can be a life saver


Can you give an example of a D problem that namespaces could solve? I 
have been with D for 14 years and haven't missed namespaces from C++ ever.

The reason I ask is, mentioning lack of features of other programming 
languages is not the right way to go. We have to understand what problem 
they were trying to solve with that feature and then see how D already 
tackels it.

In this case, it is namespacing and D solves it with the following 
feature and perhaps others that I can't think of:

- modules
- structs
- classes
- templates

I don't consider myself a maintainer of D but I don't agree that yet 
another feature for namespacing is needed. I feel that it would bring 
complications.

I don't think it is practical to bring all features of all languages 
into D or any other language.


 we've seen it used in the D
 library, so there's no excuse for why this shouldn't be added, in my
 opinion.


If I'm not mistaken you've counted five such instances. Were they really 
necessary? Could they be coded in a different way? What is the cost of 
missing namespaces? I think you are the first person raising this issue.

You must have a strong case for this feature; so, I recommend you write 
a DIP for it. It is likely that the mere act of doing that will expose 
hidden costs and usage problems.

Ali
Feb 05 2023
parent thebluepandabear <therealbluepandabear protonmail.com> writes:
On Sunday, 5 February 2023 at 23:50:35 UTC, Ali Çehreli wrote:

 On 2/5/23 02:57, thebluepandabear wrote:


 When dealing with contexts, or for when you want a clear


 context in your

 codebase, namespaces can be a life saver


 Can you give an example of a D problem that namespaces could 
 solve? I have been with D for 14 years and haven't missed 
 namespaces from C++ ever.

 The reason I ask is, mentioning lack of features of other 
 programming languages is not the right way to go. We have to 
 understand what problem they were trying to solve with that 
 feature and then see how D already tackels it.

 In this case, it is namespacing and D solves it with the 
 following feature and perhaps others that I can't think of:

 - modules
 - structs
 - classes
 - templates

 I don't consider myself a maintainer of D but I don't agree 
 that yet another feature for namespacing is needed. I feel that 
 it would bring complications.

 I don't think it is practical to bring all features of all 
 languages into D or any other language.


 we've seen it used in the D
 library, so there's no excuse for why this shouldn't be


 added, in my

 opinion.


 If I'm not mistaken you've counted five such instances. Were 
 they really necessary? Could they be coded in a different way? 
 What is the cost of missing namespaces? I think you are the 
 first person raising this issue.

 You must have a strong case for this feature; so, I recommend 
 you write a DIP for it. It is likely that the mere act of doing 
 that will expose hidden costs and usage problems.

 Ali


I'm not going to create a DIP when I've hardly even touched the 
surface of the language, this is a beginners forum. I would need 
to wait 3-5 years until I'd feel comfortable doing so. Right now, 
it's not my place to be doing such things; this is just an 
observation from a beginner (aka me).
Feb 05 2023
prev sibling parent reply ProtectAndHide <ProtectAndHide gmail.com> writes:
On Sunday, 5 February 2023 at 10:51:51 UTC, thebluepandabear 
wrote:

 It's not a terrible workaround to be honest.
 ....


The 'terrible' part is this:

- the compiler will allow you to declare a variable of type Algo
- the compiler will allow you to declare an array with elements 
of type Algo
- the compiler will allow you to use Algo as a type argument
- the compiler will allow you to use Algo as a parameter
- the compiler will allow you to use Algo as a return type
Feb 05 2023
next sibling parent ProtectAndHide <ProtectAndHide gmail.com> writes:
On Sunday, 5 February 2023 at 22:40:09 UTC, ProtectAndHide wrote:

 ..



module test;

import std;

static final class Algo
{
      disable this();

     static this()
     {
         Message =  "Hello!";
     }

     static:

     string Message;

     void drawLine() {};
}

void main()
{
     Algo foo1 = null; // the compiler should not allow you to 
declare a variable of static type
     Algo[] foo2 = null; //  the compiler should not allow you to 
declare an array with elements of static type
     List[Algo] foo3; // the compiler should not allow you to use 
static types as type arguments

     writeln(foo1);
     writeln(foo2);
     writeln(foo3);
}

void Method1(Algo x) {} //  the compiler should not allow you to 
use static types as parameters

Algo Method2() { return null; } // the compiler should not allow 
you to use static types as return types

struct List {}
Feb 05 2023
prev sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 2/5/23 14:40, ProtectAndHide wrote:


 On Sunday, 5 February 2023 at 10:51:51 UTC, thebluepandabear wrote:

 It's not a terrible workaround to be honest.
 ....


 The 'terrible' part is this:

 - the compiler will allow you to declare a variable of type Algo
 - the compiler will allow you to declare an array with elements of type
 Algo
 - the compiler will allow you to use Algo as a type argument
 - the compiler will allow you to use Algo as a parameter
 - the compiler will allow you to use Algo as a return type


I understand disabling the programmer to do certain things are 
beneficial e.g. to prevent bugs but those above can all be seen as 
features. What is so terrible about giving the programmer those powers?

Ali
Feb 05 2023
next sibling parent reply thebluepandabear <therealbluepandabear protonmail.com> writes:
On Sunday, 5 February 2023 at 23:53:35 UTC, Ali Çehreli wrote:

 On 2/5/23 14:40, ProtectAndHide wrote:


 On Sunday, 5 February 2023 at 10:51:51 UTC, thebluepandabear


 wrote:

 It's not a terrible workaround to be honest.
 ....


 The 'terrible' part is this:

 - the compiler will allow you to declare a variable of type


 Algo

 - the compiler will allow you to declare an array with


 elements of type

 Algo
 - the compiler will allow you to use Algo as a type argument
 - the compiler will allow you to use Algo as a parameter
 - the compiler will allow you to use Algo as a return type


 I understand disabling the programmer to do certain things are 
 beneficial e.g. to prevent bugs but those above can all be seen 
 as features. What is so terrible about giving the programmer 
 those powers?

 Ali


I don't see why you'd want to expose a static class/namespace as 
a variable, or any of such similar things. That would give no 
benefits to the programmer?
Feb 05 2023
parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 2/5/23 17:50, thebluepandabear wrote:


 I don't see why you'd want


I am not saying it would be wanted or needed.


 to expose a static class/namespace as a
 variable, or any of such similar things. That would give no benefits to
 the programmer?


Perhaps. As I responded to ProtectAndHide, if there is a benefit then it 
is useful by definition; if there is no benefit then it wouldn't be used 
anyway.

Ali
Feb 06 2023
prev sibling next sibling parent reply ProtectAndHide <ProtectAndHide gmail.com> writes:
On Sunday, 5 February 2023 at 23:53:35 UTC, Ali Çehreli wrote:

 On 2/5/23 14:40, ProtectAndHide wrote:


 On Sunday, 5 February 2023 at 10:51:51 UTC, thebluepandabear


 wrote:

 It's not a terrible workaround to be honest.
 ....


 The 'terrible' part is this:

 - the compiler will allow you to declare a variable of type


 Algo

 - the compiler will allow you to declare an array with


 elements of type

 Algo
 - the compiler will allow you to use Algo as a type argument
 - the compiler will allow you to use Algo as a parameter
 - the compiler will allow you to use Algo as a return type


 I understand disabling the programmer to do certain things are 
 beneficial e.g. to prevent bugs but those above can all be seen 
 as features. What is so terrible about giving the programmer 
 those powers?

 Ali


I do not agree, that a compiler that allows a programmer to 
misuse a type, should be seen as 'a feature'.

If that's the kind of 'power' D programmers want, then D is not 
for me.
Feb 05 2023
next sibling parent thebluepandabear <therealbluepandabear protonmail.com> writes:
 I do not agree, that a compiler that allows a programmer to 
 misuse a type, should be seen as 'a feature'.

 If that's the kind of 'power' D programmers want, then D is not 
 for me.


Eh, I don't think I would _quit_ D because of this issue, but 
it's definitely something that bothers me (more so the lack of an 
ecosystem) especially since I come from a .NET/JVM background. 
I'm pretty shocked this isn't a feature tbh.
Feb 05 2023
prev sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 2/5/23 18:15, ProtectAndHide wrote:


 I do not agree, that a compiler that allows a programmer to misuse a
 type


Types normally have objects. If a programmer found a way to use objects 
of a memberless type why stop them?


 should be seen as 'a feature'.


I am not saying I already see those uses as features. I am questioning 
why the compiler should ban certain features. Rather, why would a 
programmer decide that another programmer should not have objects of a 
certain type?



wanted to have such a thing. For all I know, they wanted something else 
(namespacing in this case) and implemented it as 'static class'.


that I don't know yet. What is that semantics? How does D already solve 
that?


 If that's the kind of 'power' D programmers want,


The trait here is orthogonality: Let's say A, B, C, etc. are features of 
a language. Some combination of those features work together for various 
reasons.

On the other hand, some combinations may not work well and people don't 
or can't use them for various reasons:

- The language may ban them because there may be dangerous ambiguities 
with that combination

- There may be technical impossibilities for that combination

- That combination can have no agreeable semantics (your earlier 
examples are in this category)

- People would never think about that combination (to me, at least some 
of your examples are in this category)

- People may decide not to use that combination in coding guidelines

- etc.

So, what I am understanding is that thebluepandabear and you are asking 
the compiler to ban certain combinations. For example, using a struct 
for namespacing (A) and being able to create objects (B) used together 
should not be allowed.

What other combinations can we come up with for such a list? As you 
said, certain uses of the 'static' keyword at module scope has no effect 
in D ('statis this' and 'shared static this' should be considered 
multi-word keywords and I think 'static const' has a meaning). Should 
the D spec enumerate all ineffective uses of 'static' (and others) and 
ban them? I don't agree.

In contrast, D delivers some features in an unprincipled way and the 
programmers use combinations of those features the way the see fit.

I really don't care if D had 'static class' to be used only as a 
namespace but I don't see how this issue is terrible. If the programmers 
ever need to use a struct (or a class) for namespacing then they 
wouldn't need objects of such types either. So, they wouldn't do that.

Ali
Feb 06 2023
parent reply ProtectAndHide <ProtectAndHide gmail.com> writes:
On Monday, 6 February 2023 at 08:26:45 UTC, Ali Çehreli wrote:

 ....
 In contrast, D delivers some features in an unprincipled way 
 and the programmers use combinations of those features the way 
 the see fit.


I agree, that D is unprincipled in many ways, and this is perhaps 
the biggest surprise for new comers from other 'principled' 
programming languages.

But is that a design goal for D?


 I really don't care if D had 'static class' to be used only as 
 a namespace but I don't see how this issue is terrible....



you've used them many times, and you'll continue to use them.


programmers would find it easier to migrate code to D, perhaps. 
That's not a request, just an observation. And no, I'm not going 
to 'go write a DIP'.

Of course, if I was talking about migrating C code, you'd all be 
stumbling over yourselves to make that happen - .. build it, and 
they still won't come ;-)
Feb 06 2023
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 07/02/2023 9:56 AM, ProtectAndHide wrote:

 On Monday, 6 February 2023 at 08:26:45 UTC, Ali Çehreli wrote:

 ....
 In contrast, D delivers some features in an unprincipled way and the 
 programmers use combinations of those features the way the see fit.


 
 I agree, that D is unprincipled in many ways, and this is perhaps the 
 biggest surprise for new comers from other 'principled' programming 
 languages.
 
 But is that a design goal for D?


Yes. Not all problems are best solved the same way as another.

Use what is best for you & your problem domain, not what somebody is 
selling as the next big thing.
Feb 06 2023
parent reply ProtectAndHide <ProtectAndHide gmail.com> writes:
On Monday, 6 February 2023 at 21:02:13 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 On 07/02/2023 9:56 AM, ProtectAndHide wrote:

 On Monday, 6 February 2023 at 08:26:45 UTC, Ali Çehreli wrote:

 ....
 In contrast, D delivers some features in an unprincipled way 
 and the programmers use combinations of those features the 
 way the see fit.


 
 I agree, that D is unprincipled in many ways, and this is 
 perhaps the biggest surprise for new comers from other 
 'principled' programming languages.
 
 But is that a design goal for D?


 Yes. Not all problems are best solved the same way as another.

 Use what is best for you & your problem domain, not what 
 somebody is selling as the next big thing.


Well I don't agree that D should boast about things that's its 
implemented in an unprincipled way. I find that a strange form of 
marketing in todays world.

To the extent those unprincipled implementations allow you to do 
things that you do actually want to do, then fine.. maybe. But an 
unprincipled implementation of something that just allows you do 
make mistakes, then it should be looked at further, so see if it 
can be improved.
Feb 06 2023
parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 2/6/23 23:45, ProtectAndHide wrote:


 Well I don't agree that D should boast about things that's its
 implemented in an unprincipled way.


Here, "unprincipled"[1] is just a descriptive word meaning that D does 
not insist on certain software engineering methodologies e.g. unlike 
Java where "everything is a class" or unlike some functional programming 
languages where "everything must be immutable".[2]


 an unprincipled
 implementation of something that just allows you do make mistakes, then
 it should be looked at further, so see if it can be improved.


Agreed. But the lack of 'static class' in D or its approximations are 
not in that category. I can imagine someone coming up ingeniously with a 
harmful way of using 'static class' but unless that is a real problem 
that affects D users then there is no issue.

Ali

[1] I remember reading or hearing "unprincipled" from Andrei 
Alexandrescu long time ago.

[2] Actually, const and immutable being transitive can be seen as 
counter examples of D having a strong point on something. I think this 
"turtles all the way down" is not agreed by many users.
Feb 07 2023
prev sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 2/6/23 12:56, ProtectAndHide wrote:


 I'm not going to 'go write a
 DIP'.


Nobody will write a DIP about it because very few people ever mentioned 
this issue over the years.

And as 'static class' and 'static struct' are already usable in D, a 
newcomer would definitely be confused with your "terrible" conclusion.

Ali
Feb 06 2023
parent reply ProtectAndHide <ProtectAndHide gmail.com> writes:
On Monday, 6 February 2023 at 21:46:29 UTC, Ali Çehreli wrote:

 On 2/6/23 12:56, ProtectAndHide wrote:


 I'm not going to 'go write a
 DIP'.


 Nobody will write a DIP about it because very few people ever 
 mentioned this issue over the years.

 And as 'static class' and 'static struct' are already usable in 
 D, a newcomer would definitely be confused with your "terrible" 
 conclusion.

 Ali


You being a little agressive don't you think?

My observation is very reasonable, and correct, and a new comer 
to D would do well to know that:

The compiler will allow you to do all these things, even if 
you've  disable'd' the constructor, and have only static members:

- the compiler will allow you to declare a variable of that type
- the compiler will allow you to declare an array with elements 
of that type
- the compiler will allow you to use that type as a type argument
- the compiler will allow you to use that type as a parameter
- the compiler will allow you to use that type as a return type

I can see no reason why anyone would want to do these things, in 
this context.

Nor can I see any reason, whatsoever, why the compiler would 
allow you to do these things, in this context.

It's not about me trying to remove power from the programmer. 
That's a nonsense argument, without any basis, whatsoever. It's 
just a (correct) observation.

Further comments that try to derail this will be ignored.
Feb 06 2023
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 2/6/23 23:33, ProtectAndHide wrote:

 On Monday, 6 February 2023 at 21:46:29 UTC, Ali Çehreli wrote:



 And as 'static class' and 'static struct' are already usable in D, a
 newcomer would definitely be confused with your "terrible" conclusion.





 You being a little agressive don't you think?


I see how wrong that came out. Apologies! What I meant was "your 
conclusion [about something here being] terrible".


 My observation is very reasonable, and correct,


Agreed.


 The compiler will allow you to do all these things


Agreed.


 I can see no reason why anyone would want to do these things, in this
 context.


Agreed.


 Nor can I see any reason, whatsoever, why the compiler would allow you
 to do these things, in this context.


My understanding is that these are side-effects of trying to have 
orthogonal features. Some combinations don't make sense.

Having said that, since D does not use 'static class' for namespacing, 
should it go out of its way to implement logic to ban that combination 
at module scope? Perhaps. People have been discovering meaningless 
combinations of attributes in D all the time. (I forgot why that is so.)

If D disallowed 'static' at module scope, we wouldn't be having this 
discussion anyway. If that happened, then 'class' would be accepted for 
being used for creating objects.

Ali
Feb 07 2023
parent reply ProtectAndHide <ProtectAndHide gmail.com> writes:
On Tuesday, 7 February 2023 at 16:16:48 UTC, Ali Çehreli wrote:

 On 2/6/23 23:33, ProtectAndHide wrote:

 On Monday, 6 February 2023 at 21:46:29 UTC, Ali Çehreli wrote:



 And as 'static class' and 'static struct' are already usable




 in D, a

 newcomer would definitely be confused with your "terrible"




 conclusion.


 You being a little agressive don't you think?


 I see how wrong that came out. Apologies! What I meant was 
 "your conclusion [about something here being] terrible".


 My observation is very reasonable, and correct,


 Agreed.


 The compiler will allow you to do all these things


 Agreed.


 I can see no reason why anyone would want to do these things,


 in this

 context.


 Agreed.


 Nor can I see any reason, whatsoever, why the compiler would


 allow you

 to do these things, in this context.


 My understanding is that these are side-effects of trying to 
 have orthogonal features. Some combinations don't make sense.

 Having said that, since D does not use 'static class' for 
 namespacing, should it go out of its way to implement logic to 
 ban that combination at module scope? Perhaps. People have been 
 discovering meaningless combinations of attributes in D all the 
 time. (I forgot why that is so.)

 If D disallowed 'static' at module scope, we wouldn't be having 
 this discussion anyway. If that happened, then 'class' would be 
 accepted for being used for creating objects.

 Ali


Well, in C++ I can just mark the destructor as = delete;

The compiler now won't let me do those things that D would allow.

D could do something similar I guess, with:  disable ~this();

In fact, a static class is a very useful abstraction.


without all the nonsense other languages require. In addition, 

I want from a compiler ;-)

When a compiler allows nonsense code, my confidence in it begins 
to wane...
Feb 07 2023
parent reply thebluepandabear <therealbluepandabear protonmail.com> writes:

 such, without all the nonsense other languages require. In 

 exactly what I want from a compiler ;-)


Java as well.
Feb 08 2023
parent thebluepandabear <therealbluepandabear protonmail.com> writes:
On Wednesday, 8 February 2023 at 09:00:40 UTC, thebluepandabear 
wrote:


 such, without all the nonsense other languages require. In 

 exactly what I want from a compiler ;-)


 Java as well.


Wait nvm
Feb 08 2023
prev sibling parent ProtectAndHide <ProtectAndHide gmail.com> writes:
On Sunday, 5 February 2023 at 23:53:35 UTC, Ali Çehreli wrote:

 I understand disabling the programmer to do certain things are 
 beneficial e.g. to prevent bugs but those above can all be seen 
 as features. What is so terrible about giving the programmer 
 those powers?

 Ali


Interestingly, in Swift, you cannot (as far as I can tell) 
disable init() like you can in D. Thus you cannot prevent the 
programmer from creating an instance of a class.



That leaves the question of why 'any' programming language would 
allow you to instantiate a class that has only static members. 
What exactly are you going to do with that instance? (i.e. there 
are no 'instance' members, just 'type' members).

At least in D you CAN disable the initialiser with  disable.

But even after you've done that, the compiler still:
- allows you to declare a variable of that type
- allows you to declare an array with elements of that type
- allows you to use that type as a type argument
- allows you to use that type as a parameter
- allows you to use that type as a return type

So, getting back to your statement.. under what circumstance 
would a programmer want the 'power' to do any or all of this 
things, if the programmer has explicately disabled the 
initialiser, and the type has only static 'type' members?
Feb 05 2023
prev sibling parent thebluepandabear <therealbluepandabear protonmail.com> writes:
 Why do you want a type?


I want a type because it gives clear context as to what family 
the method(s) belongs to, and helps make the code more idiomatic 
and easy to understand.
Jan 30 2023
prev sibling parent reply zjh <fqbqrr 163.com> writes:
On Friday, 20 January 2023 at 11:28:23 UTC, thebluepandabear 
wrote:

 Hi,


 ...




Last time, someone proposed to add `private` like `C++'s`, and 
then it was the same,they are always unwilling to add facilities 
useful to others, and then he left `D`.
Feb 08 2023
next sibling parent reply zjh <fqbqrr 163.com> writes:
On Wednesday, 8 February 2023 at 12:07:35 UTC, zjh wrote:

 they are always unwilling to add facilities useful to others,



`D`'s community is small, this is the reason!
Feb 08 2023
next sibling parent reply thebluepandabear <therealbluepandabear protonmail.com> writes:
On Wednesday, 8 February 2023 at 12:10:59 UTC, zjh wrote:

 On Wednesday, 8 February 2023 at 12:07:35 UTC, zjh wrote:

 they are always unwilling to add facilities useful to others,



 `D`'s community is small, this is the reason!


yeah, I've already switched to Java because of this. but I still 
think the language has potential in the future
Feb 08 2023
parent reply zjh <fqbqrr 163.com> writes:
On Wednesday, 8 February 2023 at 12:12:57 UTC, thebluepandabear 
wrote:

 but I still think the language has potential in the future



I don't know if they have a sense of crisis. Now `D` in tiebo 
ranks `50`.
Feb 08 2023
parent reply thebluepandabear <thereabluepandabear protonmail.com> writes:
On Wednesday, 8 February 2023 at 13:32:46 UTC, zjh wrote:

 On Wednesday, 8 February 2023 at 12:12:57 UTC, thebluepandabear 
 wrote:

 but I still think the language has potential in the future



 I don't know if they have a sense of crisis. Now `D` in tiebo 
 ranks `50`.


I wouldn't say they have or should have a sense of crisis, the 
language itself is improving on a day-to-day basis but it isn't 
gaining popularity. I initially came in excited learning D 
because I thought that having a small ecosystem would just be a 
minor pain, but now I realize it's not minor -- it's pretty 
major. This is not to say D isn't a good language, it certainly 
is pretty good, but it just needs a bigger ecosystem. The 
community itself is great, no weirdos in it like Rust, but it 
just needs to be bigger.

I am actually taking a computer science class and I need to 
create desktop apps to pass and get through school. I thought 
this would be possible with D, but it has turned out to be a 
massive pain, so this is why I am switching to Java.

I think D may be one of those languages that eventually blows up 
like Rust because it's honestly great (it feels like a native 
Java some times), they just need to work on _marketing_ and 
_strengthening_ the ecosystem.

Some corporate backing (RedHat, for example) would also be great 
since many people are working on it for free, and thus lacking in 
motivation.

anyways I know nobody cares about my opinion, and hopefully this 
didn't come across disrespectful
Feb 09 2023
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Thursday, 9 February 2023 at 12:31:03 UTC, thebluepandabear 
wrote:

 I am actually taking a computer science class and I need to 
 create desktop apps to pass and get through school.


This is pretty easy in D. Like what specific kind of desktop app?
Feb 09 2023
parent reply thebluepandabear <thereabluepandabear protonmail.com> writes:
On Thursday, 9 February 2023 at 12:50:48 UTC, Adam D Ruppe wrote:

 On Thursday, 9 February 2023 at 12:31:03 UTC, thebluepandabear 
 wrote:

 I am actually taking a computer science class and I need to 
 create desktop apps to pass and get through school.


 This is pretty easy in D. Like what specific kind of desktop 
 app?


For my school I am commissioned to create many types of software. 
I tried to have a look at some of the gui kits in D but there was 
no tutorial for how to use them and they seemed as if they are 
lacking features in comparison to Qt/JavaFX.
Feb 09 2023
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Thursday, 9 February 2023 at 13:00:04 UTC, thebluepandabear 
wrote:

 For my school I am commissioned to create many types of 
 software. I tried to have a look at some of the gui kits in D 
 but there was no tutorial for how to use them and they seemed 
 as if they are lacking features in comparison to Qt/JavaFX.


So your objection is one of newbie documentation. That's fair. Qt 
I always thought had nice docs, they're hard to beat. I've been 
slowly adding more to my stuff but it is a slow process.

idk about features though, you saying "seemed" means you probably 
don't even actually know what they have so that's not as 
actionable.
Feb 09 2023
parent thebluepandabear <thereabluepandabear protonmail.com> writes:
On Thursday, 9 February 2023 at 19:17:15 UTC, Adam D Ruppe wrote:

 On Thursday, 9 February 2023 at 13:00:04 UTC, thebluepandabear 
 wrote:

 For my school I am commissioned to create many types of 
 software. I tried to have a look at some of the gui kits in D 
 but there was no tutorial for how to use them and they seemed 
 as if they are lacking features in comparison to Qt/JavaFX.


 So your objection is one of newbie documentation. That's fair. 
 Qt I always thought had nice docs, they're hard to beat. I've 
 been slowly adding more to my stuff but it is a slow process.

 idk about features though, you saying "seemed" means you 
 probably don't even actually know what they have so that's not 
 as actionable.


it's not anything personal, it's just that the current gui 
libraries for D are only around 1/100th of the size of other ones 
such as Qt/JavaFX, it's not really on the same wavelength, and 
there's nothing wrong with that specifically, it's very difficult 
to make an enterprise level gui library from scratch
Feb 09 2023
prev sibling parent reply Guillaume Piolat <first.last spam.org> writes:
On Wednesday, 8 February 2023 at 12:10:59 UTC, zjh wrote:

 On Wednesday, 8 February 2023 at 12:07:35 UTC, zjh wrote:

 they are always unwilling to add facilities useful to others,



 `D`'s community is small, this is the reason!


yeah right let's implement everything that people propose
Feb 09 2023
next sibling parent thebluepandabear <thereabluepandabear protonmail.com> writes:
On Thursday, 9 February 2023 at 12:55:41 UTC, Guillaume Piolat 
wrote:

 On Wednesday, 8 February 2023 at 12:10:59 UTC, zjh wrote:

 On Wednesday, 8 February 2023 at 12:07:35 UTC, zjh wrote:

 they are always unwilling to add facilities useful to others,



 `D`'s community is small, this is the reason!


 yeah right let's implement everything that people propose


that's not the point of this thread here :P Of course you dont 
add stuff on the whim if one person says you should, I am just 
encouraging open ended discussion.
Feb 09 2023
prev sibling parent zjh <fqbqrr 163.com> writes:
On Thursday, 9 February 2023 at 12:55:41 UTC, Guillaume Piolat 
wrote:


 yeah right let's implement everything that people propose



I like the concept of C++: I provide `facilities`, you can use it 
or not.
Not that you can only do it `like this`! This is the only way.
What's more, people put forward a `reasonable` request. It has 
been implemented, but it just not been `merged`. Maybe he thinks 
D does not welcome people who are used to `C++`.
Feb 09 2023
prev sibling next sibling parent reply thebluepandabear <thereabluepandabear protonmail.com> writes:
On Wednesday, 8 February 2023 at 12:07:35 UTC, zjh wrote:

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

 Hi,


 ...




 Last time, someone proposed to add `private` like `C++'s`, and 
 then it was the same,they are always unwilling to add 
 facilities useful to others, and then he left `D`.


yeah the whole module behaviour with `private` is just a massive 
turn off tbh, it needs to be changed to match the Java style
Feb 09 2023
parent reply zjh <fqbqrr 163.com> writes:
On Thursday, 9 February 2023 at 13:07:56 UTC, thebluepandabear 
wrote:


 yeah the whole module behaviour with `private` is just a 
 massive turn off tbh, it needs to be changed to match the Java 
 style



They don't even admit the smaller the encapsulation, the better.
Feb 09 2023
parent reply zjh <fqbqrr 163.com> writes:
On Thursday, 9 February 2023 at 13:32:36 UTC, zjh wrote:


 They don't even admit the smaller the encapsulation, the better.


Our predecessors used D very early. At first, they were very 
`excited`. But `later`, they left because some people in D were 
too `stubborn`.
You can provide `facilities`, but you just don't do it! Others 
had to leave.

Therefore, the community is very small.
Feb 09 2023
parent reply zjh <fqbqrr 163.com> writes:
On Thursday, 9 February 2023 at 13:41:27 UTC, zjh wrote:


 Our predecessors used D very early. At first, they were very 
 `excited`. But `later`, they left because some people in D were 
 too `stubborn`.
 Therefore, the community is very small.



Our predecessors are `very smart` people, and they `left`.
The loss of D community is `very large`.
Feb 09 2023
parent reply zjh <fqbqrr 163.com> writes:
On Thursday, 9 February 2023 at 13:49:03 UTC, zjh wrote:


 ..


There are too `few newcomers` to D, and D must change.
If I can, I think `'D++'` is a good idea! Learn from a 
`successful` language!

The typical feature of `C++` is that you have it. Although I 
don't have it now, I will have it sooner or later. If D is the 
same, it may expand the community, because you can attract
Feb 09 2023
parent zjh <fqbqrr 163.com> writes:
On Thursday, 9 February 2023 at 14:03:41 UTC, zjh wrote:


 If I can, I think `'D++'` is a good idea! Learn from a 
 `successful` language!


Don't be afraid of D becoming complex. C++ is already `super 
complex`. Aren't there more and more people still using it?

Therefore, I don't approve of the behavior of reluctant to add 
new features.
If it's me, as long as the new features are very good and meet 
people's needs, I will be very aggressive in 'adding new 
features'!
Feb 09 2023
prev sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 2/8/23 04:07, zjh wrote:


 Last time, someone proposed to add `private` like `C++'s`,


We've discussed the 'private' topic very many times already. C++'s 
private necessitate the 'friend' keyword, which comes with it's own 
problems.

Besides, D has zero problems with its private implementation in the 
sense that there has been zero bugs related to it being that way. Given 
the number of individuals who bring this topic up over and over up is so 
few that I don't think there is a common problem.

Do you have actual bugs related to this? "Wanting" the inclusion of a 
feature is sufficient.

In contrast, I use D every day and love its relaxed attitude towards 
private.


 and then it
 was the same,they are always unwilling to add facilities useful


That is not correct. The truth is, nobody is jumping to implementations 
just because some people think they are useful. There are always valid 
reasons for including a feature or not.

Ali
Feb 09 2023
next sibling parent reply ProtectAndHide <ProtectAndHide gmail.com> writes:
On Thursday, 9 February 2023 at 20:05:06 UTC, Ali Çehreli wrote:

 On 2/8/23 04:07, zjh wrote:


 Last time, someone proposed to add `private` like `C++'s`,


 We've discussed the 'private' topic very many times already. 
 C++'s private necessitate the 'friend' keyword, which comes 
 with it's own problems.

 Besides, D has zero problems with its private implementation in 
 the sense that there has been zero bugs related to it being 
 that way. Given the number of individuals who bring this topic 
 up over and over up is so few that I don't think there is a 
 common problem.

 Do you have actual bugs related to this? "Wanting" the 
 inclusion of a feature is sufficient.

 In contrast, I use D every day and love its relaxed attitude 
 towards private.


 and then it
 was the same,they are always unwilling to add facilities


 useful

 That is not correct. The truth is, nobody is jumping to 
 implementations just because some people think they are useful. 
 There are always valid reasons for including a feature or not.

 Ali


You mentioned previously that D implements various things in 
unprincipled ways.

I guess, if one wants to use D, one has to be comfortable with 
this.

But using a relaxed attitude towards the implementation of such a 
common and important abstraction, that in turn allows me to so 
easily shoot myself in the foot, is not really an attractive 
feature .. to me ;-)

btw. When a newbie to D raises ideas, suggestions, etc... and you 
counter them with (in essence) 'we don't need that in D, but go 
write a dip if you think we do' attitude, is a real turn off.
Feb 09 2023
next sibling parent reply Hipreme <msnmancini hotmail.com> writes:
On Thursday, 9 February 2023 at 22:34:29 UTC, ProtectAndHide 
wrote:

 On Thursday, 9 February 2023 at 20:05:06 UTC, Ali Çehreli wrote:

 On 2/8/23 04:07, zjh wrote:


 Last time, someone proposed to add `private` like `C++'s`,


 We've discussed the 'private' topic very many times already. 
 C++'s private necessitate the 'friend' keyword, which comes 
 with it's own problems.

 Besides, D has zero problems with its private implementation 
 in the sense that there has been zero bugs related to it being 
 that way. Given the number of individuals who bring this topic 
 up over and over up is so few that I don't think there is a 
 common problem.

 Do you have actual bugs related to this? "Wanting" the 
 inclusion of a feature is sufficient.

 In contrast, I use D every day and love its relaxed attitude 
 towards private.


 and then it
 was the same,they are always unwilling to add facilities


 useful

 That is not correct. The truth is, nobody is jumping to 
 implementations just because some people think they are 
 useful. There are always valid reasons for including a feature 
 or not.

 Ali


 You mentioned previously that D implements various things in 
 unprincipled ways.

 I guess, if one wants to use D, one has to be comfortable with 
 this.

 But using a relaxed attitude towards the implementation of such 
 a common and important abstraction, that in turn allows me to 
 so easily shoot myself in the foot, is not really an attractive 
 feature .. to me ;-)

 btw. When a newbie to D raises ideas, suggestions, etc... and 
 you counter them with (in essence) 'we don't need that in D, 
 but go write a dip if you think we do' attitude, is a real turn 
 off.





Most of the time, when people use "private", they are actually 
shooting their users which can't even extend their class. I 
rarely see code which people use "protected" instead and I find 
that pretty lacking. One thing is hiding memory allocation 
details on your class, other thing is hiding a property which 
could and should be controlled when extended in a class.

To be fair I'm more often than not against private variables. 
Most of the time it only caused me headaches because there was a 
lot of unimplemented features and I could not simply fork the 

Thankfully those languages has ways to simply ignore the private 
attribute, which can't be done in D.

Anyway, I'm not against static classes and I don't think they 
would bring any inherent problems, they should not cause 
regression and they should be easy to implement as the compiler 
already has the tools for it
Feb 09 2023
parent ProtectAndHide <ProtectAndHide gmail.com> writes:
On Thursday, 9 February 2023 at 23:05:35 UTC, Hipreme wrote:

 On Thursday, 9 February 2023 at 22:34:29 UTC, ProtectAndHide 
 wrote:

 On Thursday, 9 February 2023 at 20:05:06 UTC, Ali Çehreli 
 wrote:

 On 2/8/23 04:07, zjh wrote:


 Last time, someone proposed to add `private` like `C++'s`,


 We've discussed the 'private' topic very many times already. 
 C++'s private necessitate the 'friend' keyword, which comes 
 with it's own problems.

 Besides, D has zero problems with its private implementation 
 in the sense that there has been zero bugs related to it 
 being that way. Given the number of individuals who bring 
 this topic up over and over up is so few that I don't think 
 there is a common problem.

 Do you have actual bugs related to this? "Wanting" the 
 inclusion of a feature is sufficient.

 In contrast, I use D every day and love its relaxed attitude 
 towards private.


 and then it
 was the same,they are always unwilling to add facilities


 useful

 That is not correct. The truth is, nobody is jumping to 
 implementations just because some people think they are 
 useful. There are always valid reasons for including a 
 feature or not.

 Ali


 You mentioned previously that D implements various things in 
 unprincipled ways.

 I guess, if one wants to use D, one has to be comfortable with 
 this.

 But using a relaxed attitude towards the implementation of 
 such a common and important abstraction, that in turn allows 
 me to so easily shoot myself in the foot, is not really an 
 attractive feature .. to me ;-)

 btw. When a newbie to D raises ideas, suggestions, etc... and 
 you counter them with (in essence) 'we don't need that in D, 
 but go write a dip if you think we do' attitude, is a real 
 turn off.





 Most of the time, when people use "private", they are actually 
 shooting their users which can't even extend their class. I 
 rarely see code which people use "protected" instead and I find 
 that pretty lacking. One thing is hiding memory allocation 
 details on your class, other thing is hiding a property which 
 could and should be controlled when extended in a class.

 To be fair I'm more often than not against private variables. 
 Most of the time it only caused me headaches because there was 
 a lot of unimplemented features and I could not simply fork the 

 Thankfully those languages has ways to simply ignore the 
 private attribute, which can't be done in D.

 Anyway, I'm not against static classes and I don't think they 
 would bring any inherent problems, they should not cause 
 regression and they should be easy to implement as the compiler 
 already has the tools for it


Glad to hear someone say they're not 'against' something ;-)

btw. The Swift programming language is superior to D with regards 
to the notion of type privacy.

That is, Swift has fileprivate (which provides **the exact** same 
flexibility of D's private), but Swift (unlike D), *does* allow 
the programmer to choose to have aspects of their type private to 
that type. To something similar to Swift private in D, the 
programmer is **required** to have that type - and nothing else, 
in a module. That then places an important design decision in the 
hands of the langauge, rather than the programmer.

It's unlikely this aspect of Swift is in any way 'unprincipled', 
but more likely, a very well thought out decision to give 
programmers control of their design.

So uising a term someone else mentioned in this thread, the 
programmer is 'free' to make their own choices around type 
privacy in Swift, but not in D :-(
Feb 09 2023
prev sibling next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 2/9/23 14:34, ProtectAndHide wrote:


 You mentioned previously that D implements various things in
 unprincipled ways.


I think you will continue misunderstanding that term. What it means is, 
D does not insist on certain programming paradigms over others. For 
example, you can code in structured, functional, object-oriented, etc. 
styles depending on your problem.


 I guess, if one wants to use D, one has to be comfortable with this.


I can't see how being free is something that one needs to be comfortable 
with but I guess you are correct.


 But using a relaxed attitude towards the implementation of such a common
 and important abstraction, that in turn allows me to so easily shoot
 myself in the foot, is not really an attractive feature .. to me ;-)


Thanks for the wink.


 btw. When a newbie to D raises ideas, suggestions, etc... and you
 counter them with (in essence)


That is not the essence at all! There has been numerous responses here 
before I reminded how the path is actually open for language changes.


 'we don't need that in D, but go write a
 dip if you think we do' attitude, is a real turn off.


What was the alternative? Jumping to implementations of all suggested 
features? A bigger turn off would be forkit!

Ali
Feb 09 2023
parent reply ProtectAndHide <ProtectAndHide gmail.com> writes:
On Thursday, 9 February 2023 at 23:13:00 UTC, Ali Çehreli wrote:

...


Well, the only thing we can say for sure now, is that since 
'class', 'oop', and 'private' have all been mentioned in this 
thread, some 'key D people' (wink wink) will come out to derail 
this thread by further pointing out how D neither needs (nor 
wants) any of these things... and that real programmers shouldn't 
need them either.

So I hand that over to you .. wink wink.
Feb 09 2023
parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 2/9/23 15:59, ProtectAndHide wrote:


 some 'key D
 people' (wink wink)


[...]

 So I hand that over to you .. wink wink.


You're trolling[1] again.

Ali

[1] https://www.merriam-webster.com/dictionary/troll#h3
Feb 09 2023
prev sibling parent reply thebluepandabear <thereabluepandabear protonmail.com> writes:
 btw. When a newbie to D raises ideas, suggestions, etc... and 
 you counter them with (in essence) 'we don't need that in D, 
 but go write a dip if you think we do' attitude, is a real turn 
 off.


yeah it seems like the community is closed off for feedback, 
which is concerning. namespaces/static classes are a net positive 
for the language, and they've been shown to be an extremely good 


if the language wants to gain more people it needs to evolve
Feb 09 2023
parent bachmeier <no spam.net> writes:
On Thursday, 9 February 2023 at 23:51:18 UTC, thebluepandabear 
wrote:

 btw. When a newbie to D raises ideas, suggestions, etc... and 
 you counter them with (in essence) 'we don't need that in D, 
 but go write a dip if you think we do' attitude, is a real 
 turn off.


 yeah it seems like the community is closed off for feedback, 
 which is concerning.


Not at all. These things have been discussed to death and 
decisions have been made. Do you regularly have discussions with 

implement your requested features?


 if the language wants to gain more people it needs to evolve


I doubt that this would lead to a large influx of new D 
programmers. It would more than likely make the language more 
complex and less desirable, reducing the number of users.
Feb 09 2023
prev sibling next sibling parent reply thebluepandabear <thereabluepandabear protonmail.com> writes:
 In contrast, I use D every day and love its relaxed attitude 
 towards private.


the fact that private stuff is accessible from other classes in 
the same module is really really bad, and it's pretty detrimental 
to the language.

let's actually think about what `private` means.

when you come back from work, arrive home, and you close the 
curtains and want some alone, you want to be private to everyone.

you wouldn't want your neighbours (the module) to peek at what 
you're doing.

your neighbours aren't your friends in real life, and they (the 
module) aren't your friends in code -- just because they are in 
your vicinity doesn't mean they have a right to violate your 
privacy.

tbh this whole private behaviour should be changed, it's just so 
weird
Feb 09 2023
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 2/9/23 15:58, thebluepandabear wrote:

 In contrast, I use D every day and love its relaxed attitude towards
 private.


 the fact that private stuff is accessible from other classes in the same
 module is really really bad, and it's pretty detrimental to the language.


Not everybody shares that view. So, there must be something deeper here: 
maybe some people are blind (including me), or others have expectations 
that they carry from other languages, or something else... But look at 
the contrast: Some people see the same thing as great and some people 
see it as really really bad.

One thing is clear: We can't agree on this topic at least at this time.


 let's actually think about what `private` means.


It gives implementation freedom: I can change my implementation at will.

The same exact goal can be achieved by convention as well: I can name my 
members with e.g. an underscore and everybody understands that they are 
private. Nobody touches it and they are protected from future 
implementation changes.

If they do, they do it with full understanding that their code may break 
in the future.


 when you come back from work, arrive home, and you close the curtains
 and want some alone, you want to be private to everyone.


I don't agree with that example: Yes, it's the same word but different 
meanings in code.


 you wouldn't want your neighbours (the module) to peek at what you're
 doing.


Yes but I would have no problem other code looking at or using parts of 
my code if they wanted to.


 your neighbours aren't your friends in real life,


There is some friendship with my neighbors! :)


 and they (the module)
 aren't your friends in code


Some of them are and some aren't.


 -- just because they are in your vicinity
 doesn't mean they have a right to violate your privacy.


Right to violate doesn't mean anything will be broken. It means, there 
will be no hurdle if access is needed. Nobody will or does violate 
anything. I haven't seen a single time when D's approach to privacy 
caused harm.


 tbh this whole private behaviour should be changed, it's just so weird


Ok, I like "so weird" more than "really really bad". :)

Ali
Feb 09 2023
next sibling parent bachmeier <no spam.net> writes:
On Friday, 10 February 2023 at 00:18:59 UTC, Ali Çehreli wrote:

 On 2/9/23 15:58, thebluepandabear wrote:

 In contrast, I use D every day and love its relaxed attitude




 towards

 private.


 the fact that private stuff is accessible from other classes


 in the same

 module is really really bad, and it's pretty detrimental to


 the language.

 Not everybody shares that view.


Correct. I think D has made the right decision, even if others 
want it to be what they're used to, and even if they have never 
bothered to try an alternative approach. In the many discussions 
on this, I have only seen opinions and conjecture, never a strong 
argument for a change.
Feb 09 2023
prev sibling parent reply ProtectAndHide <ProtectAndHide gmail.com> writes:
On Friday, 10 February 2023 at 00:18:59 UTC, Ali Çehreli wrote:

 Not everybody shares that view. So, there must be something 
 deeper here: maybe some people are blind (including me), or 
 others have expectations that they carry from other languages, 
 or something else... But look at the contrast: Some people see 
 the same thing as great and some people see it as really really 
 bad.


Well, it's true, that we all have preconceived and limited 
notions, about this or that.

But honestly, dithyrambic praise of how D does things is not all 
that helpful.

You talk about being 'free' as a programmer, but that terms only 
seems to apply to your needs.

I'd like to be 'free' to decide on whether I want type privacy, 
or module privacy.

I don't understand the dithyrambic praise, from some D users, for 
D preventing you from doing so (in a way that is truly 'free' - 
as opposed to enforcing a design decision on to the programmer)

Anyway, the 'reality' is, that type privacy can be both 
convenient and inconvient.

Good luck on your path towards that enlightenment ;-)

"Before practicing Zen, mountains were mountains and rivers were 
rivers.
While practicing Zen, mountains are no longer mountains and 
rivers are no longer rivers.
After realization, mountains are mountains and rivers are rivers 
again."
Feb 09 2023
parent reply zjh <fqbqrr 163.com> writes:
On Friday, 10 February 2023 at 02:04:06 UTC, ProtectAndHide wrote:


 "Before practicing Zen, mountains were mountains and rivers 
 were rivers.
 While practicing Zen, mountains are no longer mountains and 
 rivers are no longer rivers.
 After realization, mountains are mountains and rivers are 
 rivers again."



Chinese proverb, is it very cool?
Feb 09 2023
parent ProtectAndHide <ProtectAndHide gmail.com> writes:
On Friday, 10 February 2023 at 02:57:42 UTC, zjh wrote:

 On Friday, 10 February 2023 at 02:04:06 UTC, ProtectAndHide 
 wrote:


 "Before practicing Zen, mountains were mountains and rivers 
 were rivers.
 While practicing Zen, mountains are no longer mountains and 
 rivers are no longer rivers.
 After realization, mountains are mountains and rivers are 
 rivers again."



 Chinese proverb, is it very cool?


you'll find this mentioned towards the end of this article:

"The Importance of Being Closed"

https://martinfowler.com/ieeeSoftware/protectedVariation.pdf
Feb 10 2023
prev sibling next sibling parent zjh <fqbqrr 163.com> writes:
On Thursday, 9 February 2023 at 20:05:06 UTC, Ali Çehreli wrote:

 On 2/8/23 04:07, zjh wrote:



 Besides, D has zero problems with its private implementation in 
 the sense that there has been zero bugs related to it being 
 that way. In contrast, I use D every day and love its relaxed 
 attitude towards private.


 Ali



That comrade has mentioned it `many(>10) times`!
`Private` can be used for two purposes. 1 is `module private`. 2 
is `class private`!.
However, you only provide `module private`, so programmers who 
want to use private classes as private classes leave, and then 
`D` continues to stay in a very small community. few man comes 
in!.
Like me, from C++, I didn't even use `friend` once! It's useless 
for me! But the "`private`" of "C++" is just right for me!.
But `D` refused to admit that `private` has two purposes! He said 
that you can only use private modules. Don't move around. It will 
increase `complexity` and make novices `afraid`!
In this way, I will only stay in `C++`, because there are more 
and more features of `C++`, and I use them `more and more`!
Feb 09 2023
prev sibling next sibling parent reply zjh <fqbqrr 163.com> writes:
On Thursday, 9 February 2023 at 20:05:06 UTC, Ali Çehreli wrote:


 In contrast, I use D every day and love its relaxed attitude 
 towards private.


I admit that you use 'D' happy, but you don't admit that I use 
'D' unhappy.
Feb 09 2023
parent zjh <fqbqrr 163.com> writes:
On Friday, 10 February 2023 at 00:58:51 UTC, zjh wrote:


 I admit that you use 'D' happy, but you don't admit that I use 
 'D' unhappy.



Right,just `forkit`.

The `minority` language is more closed than the big language! If 
you think about it, you will know that the `'D'` ranking should 
fall!

`forkit` leaves `D` ,goto `swift`.

This is what you expect. People are leaving. You can `have a 
party`.
Feb 09 2023
prev sibling parent reply Max Samukha <maxsamukha gmail.com> writes:
On Thursday, 9 February 2023 at 20:05:06 UTC, Ali Çehreli wrote:


 Besides, D has zero problems with its private implementation in 
 the sense that there has been zero bugs related to it being 
 that way.


That is how a Python aficionado would defend the absence of 
visibility attributes therein. "We don't have them, because _ is 
enough, and there are no bugs". And I would agree that D would be 
better off without visibility attributes entirely instead of 
having unending issues with them (private aliases, private + 
reflection, private + synchronized/invariant, etc).


 In contrast, I use D every day and love its relaxed attitude 
 towards private.


Having class-private doesn't preclude module-private. Dennis even 
submitted a PR implementing class-private, but it stalled because 
people couldn't agree on whether class-private should be "private 
to class" or "private to class instance".
Feb 09 2023
next sibling parent reply bachmeier <no spam.net> writes:
On Friday, 10 February 2023 at 07:04:31 UTC, Max Samukha wrote:


 Having class-private doesn't preclude module-private. Dennis 
 even submitted a PR implementing class-private, but it stalled 
 because people couldn't agree on whether class-private should 
 be "private to class" or "private to class instance".


This is a great example of the problem. In a discussion of any 
five programmers, you'll have five conflicting sets of rules that 
are the obvious and intuitive way to do it.
Feb 10 2023
parent reply ProtectAndHide <ProtectAndHide gmail.com> writes:
On Friday, 10 February 2023 at 14:50:59 UTC, bachmeier wrote:

 On Friday, 10 February 2023 at 07:04:31 UTC, Max Samukha wrote:


 Having class-private doesn't preclude module-private. Dennis 
 even submitted a PR implementing class-private, but it stalled 
 because people couldn't agree on whether class-private should 
 be "private to class" or "private to class instance".


 This is a great example of the problem. In a discussion of any 
 five programmers, you'll have five conflicting sets of rules 
 that are the obvious and intuitive way to do it.


Well in Swift, there is no problem .. at all.

Why is it a problem in D then? (and I mean technically).

I think the 'real' problem, is that some core D people just 
refuse to allow D to provide such an option to the programmer. 
For what reason, I cannot fathom, since Swift can do this just 
fine. I think it's some kind of bias against a particular style 
of programming that some don't want to see occuring when people 
use the D programming lanuguage. i.e. It has nothing at all to do 
with implementation, since it's already been demonstrated that it 
can be implemented, very easily.

Again, in this particular area, Swift is way ahead of D.
Feb 10 2023
next sibling parent reply thebluepandabear <thereabluepandabear protonmail.com> writes:
 I think the 'real' problem, is that some core D people just 
 refuse to allow D to provide such an option to the programmer. 
 For what reason, I cannot fathom, since Swift can do this just 
 fine. I think it's some kind of bias against a particular style 
 of programming that some don't want to see occuring when people 
 use the D programming lanuguage. i.e. It has nothing at all to 
 do with implementation, since it's already been demonstrated 
 that it can be implemented, very easily.

 Again, in this particular area, Swift is way ahead of D.


Sorry, but I do not believe Swift is near to the level of what D 
is, it's a language that's tied - like jail - to Apple's 
ecosystem, and its only real use is for iOS apps. They're two 
completely different languages in general.
Feb 10 2023
next sibling parent reply thebluepandabear <thereabluepandabear protonmail.com> writes:


perfect language. Java is also pretty good, but it has its 
downsides.
Feb 10 2023
parent reply ProtectAndHide <ProtectAndHide gmail.com> writes:
On Friday, 10 February 2023 at 23:22:34 UTC, thebluepandabear 
wrote:



 much the perfect language. Java is also pretty good, but it has 
 its downsides.


I don't agree with all of that.



Particulary because of its extensive framework library, which D 
could never compete with.

Also, the  move to open-source, and the move to cross platform 

use cases, and will certainly see the language being used more 
and more...

I don't necessarily have a problem (anymore) with it being tied 
to Microsoft (because of the above). Also, Microsoft can afford 
to employ 'the best', which is what they indeed do, and which is 


What attracts me to D, is the inability to program outside of a 

happen, but I wouldn't hold my breath.

If only D 'really did' support OOP, as it claims, it would be 
more useful to me.
Feb 10 2023
parent reply thebluepandabear <thereabluepandabear protonmail.com> writes:
 What attracts me to D, is the inability to program outside of a 

 happen, but I wouldn't hold my breath.


programming outside of a class is overrated though in my opinion. 
i've never seen a usecase for it in an object oriented language. 
Of course Kotlin can do this, which is good, but you can just 

in Java with a private ctor, or Kotlin `object`.)
Feb 10 2023
parent ProtectAndHide <ProtectAndHide gmail.com> writes:
On Saturday, 11 February 2023 at 02:18:48 UTC, thebluepandabear 
wrote:

 What attracts me to D, is the inability to program outside of 

 this happen, but I wouldn't hold my breath.


 programming outside of a class is overrated though in my 
 opinion. i've never seen a usecase for it in an object oriented 
 language. Of course Kotlin can do this, which is good, but you 

 `final class` in Java with a private ctor, or Kotlin `object`.)




still... in Swift, you can do hello world, just like this:

print("Hello World!");



using System;
Console.WriteLine("Hello World!");

(but that's just syntactic sugar .. the class, main etc. is 
actually generated behind the scenes.) I don't use top-level 
statements though, as find them completely pointless (and 


The shortest syntax in D, for hello workd - as far as I know, is:

import std.stdio;

void main()
{
     writeln("Hello World!");
}
Feb 10 2023
prev sibling parent reply ProtectAndHide <ProtectAndHide gmail.com> writes:
On Friday, 10 February 2023 at 23:19:31 UTC, thebluepandabear 
wrote:

 I think the 'real' problem, is that some core D people just 
 refuse to allow D to provide such an option to the programmer. 
 For what reason, I cannot fathom, since Swift can do this just 
 fine. I think it's some kind of bias against a particular 
 style of programming that some don't want to see occuring when 
 people use the D programming lanuguage. i.e. It has nothing at 
 all to do with implementation, since it's already been 
 demonstrated that it can be implemented, very easily.

 Again, in this particular area, Swift is way ahead of D.


 Sorry, but I do not believe Swift is near to the level of what 
 D is, it's a language that's tied - like jail - to Apple's 
 ecosystem, and its only real use is for iOS apps. They're two 
 completely different languages in general.


That's not entirely correct.

I don't use any Apple hardware products. Never have, and never 
will.

I use Swift on Linux only.

There are of course some library features of Swift tied to Apple 
products. But I have no need for those library features.

As a standalone language, Swift can (IMO) already out compete D.
Feb 10 2023
parent reply thebluepandabear <thereabluepandabear protonmail.com> writes:
 That's not entirely correct.

 I don't use any Apple hardware products. Never have, and never 
 will.

 I use Swift on Linux only.

 There are of course some library features of Swift tied to 
 Apple products. But I have no need for those library features.

 As a standalone language, Swift can (IMO) already out compete D.


Swift on Linux? Interesting...

what is the use case?
Feb 10 2023
parent ProtectAndHide <ProtectAndHide gmail.com> writes:
On Saturday, 11 February 2023 at 02:15:37 UTC, thebluepandabear 
wrote:

 That's not entirely correct.

 I don't use any Apple hardware products. Never have, and never 
 will.

 I use Swift on Linux only.

 There are of course some library features of Swift tied to 
 Apple products. But I have no need for those library features.

 As a standalone language, Swift can (IMO) already out compete 
 D.


 Swift on Linux? Interesting...

 what is the use case?




But its not a 'play' language. It's a seriously well designed 
language.

Swift is also available on Windows.
Feb 10 2023
prev sibling next sibling parent reply thebluepandabear <thereabluepandabear protonmail.com> writes:
 I think the 'real' problem, is that some core D people just 
 refuse to allow D to provide such an option to the programmer.



I think a lot of it has to do with the fact that heaps of D 
programmers write procedural code and don't care about any object 
oriented features, that's because they're 'old-school' 
programmers, whereas OOP is 'new-school'.
Feb 10 2023
parent reply ProtectAndHide <ProtectAndHide gmail.com> writes:
On Friday, 10 February 2023 at 23:24:11 UTC, thebluepandabear 
wrote:

 I think the 'real' problem, is that some core D people just 
 refuse to allow D to provide such an option to the programmer.



 I think a lot of it has to do with the fact that heaps of D 
 programmers write procedural code and don't care about any 
 object oriented features, that's because they're 'old-school' 
 programmers, whereas OOP is 'new-school'.


OOP is not 'new-school' ..not by any means...

It had a period where it became 'more popular', that is for sure.

Some took it too far, as this has caused some friction, with many 
languages deciding to rebel against that style.

It is true, that no core D users will advocate anything OOP, that 
is for sure ;-)

However the language claims to support OOP, so there is some 
tension when newbies come to D and actually try it out.

I'm not an advocate of any style in particular. I'm happy to use 
any style that is clear to understand and use, suitable, and can 
provide reasonable guarantees around memory safety and 
correctness.

But a language that claims to support OOP but doesn't even have 
type privacy, is a bit of joke IMO.
Feb 10 2023
parent reply thebluepandabear <thereabluepandabear protonmail.com> writes:
 I'm not an advocate of any style in particular. I'm happy to 
 use any style that is clear to understand and use, suitable, 
 and can provide reasonable guarantees around memory safety and 
 correctness.

 But a language that claims to support OOP but doesn't even have 
 type privacy, is a bit of joke IMO.


agreed, the current behaviour of `private` is inexcusable, and 
it's something newcomers need to be warned about.
Feb 10 2023
parent reply ProtectAndHide <ProtectAndHide gmail.com> writes:
On Saturday, 11 February 2023 at 02:17:09 UTC, thebluepandabear 
wrote:

 I'm not an advocate of any style in particular. I'm happy to 
 use any style that is clear to understand and use, suitable, 
 and can provide reasonable guarantees around memory safety and 
 correctness.

 But a language that claims to support OOP but doesn't even 
 have type privacy, is a bit of joke IMO.


 agreed, the current behaviour of `private` is inexcusable, and 
 it's something newcomers need to be warned about.


that wasn't my first 'shock' when I came to D.

My first shock, was that 'public' was default!

New comers should know that before they even begin their first 
line in D.

For a language that claims to supprot OOP, and does public by 
default, and no way to declare type private... I mean... wow!
Feb 10 2023
parent thebluepandabear <thereabluepandabear protonmail.com> writes:
 For a language that claims to supprot OOP, and does public by 
 default, and no way to declare type private... I mean... wow!


agree, it should definitely be `private` by default... if 
`private` was implemented properly lmao
Feb 10 2023
prev sibling parent reply Kagamin <spam here.lot> writes:
On Friday, 10 February 2023 at 21:52:02 UTC, ProtectAndHide wrote:

 Well in Swift, there is no problem .. at all.

 Why is it a problem in D then? (and I mean technically).


What about the increment operator `++` ?
Feb 12 2023
parent reply ProtectAndHide <ProtectAndHide gmail.com> writes:
On Monday, 13 February 2023 at 07:19:49 UTC, Kagamin wrote:

 On Friday, 10 February 2023 at 21:52:02 UTC, ProtectAndHide 
 wrote:

 Well in Swift, there is no problem .. at all.

 Why is it a problem in D then? (and I mean technically).


 What about the increment operator `++` ?


Remember, that a one of the design goals of Swift was to NOT 
continue the 'continuity with C'. This is a very, very, very 
different goal to D.

Personally, I've never liked ++ and -- (and I have for many 
years, wrote them out the way Swift now requires.).

So for me, Swift does exactly what I want here ;-)

Chris Lattner outlines the reasons for removing it in Swift 3.0 
here:

https://github.com/apple/swift-evolution/blob/main/proposals/0004-remove-pre-post-inc-decrement.md
Feb 13 2023
parent reply Kagamin <spam here.lot> writes:
On Monday, 13 February 2023 at 08:22:06 UTC, ProtectAndHide wrote:

 Chris Lattner outlines the reasons for removing it in Swift 3.0 
 here:

 https://github.com/apple/swift-evolution/blob/main/proposals/0004-remove-pre-post-inc-decrement.md


So your complaint is that you agree with Chris Lattner and 
disagree with others?
Feb 13 2023
parent reply ProtectAndHide <ProtectAndHide gmail.com> writes:
On Monday, 13 February 2023 at 09:14:18 UTC, Kagamin wrote:

 On Monday, 13 February 2023 at 08:22:06 UTC, ProtectAndHide 
 wrote:

 Chris Lattner outlines the reasons for removing it in Swift 
 3.0 here:

 https://github.com/apple/swift-evolution/blob/main/proposals/0004-remove-pre-post-inc-decrement.md


 So your complaint is that you agree with Chris Lattner and 
 disagree with others?


I was just responding to your comment about '++'.

What is your point? That I should not complain about not being 
able to 'declare' type private? (in a language that says it 
support OOP).

My request is not odd. What is odd, is the complete and utter 
rejection of it ;-)
Feb 13 2023
parent reply Kagamin <spam here.lot> writes:
My point is you know you're just picky.
Feb 14 2023
parent reply ProtectAndHide <ProtectAndHide gmail.com> writes:
On Tuesday, 14 February 2023 at 08:15:37 UTC, Kagamin wrote:

 My point is you know you're just picky.


Well.. it seems to me, that your 'point' is to just have a go at 
me.

In any case, there is nothing 'picky' about wanting to be able to 
explicately 'declare' a member of my class type as being private. 
That to me, is what a programmer should expect to be able to do 
in a language that says it supports OOP.

Further nonsense towards me will be ignored ;-)
Feb 14 2023
next sibling parent thebluepandabear <thereabluepandabear protonmail.com> writes:
On Tuesday, 14 February 2023 at 10:16:47 UTC, ProtectAndHide 
wrote:

 On Tuesday, 14 February 2023 at 08:15:37 UTC, Kagamin wrote:

 My point is you know you're just picky.


 Well.. it seems to me, that your 'point' is to just have a go 
 at me.

 In any case, there is nothing 'picky' about wanting to be able 
 to explicately 'declare' a member of my class type as being 
 private. That to me, is what a programmer should expect to be 
 able to do in a language that says it supports OOP.

 Further nonsense towards me will be ignored ;-)


fight fight fight fight

jk
Feb 14 2023
prev sibling parent reply bachmeier <no spam.net> writes:
On Tuesday, 14 February 2023 at 10:16:47 UTC, ProtectAndHide 
wrote:


 In any case, there is nothing 'picky' about wanting to be able 
 to explicately 'declare' a member of my class type as being 
 private. That to me, is what a programmer should expect to be 
 able to do in a language that says it supports OOP.


What you are saying is that you want an implementation of a 
particular language that calls itself an OOP language. [There is 
a lot of controversy about the definition of 
OOP](https://wiki.c2.com/?NobodyAgreesOnWhatOoIs). I do not think 
the explicit ability to declare a member of a class private in a 
particular way has anything to do with it. You are certainly 
entitled to your opinion, but it doesn't help to say D is not an 
OOP language because you don't like some of the design decisions.
Feb 14 2023
next sibling parent ProtectAndHide gmail.com <ProtectAndHide gmail.com> writes:
On Tuesday, 14 February 2023 at 15:34:17 UTC, bachmeier wrote:

 On Tuesday, 14 February 2023 at 10:16:47 UTC, ProtectAndHide 
 wrote:


 In any case, there is nothing 'picky' about wanting to be able 
 to explicately 'declare' a member of my class type as being 
 private. That to me, is what a programmer should expect to be 
 able to do in a language that says it supports OOP.


 What you are saying is that you want an implementation of a 
 particular language that calls itself an OOP language. [There 
 is a lot of controversy about the definition of 
 OOP](https://wiki.c2.com/?NobodyAgreesOnWhatOoIs). I do not 
 think the explicit ability to declare a member of a class 
 private in a particular way has anything to do with it. You are 
 certainly entitled to your opinion, but it doesn't help to say 
 D is not an OOP language because you don't like some of the 
 design decisions.


It's true that not everybody understands what OOP is.

But I think everyone would agree, that data hiding is at the core.

First, I'm not advocating for OOP, or against it.

It's just a tool that's suitable in some scenarios, and not it 
others.

I'm also not a OOP purist.

Now with that out of the way....

D claims to support OOP. Put that to the test. Because there is a 
difference between programming with modules ('Decide which 
modules you want and partition the program so that data is hidden 
in modules.') and programming with 'user-defined types' ('Decide 
which types you want and provide a full set of operations for 
each type').

Data hiding is at the core of using modules.

It's also at the core of using types.

I refer interested people to:

"Most, but not all, modules are better expressed as user defined 
types." -

What is 'Object-Oriented Programming'? (1991 revised version) 
Bjarne Stroustrup

https://www.stroustrup.com/whatis.pdf
Feb 14 2023
prev sibling parent reply thebluepandabear <thereabluepandabear protonmail.com> writes:
On Tuesday, 14 February 2023 at 15:34:17 UTC, bachmeier wrote:

 On Tuesday, 14 February 2023 at 10:16:47 UTC, ProtectAndHide 
 wrote:


 In any case, there is nothing 'picky' about wanting to be able 
 to explicately 'declare' a member of my class type as being 
 private. That to me, is what a programmer should expect to be 
 able to do in a language that says it supports OOP.


 What you are saying is that you want an implementation of a 
 particular language that calls itself an OOP language. [There 
 is a lot of controversy about the definition of 
 OOP](https://wiki.c2.com/?NobodyAgreesOnWhatOoIs). I do not 
 think the explicit ability to declare a member of a class 
 private in a particular way has anything to do with it. You are 
 certainly entitled to your opinion, but it doesn't help to say 
 D is not an OOP language because you don't like some of the 
 design decisions.


D is still an OOP language, as long as it has classes, 
inheritance, and polymorphism, though it's certainly not a good 
one if any class can acccess private members from the module, 
that's just horrid.
Feb 14 2023
parent reply thebluepandabear <thereabluepandabear protonmail.com> writes:
On Wednesday, 15 February 2023 at 01:15:09 UTC, thebluepandabear 
wrote:

 On Tuesday, 14 February 2023 at 15:34:17 UTC, bachmeier wrote:

 On Tuesday, 14 February 2023 at 10:16:47 UTC, ProtectAndHide 
 wrote:


 In any case, there is nothing 'picky' about wanting to be 
 able to explicately 'declare' a member of my class type as 
 being private. That to me, is what a programmer should expect 
 to be able to do in a language that says it supports OOP.


 What you are saying is that you want an implementation of a 
 particular language that calls itself an OOP language. [There 
 is a lot of controversy about the definition of 
 OOP](https://wiki.c2.com/?NobodyAgreesOnWhatOoIs). I do not 
 think the explicit ability to declare a member of a class 
 private in a particular way has anything to do with it. You 
 are certainly entitled to your opinion, but it doesn't help to 
 say D is not an OOP language because you don't like some of 
 the design decisions.


 D is still an OOP language, as long as it has classes, 
 inheritance, and polymorphism, though it's certainly not a good 
 one if any class can acccess private members from the module, 
 that's just horrid.


I think what you could say is that D lacks _encapsulation_ which 
is also an OOP concept. So D is partially OOP but not fully OOP 
due to there being no encapsulation in the language.
Feb 14 2023
parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 15 February 2023 at 01:16:00 UTC, thebluepandabear 
wrote:


 I think what you could say is that D lacks _encapsulation_ 
 which is also an OOP concept. So D is partially OOP but not 
 fully OOP due to there being no encapsulation in the language.


D does not lack encapsulation, it's just that the unit of 
encapsulation is the module. Everything private in a module is 
encapsulated from the perspective of the public API.

If you really want to prevent anything inside a module from 
accessing the private parts of a class, you can put the class in 
its own module.

Must we continue beating this horse?
Feb 14 2023
next sibling parent reply bachmeier <no spam.net> writes:
On Wednesday, 15 February 2023 at 02:14:30 UTC, Mike Parker wrote:

 On Wednesday, 15 February 2023 at 01:16:00 UTC, 
 thebluepandabear wrote:


 I think what you could say is that D lacks _encapsulation_ 
 which is also an OOP concept. So D is partially OOP but not 
 fully OOP due to there being no encapsulation in the language.


 D does not lack encapsulation, it's just that the unit of 
 encapsulation is the module. Everything private in a module is 
 encapsulated from the perspective of the public API.

 If you really want to prevent anything inside a module from 
 accessing the private parts of a class, you can put the class 
 in its own module.

 Must we continue beating this horse?


Time to move on to OCaml programmers telling us D doesn't have 
floating point arithmetic because there's no `+.` operator.
Feb 14 2023
parent reply thebluepandabear <thereabluepandabear protonmail.com> writes:
 Time to move on to OCaml programmers telling us D doesn't have 
 floating point arithmetic because there's no `+.` operator.


that's not the same thing though, you've created a great false 
equivalence! Congrats.
Feb 14 2023
parent reply bachmeier <no spam.net> writes:
On Wednesday, 15 February 2023 at 07:13:41 UTC, thebluepandabear 
wrote:

 Time to move on to OCaml programmers telling us D doesn't have 
 floating point arithmetic because there's no `+.` operator.


 that's not the same thing though, you've created a great false 
 equivalence! Congrats.


Only if you don't understand D's encapsulation. You're going on 
at length (apparently under multiple names in this thread) 
because you don't like D's implementation of encapsulation. 
That's no different from complaining that the `+` operator should 
be `+.`, and until D makes the change, it doesn't support 
floating point addition.

There are reasonable arguments for changing and not changing D's 
implementation of encapsulation. Your claim that D doesn't 
support encapsulation is false.
Feb 15 2023
parent reply thebluepandabear <thereabluepandabear protonmail.com> writes:
On Wednesday, 15 February 2023 at 20:06:18 UTC, bachmeier wrote:

 On Wednesday, 15 February 2023 at 07:13:41 UTC, 
 thebluepandabear wrote:

 Time to move on to OCaml programmers telling us D doesn't 
 have floating point arithmetic because there's no `+.` 
 operator.


 that's not the same thing though, you've created a great false 
 equivalence! Congrats.


 Only if you don't understand D's encapsulation. You're going on 
 at length (apparently under multiple names in this thread) 
 because you don't like D's implementation of encapsulation. 
 That's no different from complaining that the `+` operator 
 should be `+.`, and until D makes the change, it doesn't 
 support floating point addition.

 There are reasonable arguments for changing and not changing 
 D's implementation of encapsulation. Your claim that D doesn't 
 support encapsulation is false.


'under multiple names'... You can clearly see I have the same 
name, simply different profile pictures.
Feb 15 2023
parent ProtectAndHide <ProtectAndHide gmail.com> writes:
On Wednesday, 15 February 2023 at 20:34:13 UTC, thebluepandabear 
wrote:

 On Wednesday, 15 February 2023 at 20:06:18 UTC, bachmeier wrote:

 On Wednesday, 15 February 2023 at 07:13:41 UTC, 
 thebluepandabear wrote:

 Time to move on to OCaml programmers telling us D doesn't 
 have floating point arithmetic because there's no `+.` 
 operator.


 that's not the same thing though, you've created a great 
 false equivalence! Congrats.


 Only if you don't understand D's encapsulation. You're going 
 on at length (apparently under multiple names in this thread) 
 because you don't like D's implementation of encapsulation. 
 That's no different from complaining that the `+` operator 
 should be `+.`, and until D makes the change, it doesn't 
 support floating point addition.

 There are reasonable arguments for changing and not changing 
 D's implementation of encapsulation. Your claim that D doesn't 
 support encapsulation is false.


 'under multiple names'... You can clearly see I have the same 
 name, simply different profile pictures.



You should know by now, that anyone that supports the idea of D 
providing an explicit mechanism to support data hiding for a 
user-defined type, are all the **same** person.

Nobody else in the world supports such an idea.

It's all just one person... apparently ;-)
Feb 15 2023
prev sibling parent reply thebluepandabear <therealbluepandabear protonmail.com> writes:
On Wednesday, 15 February 2023 at 02:14:30 UTC, Mike Parker wrote:

 On Wednesday, 15 February 2023 at 01:16:00 UTC, 
 thebluepandabear wrote:


 I think what you could say is that D lacks _encapsulation_ 
 which is also an OOP concept. So D is partially OOP but not 
 fully OOP due to there being no encapsulation in the language.


 D does not lack encapsulation, it's just that the unit of 
 encapsulation is the module. Everything private in a module is 
 encapsulated from the perspective of the public API.

 If you really want to prevent anything inside a module from 
 accessing the private parts of a class, you can put the class 
 in its own module.

 Must we continue beating this horse?


Why is the unit of encapsulation the module though? Makes no 
sense.
Feb 14 2023
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 15 February 2023 at 07:23:39 UTC, thebluepandabear 
wrote:


 Why is the unit of encapsulation the module though? Makes no 
 sense.


What is the purpose of encapsulation? To keep the implementation 
details hidden behind the public API, such that changing the 
implementation doesn't change the API.

Consider this:

```d
module gfx;
struct Point {
     private int x, y;
     this(int x, int y)
     {
         this.x = x;
         this.y = y;
     }

     void move(Point to) {
         x = to.x;
         y = to.y;
     }
}
```
Here, `move` is part of the public API. `x` and `y` are part of 
the implementation. Nothing outside the module can touch them.

Now this:

```d
module gfx;
struct Point {
     private int x, y;
     this(int x, int y)
     {
         this.x = x;
         this.y = y;
     }
}

void move(ref Point from, Point to) {
     from.x = to.x;
     from.y = to.y;
}
```

 From the perspective of the public API, nothing has changed. The 
following works in both cases:

```d
Point p;
p.move(Point(10, 20));
writeln(p);
```

In both cases, the implementation is hidden behind the same 
public API.

If private were restricted to the class/struct, it would add 
anything more for encapsulation in D. In practical terms, if you 
are editing the `gfx` module, you also have access to the 
implementation details of `Point`.

Sure, if you have e.g., a special setter that does some extra 
work when a member variable is set, you want to ensure that only 
that setter is used to change the member variable. But that's 
true *inside the class/struct* as well.

I mean, just consider this:

```d
class C {
     private enum minX = -100;
     private int _x;

     void setX(int newX) { _x = newX > minX ? newX : minX }

     void doSomething(State s) { setX(_x + s.val); }
}
```

vs. this:

```d
class C {
     private enum minX = -100;
     private int _x;

     void setX(int newX) { _x = newX > minX ? newX : minX }
}

void doSomething(C c, State s) { c.setX(c._x + s.val); }
```

Ideologically, they are not the same. In practical terms, they 
are. Whether the closing brace of the class declaration is before 
or after `doSomething` matters not one bit. Yes, things can go 
wonky in a module that's many lines long and someone sets `_x` 
from outside of the class. So what? The same is true for a class 
that's many lines long when someone adds a new method that 
directly sets `_x` rather than going through the setter.

D's modules are intended to be used for grouping related 
constructs. Everything in the module is part of the same private 
implementation. If the constructs aren't related, then put them 
in separate modules. And there's still a solution for anyone with 
a strict ideological preference regarding related constructs: 
they can put their classes and structs in individual modules 
under a common package. `package` protection can be used for 
cross-module access inside the package, and the entire set can be 
presented to the outside world as a single module with 
`package.d`.

Our friend of many forum handles misses no opportunity to return 
to this putrid horse corpse to beat it some more, but the meaning 
of private isn't going to change. This is D's approach to 
encapsulation.
Feb 15 2023
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 15 February 2023 at 08:56:00 UTC, Mike Parker wrote:


 If private were restricted to the class/struct, it would add 
 anything more for encapsulation in D.


I meant to say, it "wouldn't add more".
Feb 15 2023
next sibling parent ProtectAndHide <ProtectAndHide gmail.com> writes:
On Wednesday, 15 February 2023 at 08:57:27 UTC, Mike Parker wrote:

 On Wednesday, 15 February 2023 at 08:56:00 UTC, Mike Parker 
 wrote:


 If private were restricted to the class/struct, it would add 
 anything more for encapsulation in D.


 I meant to say, it "wouldn't add more".


Well, to quote Stroustrup (from that paper I cited):

"A language is said to support a style of programming if it 
provides facilities that makes it convenient (reasonably easy, 
safe, and efficient) to use that style. A language
does not support a technique if it takes exceptional effort or 
skill to write such programs; it merely enables the technique to 
be used."

If the only way to protect hidden data within a user-defined type 
(lets call it a class.. or whatever you want) from other code 
within the module is to put that type in it's own module, I would 
argue that D 'enables' data hiding, but does not 'support' it. Of 
course, I am referring to the context of a module, and any code 
within that module.

The benefit of having the ability to 'not have to' put a 
user-defined type in a module by itself, simply to enforce data 
hiding (from other code in a module), seems pretty obvious to me. 
For example, you could put tightly coupled classes in the same 
module, and each class would not be able to access the hidden 
parts of each other (except through an explicit declaration). 
You'd be able to put unit-tests in the same module, and not have 
those unit-tests accessing hidden data of your type. Etc...etc.

So the benefit is clear.

The downside? I (as yet) have never heard a convincing argument 
for why D should never provide such an option to the programmer, 
but should instead, continue to force programmers in to the 
1-type-per-module design (which is an entirely unreasonable 
contraint for a language to enforce on a programmer).

btw. This is not about beating a horse. I think the point was 
raised in some comment, and various people (the usual ones, 
including yourself) have decided to weigh in. That is what 
results in the converstaion being had ;-)
Feb 15 2023
prev sibling parent reply zjh <fqbqrr 163.com> writes:
On Wednesday, 15 February 2023 at 08:57:27 UTC, Mike Parker wrote:


 I meant to say, it "wouldn't add more".



What if two classes in the module that are several meters apart 
make `mistakes` that change the privite variable of `another 
class`?

No one can guarantee that after `a few months`, even if you are 
the author, you will not make mistakes, so as to misuse private 
variable, while `class level` private can be completely avoided 
it!

There is no maintainability, because two `out-of-class` functions 
may quietly change your private `variables`.
Feb 15 2023
next sibling parent reply ProtectAndHide <ProtectAndHide gmail.com> writes:
On Wednesday, 15 February 2023 at 09:51:41 UTC, zjh wrote:

 On Wednesday, 15 February 2023 at 08:57:27 UTC, Mike Parker 
 wrote:


 I meant to say, it "wouldn't add more".



 What if two classes in the module that are several meters apart 
 make `mistakes` that change the privite variable of `another 
 class`?

 No one can guarantee that after `a few months`, even if you are 
 the author, you will not make mistakes, so as to misuse private 
 variable, while `class level` private can be completely avoided 
 it!

 There is no maintainability, because two `out-of-class` 
 functions may quietly change your private `variables`.


In a module that contains a class, and other code as well 
(perhaps other tightly coupled classes), you can know **nothing** 
at all about that type (or any other class) without knowing 
**everything** else in the module. If one understands this, then 
one understands the problem here ;-)

.. btw. other code.. includes unitests as well.

The solution that D provides, is not a solution. It's a design 
constraint being forced on programmers. Anyone that argues 
otherwise, is speaking out of their ...
Feb 15 2023
parent reply zjh <fqbqrr 163.com> writes:
On Wednesday, 15 February 2023 at 09:57:56 UTC, ProtectAndHide 
wrote:


 In a module that contains a class, and other code as well 
 (perhaps other tightly coupled classes), you can know 
 **nothing** at all about that type (or any other class) without 
 knowing **everything** else in the module. If one understands 
 this, then one understands the problem here ;-)

 .. btw. other code.. includes unitests as well.

 The solution that D provides, is not a solution. It's a design 
 constraint being forced on programmers. Anyone that argues 
 otherwise, is speaking out of their ...



Right... They greatly increase your code maintenance work!
Feb 15 2023
parent zjh <fqbqrr 163.com> writes:
On Wednesday, 15 February 2023 at 12:44:19 UTC, zjh wrote:


 Right... They greatly increase your code maintenance work!


Many people left D because of these small details!
Their encapsulation can actually leakage class members. 
Programmers in other languages will laugh cry!
Feb 15 2023
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 15 February 2023 at 09:51:41 UTC, zjh wrote:

 What if two classes in the module that are several meters apart 
 make `mistakes` that change the privite variable of `another 
 class`?

 No one can guarantee that after `a few months`, even if you are 
 the author, you will not make mistakes, so as to misuse private 
 variable, while `class level` private can be completely avoided 
 it!

 There is no maintainability, because two `out-of-class` 
 functions may quietly change your private `variables`.


I referenced that in my post. The exact same problem exists 
*inside* the class when your class file is very long. You can 
easily manipulate the private member even when it's only supposed 
to be accessed by a specific function. A common recommendation in 
Java used to be (and probably still is) to always accessing 
private members by their setters even inside the class. And after 
all these years they haven't had a need to lock down 
single-method access to private members. It's the *exact* same 
thing in D: the private implementation is in the source file. The 
fact that the source file represents a module rather than a 
single class is irrelevant.

We keep repeating the same arguments over and over and over again 
on this. I still haven't seen any convincing argument for 
changing things when it's already possible to do what you want to 
do. I repeat for the umpteenth time: if you care so much about 
who can touch your private parts, then put your classes and 
structs in their own modules and use D's package facilities to 
provide the public interface you want.
Feb 15 2023
next sibling parent zjh <fqbqrr 163.com> writes:
On Wednesday, 15 February 2023 at 10:17:30 UTC, Mike Parker wrote:


 I referenced that in my post. The exact same problem exists 
 *inside* the class when your class file is very long. You can 
 easily manipulate the private member even when it's only 
 supposed to be accessed by a specific function. A common 
 recommendation in Java used to be (and probably still is) to 
 always accessing private members by their setters even inside 
 the class. And after all these years they haven't had a need to 
 lock down single-method access to private members. It's the 
 *exact* same thing in D: the private implementation is in the 
 source file. The fact that the source file represents a module 
 rather than a single class is irrelevant.

 We keep repeating the same arguments over and over and over 
 again on this. I still haven't seen any convincing argument for 
 changing things when it's already possible to do what you want 
 to do. I repeat for the umpteenth time: if you care so much 
 about who can touch your private parts, then put your classes 
 and structs in their own modules and use D's package facilities 
 to provide the public interface you want.



Class level private, which can ensure that there will never be 
any leakage and there will be no encapsulation misuse,
At the module level, this is unavoidable!
And there are closely related classes, which should be placed in 
a module.
Feb 15 2023
prev sibling next sibling parent ProtectAndHide <ProtectAndHide gmail.com> writes:
On Wednesday, 15 February 2023 at 10:17:30 UTC, Mike Parker wrote:

 We keep repeating the same arguments over and over and over 
 again on this. I still haven't seen any convincing argument for 
 changing things when it's already possible to do what you want 
 to do. I repeat for the umpteenth time: if you care so much 
 about who can touch your private parts, then put your classes 
 and structs in their own modules and use D's package facilities 
 to provide the public interface you want.


The convincing arguement (convincing to me anyway) was made when 
I came to D, programmed a class, and put a unittest in the same 
module, and accidently referenced hidden data of my class in my 
unittest. This result in a bug. It was when i was tracking down 
the source of this bug, that I discovered that private is not 
private at all (inside the module).

If there is a cycle continuing, it's because your solution to a 
'real' problem (read above again please), is to force an 
unreasonable design constraint onto the programmer.

This includes being forced to put your unittest in its own module 
as well (for reasons demonstrated above).

It should be up to the programmer to decide what types should go 
into their module: Not the language! You think the language has 
this right to force such a constraint onto the programmer, I do 
not. That really is the basis for the disagreement here.

I want fewer modules, each containing tighly couple types.

You want more modules, each containing one single type.

I want unittest in the same module as my type.

You want me to have them in their own module as well.

No. I cannot accept this as a reasonable solution.
Feb 15 2023
prev sibling parent reply ProtectAndHide <ProtectAndHide gmail.com> writes:
On Wednesday, 15 February 2023 at 10:17:30 UTC, Mike Parker wrote:

 I referenced that in my post. The exact same problem exists 
 *inside* the class when your class file is very long. You can 
 easily manipulate the private member even when it's only 
 supposed to be accessed by a specific function.


You're missing the point, completely.

We're discussing the issue of type safety.

Your talking about typing mistakes.


 .. in D: the private implementation is in the source file. The 
 fact that the source file represents a module rather than a 
 single class is irrelevant.


Again, this is about type safety, supported by the compiler.

Read that article by Stroustup that I cited, so you can obtain a 
clearer understanding what it is 'he' is saying, because what I 
am saying.

In essence, he discusses how inferior a type created  through  a 
module mechanism is, compared to a user-defined type (and that 
user-defined types were provided by languages for that very 
reason). The key being, that user-defined types provide their own 
mechanism for data hiding (the representation is private). D's 
module system supports this, but it does not 'enable' it. i.e. it 
supports it by forcing the programmer to put that type into its 
own module.


 We keep repeating the same arguments over and over and over 
 again on this......


That's because the key idea being presented here, is not being 
taken on board.

A user-defined type is a type that has a mechanism to keep it 
representation private.

D does not support this. It only enables it.

You (and others) may well argue that D should not enable this 
(directly), it should only support it (indirectly), and thus 
allow the language to force an important design decision onto 
programmers.

As a programmer, I don't think that is acceptable.
Feb 15 2023
next sibling parent reply bachmeier <no spam.net> writes:
On Wednesday, 15 February 2023 at 19:44:50 UTC, ProtectAndHide 
wrote:


 A user-defined type is a type that has a mechanism to keep it 
 representation private.

 D does not support this. It only enables it.

 You (and others) may well argue that D should not enable this 
 (directly), it should only support it (indirectly), and thus 
 allow the language to force an important design decision onto 
 programmers.

 As a programmer, I don't think that is acceptable.


The response was to your claim that "I think what you could say 
is that D lacks _encapsulation_ which is also an OOP concept. So 
D is partially OOP but not fully OOP due to there being no 
encapsulation in the language."

Mike demonstrated clearly that your claim is false.
Feb 15 2023
parent reply ProtectAndHide <ProtectAndHide gmail.com> writes:
On Wednesday, 15 February 2023 at 20:01:12 UTC, bachmeier wrote:

 On Wednesday, 15 February 2023 at 19:44:50 UTC, ProtectAndHide 
 wrote:


 A user-defined type is a type that has a mechanism to keep it 
 representation private.

 D does not support this. It only enables it.

 You (and others) may well argue that D should not enable this 
 (directly), it should only support it (indirectly), and thus 
 allow the language to force an important design decision onto 
 programmers.

 As a programmer, I don't think that is acceptable.


 The response was to your claim that "I think what you could say 
 is that D lacks _encapsulation_ which is also an OOP concept. 
 So D is partially OOP but not fully OOP due to there being no 
 encapsulation in the language."

 Mike demonstrated clearly that your claim is false.



My claims are factually correct.

What Mike is arguing, is that I don't need a 'data hiding' 
mechanism for a user-defined type, because that is already 
provided to me by the 'data hiding' mechanism of the module.

That is his argument.

My argument is that I want 'data hiding' mechanism at the 
user-defined type level as well.

Again, his argument is that i don't need it.. because...

And my argument is, that I want it...

And his arguement is, that I don't need it..

And...

And.....

And.......
Feb 15 2023
next sibling parent ProtectAndHide <ProtectAndHide gmail.com> writes:
On Wednesday, 15 February 2023 at 20:10:31 UTC, ProtectAndHide 
wrote:

...


this is not to be personal, just to make an analogy about the 
point being made:

if Mike was a car salesperson, he'd be arguing that I don't need 
an automatic transmission. I can already do it manually. Why 
should we complicate our design by making an automatic 
tranmission if you can alreay change gears anyway.

Well..do you think I'd end up buying my new car from him?
Feb 15 2023
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 15 February 2023 at 20:10:31 UTC, ProtectAndHide 
wrote:


 What Mike is arguing, is that I don't need a 'data hiding' 
 mechanism for a user-defined type, because that is already 
 provided to me by the 'data hiding' mechanism of the module.

 That is his argument.

 My argument is that I want 'data hiding' mechanism at the 
 user-defined type level as well.

 Again, his argument is that i don't need it.. because...


Wrong. I'm arguing  things:

1. D has encapsulation (you say it doesn't).
2. We don't need a new protection attribute or a redefinition of 
private because D already provides the mechanism to give you what 
you want.
Feb 15 2023
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 16 February 2023 at 02:26:44 UTC, Mike Parker wrote:


 Wrong. I'm arguing  things:


Geez. "I'm arguing 2 things:"
Feb 15 2023
parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Thursday, 16 February 2023 at 02:27:23 UTC, Mike Parker wrote:

 On Thursday, 16 February 2023 at 02:26:44 UTC, Mike Parker 
 wrote:


 Wrong. I'm arguing  things:


 Geez. "I'm arguing 2 things:"


Springboarding off this post:

This thread is vastly dominated by some people who care very much 
about this issue. Comparatively, for instance, I care very little 
because I think D already does it right.

But then the thread will look unbalanced. This is a fundamental 
design flaw in forum software.

So let me just say: I think D does it right. D does not have 
class encapsulation; it has module encapsulation. This is by 
design, and the design is good.
Feb 16 2023
next sibling parent thebluepandabear <therealbluepandabear protonmail.com> writes:
 So let me just say: I think D does it right. D does not have 
 class encapsulation; it has module encapsulation. This is by 
 design, and the design is good.


The design is terrible...
Feb 16 2023
prev sibling parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Thu, Feb 16, 2023 at 08:51:39AM +0000, FeepingCreature via
Digitalmars-d-learn wrote:
[...]

 Springboarding off this post:
 
 This thread is vastly dominated by some people who care very much
 about this issue. Comparatively, for instance, I care very little
 because I think D already does it right.
 
 But then the thread will look unbalanced. This is a fundamental design
 flaw in forum software.
 
 So let me just say: I think D does it right. D does not have class
 encapsulation; it has module encapsulation. This is by design, and the
 design is good.


+1, this issue is wayyy overblown by a vocal minority. D's design
diverges from other languages, but that in itself does not make it a bad
design.  In the context of D it actually makes sense. Saying that D's
design is bad because language X does it differently is logically
fallacious (X is good, Y is not X, therefore Y is bad).


T

-- 
He who sacrifices functionality for ease of use, loses both and deserves
neither. -- Slashdotter
Feb 16 2023
parent reply ProtectAndHide <ProtectAndHide gmail.com> writes:
On Thursday, 16 February 2023 at 13:39:13 UTC, H. S. Teoh wrote:

 On Thu, Feb 16, 2023 at 08:51:39AM +0000, FeepingCreature via 
 Digitalmars-d-learn wrote: [...]

 Springboarding off this post:
 
 This thread is vastly dominated by some people who care very 
 much about this issue. Comparatively, for instance, I care 
 very little because I think D already does it right.
 
 But then the thread will look unbalanced. This is a 
 fundamental design flaw in forum software.
 
 So let me just say: I think D does it right. D does not have 
 class encapsulation; it has module encapsulation. This is by 
 design, and the design is good.


 +1, this issue is wayyy overblown by a vocal minority. D's 
 design diverges from other languages, but that in itself does 
 not make it a bad design.  In the context of D it actually 
 makes sense. Saying that D's design is bad because language X 
 does it differently is logically fallacious (X is good, Y is 
 not X, therefore Y is bad).


 T


It's really the vocal majority that makes this issue overblown.

One person saying they don't like something...dozens deciding to 
weigh in and say how wrong he is. So whose doing the overblowing?

The 'fact' of the matter is, that the vast majority of 
programmers in the most major languages have the capacity to 
explicately declare hidden data associated with their 
user-defined type (class, struct..whatever).

Both the module type, and the class type need this capability.

One without the other leads to the kind of errors I made when I 
first started writing classes in D (which of course I now longer 
use D for).

So for the D's 'majority' to flood this thread saying 'no we're 
right and you're wrong' and all the other major languages in the 
world are wrong, as are their designers, and all the programmers 
using them are blind, and don't really need that capability... I 
mean really? Are we meant to take that seriously?

D was clearly created by procedural programmers for procedural 
programmers.

And again, a language that deliberately forces an important 
design decision onto programmers (one-user-defined-type per 
module just to protect its hidden data), is wrong. D people 
saying its fine, are wrong. It's just wrong.

If you think its not wrong, you are wrong.

A user-defined type where the programmer cannot explicately 
declare protected hidden data, is wrong.

If you think its not wrong, you are wrong.
Feb 16 2023
next sibling parent reply ProtectAndHide <ProtectAndHide gmail.com> writes:
On Thursday, 16 February 2023 at 20:56:00 UTC, ProtectAndHide 
wrote:


My agrument is this:

Objects are data abstractions with an interface of named 
operations and a hidden local state. Does anyone disagree with 
this?

D does not have a language mechanism, but rather a design 
mechanism that supports the above.
By that I mean, you cannot use a language 'declaration' mechanism 
to enforce the above, but rather have to revert to a design 
mechanism - putting the class that represents that object into a 
module by itself. Does anyone disagrre with this?

Forcing programmers to use a design mechanism rather than a 
language mechanism to achieve the above abstraction is wrong. 
This seems to be the source of the disagreement, correct?

So some think its fine to force this onto programmers? That is 
essentially your argument... right?



 Feb 16 2023



  parent reply bachmeier <no spam.net>  writes:


On Thursday, 16 February 2023 at 21:23:53 UTC, ProtectAndHide 
wrote:


 Forcing programmers to use a design mechanism rather than a 
 language mechanism to achieve the above abstraction is wrong. 
 This seems to be the source of the disagreement, correct?


There's no disagreement. It's you posting the same false claim 
again and again (presumably because you're hoping it will come up 
when someone does a search for it, or some similar reason) and 
others explaining why you're wrong.

If you don't want to use the language, don't use it. You have 
your subjective preferences. You are unable to muster a good 
argument in favor of it. There's no reason to (yet again) post 
the same thing over and over.



 Feb 16 2023



 next sibling parent  ProtectAndHide <ProtectAndHide gmail.com>  writes:


On Thursday, 16 February 2023 at 21:56:03 UTC, bachmeier wrote:

 On Thursday, 16 February 2023 at 21:23:53 UTC, ProtectAndHide 
 wrote:


 Forcing programmers to use a design mechanism rather than a 
 language mechanism to achieve the above abstraction is wrong. 
 This seems to be the source of the disagreement, correct?


 There's no disagreement. It's you posting the same false claim 
 again and again (presumably because you're hoping it will come 
 up when someone does a search for it, or some similar reason) 
 and others explaining why you're wrong.

 If you don't want to use the language, don't use it. You have 
 your subjective preferences. You are unable to muster a good 
 argument in favor of it. There's no reason to (yet again) post 
 the same thing over and over.


It's your claim that is false.

What I outlined is correct. I've even shown code that clearly 
demonatrates it.

I don't know how you can call those claims false. They are fact. 
And any D programmers know what I've said is correct.

The disagreement, is whether D should do something about it. Not 
that what I've demonstrated is incorrect.

Also, I don't keep posting just cause I like to doing it. I'm 
responding to people like you who continually make accusations 
against me which are not correct.

Try focusing on the source of the disagreement, and not on 
personal issues.

Then we will not have this constant to and fro. Instead, we will 
end up disagreeing on some language design issue, and that will 
be that.

Stop making it personal!



 Feb 16 2023



prev sibling  parent reply ProtectAndHide <ProtectAndHide gmail.com>  writes:


On Thursday, 16 February 2023 at 21:56:03 UTC, bachmeier wrote:

 On Thursday, 16 February 2023 at 21:23:53 UTC, ProtectAndHide 
 wrote:


 Forcing programmers to use a design mechanism rather than a 
 language mechanism to achieve the above abstraction is wrong. 
 This seems to be the source of the disagreement, correct?


 There's no disagreement. It's you posting the same false claim 
 again and again (presumably because you're hoping it will come 
 up when someone does a search for it, or some similar reason) 
 and others explaining why you're wrong.

 If you don't want to use the language, don't use it. You have 
 your subjective preferences. You are unable to muster a good 
 argument in favor of it. There's no reason to (yet again) post 
 the same thing over and over.



also, I noticed that you intentionally? did not respond to the 
facts that I outlined:

ie.

Objects are data abstractions with an interface of named 
operations and a hidden local state. Does anyone disagree with 
this?

D does not have a language mechanism, but rather a design 
mechanism that supports the above.
By that I mean, you cannot use a language 'declaration' mechanism 
to enforce the above, but rather have to revert to a design 
mechanism - putting the class that represents that object into a 
module by itself. Does anyone disagrre with this?

Forcing programmers to use a design mechanism rather than a 
language mechanism to achieve the above abstraction is wrong. 
This seems to be the source of the disagreement, correct?

So some think its fine to force this onto programmers? That is 
essentially your argument... right?

This is about the language. It's not personal. Don't make it 
personal!



 Feb 16 2023



  parent reply zjh <fqbqrr 163.com>  writes:


On Thursday, 16 February 2023 at 22:25:22 UTC, ProtectAndHide 
wrote:


 also, I noticed that you intentionally? did not respond to the 
 facts that I outlined:

 ie.


They can't refute you, so they have to blame you.
You can't wake up who pretend to sleep.



 Feb 16 2023



  parent reply zjh <fqbqrr 163.com>  writes:


On Friday, 17 February 2023 at 01:13:59 UTC, zjh wrote:


 They can't refute you, so they have to blame you.
 You can't wake up who pretend to sleep.


They don't admit their mistakes! And `D` community is getting 
smaller and smaller!

If I were D author , I would suspect that they are undercover 
agents of other language communities!

Because other languages laughs cry!
`D` don't even have `type-safe` classes.



 Feb 16 2023



  parent  zjh <fqbqrr 163.com>  writes:


On Friday, 17 February 2023 at 01:21:18 UTC, zjh wrote:


 They don't admit their mistakes! And `D` community is getting 
 smaller and smaller!

 Because other languages laughs cry!
 `D` don't even have `type-safe` classes.


The ability of a group of people to open their eyes and tell lies 
is really eye-opening.



 Feb 16 2023



prev sibling  parent reply RTM <riven baryonides.ru>  writes:


On Thursday, 16 February 2023 at 20:56:00 UTC, ProtectAndHide 
wrote:

 Both the module type, and the class type need this capability.


No, they are not.
Look at Go.



 Feb 16 2023



 next sibling parent reply RTM <riven baryonides.ru>  writes:


Data hiding is overrated.
Furthermore, OOP is overrated :-)

https://betterprogramming.pub/object-oriented-programming-the-trillion-dollar-disaster-92a4b666c7c7



 Feb 16 2023



 next sibling parent  ProtectAndHide <ProtectAndHide gmail.com>  writes:


On Friday, 17 February 2023 at 04:58:17 UTC, RTM wrote:

 Data hiding is overrated.
 Furthermore, OOP is overrated :-)

 https://betterprogramming.pub/object-oriented-programming-the-trillion-dollar-disaster-92a4b666c7c7


Submit a request to the C++ Committee to remove private from the 
language.



Do the same for Swift

Do the same for Javasript...

Then watch how they all ridicule you for presenting such an 
absurd proposal ;-)

Oddly enough, then you will know how I feel when I'm ridiculed 
for advocating that D adds a private-like declaration for the 
type - something all those languages have, and the majority of 
the programmers in those languages would be using on a regular 
basis.

As for OOP being overrated, I don't necessarily disagree ;-)

But OOP is a tool that works well, when that tool is the best 
tool for the job.



 Feb 16 2023



prev sibling next sibling parent reply ProtectAndHide <ProtectAndHide gmail.com>  writes:


On Friday, 17 February 2023 at 04:58:17 UTC, RTM wrote:

 Data hiding is overrated.
 Furthermore, OOP is overrated :-)

 https://betterprogramming.pub/object-oriented-programming-the-trillion-dollar-disaster-92a4b666c7c7



What is 'Object-Oriented Programming'? (1991 revised version) 
Bjarne Stroustrup

https://www.stroustrup.com/whatis.pdf



 Feb 16 2023



  parent reply RTM <riven baryonides.ru>  writes:


On Friday, 17 February 2023 at 06:56:08 UTC, ProtectAndHide wrote:


 What is 'Object-Oriented Programming'? (1991 revised version) 
 Bjarne Stroustrup

 https://www.stroustrup.com/whatis.pdf


Thirty years passed since. Lessons were learned. Out of three PLs 
of the newer generation (Rust, Swift, Go), two are not OOP, 
basically.

And no private/public/protected:
https://doc.rust-lang.org/reference/keywords.html
https://go.dev/ref/spec#Keywords

:-P



 Feb 17 2023



 next sibling parent  RTM <riven baryonides.ru>  writes:


Funny, seems I have old news: Rust adopted D-like module 
visibility.

https://doc.rust-lang.org/reference/visibility-and-privacy.html

pub(in path), pub(crate), pub(super), and pub(self)

In addition to public and private, Rust allows users to declare 
an item as visible only within a given scope. The rules for pub 
restrictions are as follows:

pub(in path) makes an item visible within the provided path. path 
must be an ancestor module of the item whose visibility is being 
declared.
pub(crate) makes an item visible within the current crate.
pub(super) makes an item visible to the parent module. This is 
equivalent to pub(in super).
pub(self) makes an item visible to the current module. This is 
equivalent to pub(in self) or not using pub at all.



 Feb 17 2023



prev sibling  parent  ProtectAndHide <ProtectAndHide gmail.com>  writes:


On Friday, 17 February 2023 at 09:56:26 UTC, RTM wrote:

 On Friday, 17 February 2023 at 06:56:08 UTC, ProtectAndHide


 Thirty years passed since. Lessons were learned. Out of three 
 PLs of the newer generation (Rust, Swift, Go), two are not OOP, 
 basically.

 And no private/public/protected:
 https://doc.rust-lang.org/reference/keywords.html
 https://go.dev/ref/spec#Keywords

 :-P


this is not a discussion about one paradigm or language being 
better or worse than another.

btw. neither Rust nor Go claim to support OOP. They don't even 
have a class type.

so it doesn't suprise me they don't have a language mechanism for 
class-type privacy.

for OOP using classes, the class designer should be able to 
expose only that which should be exposed, and no more. in D, 
everything is exposed inside the module, and the only solution D 
provides to prevent this, is to not put any other code in the 
same module as that class - this includes not putting your 
unittests in that module either.

please compare apples with apples, not apples with sardines ;-)



 Feb 17 2023



prev sibling  parent reply ProtectAndHide <ProtectAndHide gmail.com>  writes:


On Friday, 17 February 2023 at 04:58:17 UTC, RTM wrote:

 Data hiding is overrated.
 ...


Actually, data hiding is at the core of using objects, and 
objects are at the core of doing OOP.

" Hiding internal state and requiring all interaction to be 
performed through an object's methods is known as data 
encapsulation — a fundamental principle of object-oriented 
programming."

https://docs.oracle.com/javase/tutorial/java/concepts/object.html

D can 'provide' that encapsulation. That is true. But it does it 
**indirectly**, by requiring the class representing that object 
to not have any other code in the module containing that class. 
If there is any other code in the module with that class 
(including unittests), then that class is no longer encapsulated.

There should be no argument as to whether the statements above 
are correct or not. They are clearly correct.

The only objection people can reasonably raise, is whether its ok 
to provide encapsulation in this manner (i.e. indirectly), or 
whether the language should provide a mechanism whereby the 
progammer can 'declare' the encapsulation.


Javascript.. .. ... that a programmer might want to have more 
explicit access control... since they have it in those languages 
... and those languages represent the vast majority of the worlds 
programmers.

What is surprising, is the level of objection in the D community 
to allow such an option in D.

Since the majority of programmers in the world HAVE this option 
already, there will be continued debate over this issue, should 
they ever come and have a look at D. That much is certain.

But the debate should not be about whether a programmer needs to 
encapsulate their object. That is a choice the programmer should 
make. It's a design decision for them, not for others.

The debate should be whether those programmers should be FORCED 
to put each and every class in its own modules. That's a design 
being forced on the programmer in order to get encapsulation of 
that object.

D forces a 1:1 mapping of class to module in order to provide 
object encapsulation. That is what I don't like. Keep in mind, 
this also means unittests must be in a separate module as well, 
as the unittest in the same module as the class, means the class 
is no longer encapsulated (i.e. the compiler cannot assist you - 
in relation to type safety - when you accidently reference a 
private member - which is what I did when I first came to D - and 
hence, is the reason for my raising this as an issue in the first 
place).

I think this thread has lost any usefulness, because many try 
redirect the issue at hand to something else completely. But this 
post summarises the problem well enough for everyone to 
understand - and choose their side ;-)



 Feb 17 2023



 next sibling parent  ProtectAndHide <ProtectAndHide gmail.com>  writes:


On Friday, 17 February 2023 at 22:58:19 UTC, ProtectAndHide wrote:


Actually, I just now understand 'why' (as opposed to 'how') 
private works in D the way it does.

In D, private within a module is (more-or-less) like static used 
in C outside of a function.

That is, in C it restrains the visibility to the current file, 
and so it does in D (visibility to the current module).

ok fine. That works well in C.

But C does not have classes! (user defined types with their own 
abstraction boundaries).

So what would happen if C got classes then?

Well, we already know -> C++ (private declared within a 
user-defined type, restrains visibility to that type). And so it 


So in essence, the D module is still stuck in the C era it seems.

Now I'm fully convinced that OOP should never, ever, ever, be 
done in D.

Now I can finally move on ;-)



 Feb 17 2023



prev sibling  parent reply RTM <riven baryonides.ru>  writes:


On Friday, 17 February 2023 at 22:58:19 UTC, ProtectAndHide wrote:


 Actually, data hiding is at the core of using objects, and 
 objects are at the core of doing OOP.


Let's look at Stroustrup's definition:

```
Object-oriented programming is programming using inheritance. 
Data abstraction is programming using user-defined types. With 
few exceptions, object-oriented programming can and ought to be a 
superset of data abstraction.
```

Data hiding is orthogonal to OOP. It can be used without 
inheritance, on struct members. Inheritance can be used without 
it.



 Javascript.. .. ... that a programmer might want to have more 
 explicit access control... since they have it in those 
 languages ... and those languages represent the vast majority 
 of the worlds programmers.


It's the old way, the first attempt. A mistake. Modern 
programming languages tend to implement it differently, or even 
reject.

For example, in Google's Dart it was explicitly rejected:

https://github.com/dart-lang/sdk/issues/33383
```
It's not the first time this has been requested, but we have no 
current plan to add such keywords.

There is a reason Dart does not use class based privacy.
Dart allows dynamic invocations. If you write dynamic x = 
someObject(); x.foo; then the foo access does not know the class 
of the object in x. It must work independently of that.
Now, if x has a class with a private foo, should that function 
then be found? That depends on whether the access x.foo is inside 
that class. If it's protected, then it depends on whether the 
access is inside a subclass of the declaring class. That adds a 
lot of overhead to dynamic accesses. It's not impossible, but 
it's just not something that the Dart language is well suited for.

The library based privacy that Dart has is allows us to 
syntactically detect private member accesses, and use renaming 
per library to allow a more efficient implementation of dynamic 
access.

If we ever add some other sort of privacy, it's more likely to be 
instance based than class based. That means that you can only 
access such members through this or super, which ensures that we 
always know the type of the receiver and we avoid dynamic 
accesses.
```


 What is surprising, is the level of objection in the D 
 community to allow such an option in D.


No offense, but it looks like your surprise comes from your 
inexperience.



 Feb 17 2023



  parent reply ProtectAndHide <ProtectAndHide gmail.com>  writes:


On Saturday, 18 February 2023 at 06:12:47 UTC, RTM wrote:

 No offense, but it looks like your surprise comes from your 
 inexperience.


More likely is comes from my experience .. otherwise I wouldn't 
be surprised ;-)

btw.

I love the way that Brayan Martinez (Senior Developer with Azure, 
Spring Boot, and Flutter.) outlines all the well-thoughout out 
positive reasons.
https://github.com/dart-lang/sdk/issues/33383#issuecomment-395987115

Then the next guy says..."Sounds like personal preference."
https://github.com/dart-lang/sdk/issues/33383#issuecomment-396031405

As for me, I don't even know what Dart is ;-)

I guess we could all revert to:

class foo()
{
   int _x; // this is private. please don't use it outside of this 
class.
}

and hope that people read and comply with that instruction - 
cause we all know how great people are at following instructions 
;-)

D could just add a new keyword (problem solved!)

class foo()
{
   intern int x; // x is internal to foo.
}

of course, then we get to the next issue ... protected ;-)

No, I think D is not for me.



 Feb 17 2023



 next sibling parent  zjh <fqbqrr 163.com>  writes:


On Saturday, 18 February 2023 at 06:55:49 UTC, ProtectAndHide 
wrote:

 No, I think D is not for me.



They don't care about the needs of `D` users!
They won't listen ,even if you said it thousand times.



 Feb 17 2023



prev sibling  parent reply RTM <riven baryonides.ru>  writes:


On Saturday, 18 February 2023 at 06:55:49 UTC, ProtectAndHide 
wrote:


 More likely is comes from my experience .. otherwise I wouldn't 
 be surprised ;-)


Now that's a screaming sign:

https://media.licdn.com/dms/image/C4D12AQEymZALzWVDXQ/article-cover_image-shrink_600_2000/0/1629008577928?e=2147483647&v=beta&t=yBj1ft4wivYyPzpwtwlYFlBpvw_PwSgNqx_ixFIGcOM


 No, I think D is not for me.


Implying that D language maintainers should prefer your personal 
taste over modern practice?

Don't like it, don't use it.



 Feb 17 2023



 next sibling parent  ProtectAndHide <ProtectAndHide gmail.com>  writes:


On Saturday, 18 February 2023 at 07:49:03 UTC, RTM wrote:

 Implying that D language maintainers should prefer your 
 personal taste over modern practice?


So it's now modern practice to dump the principle of data hiding?

I'm sure that will surely advance the science of programming.


 Don't like it, don't use it.


On this we can agree.

D has an ongoing, and ever-getting-stronger love affair with C. 
So for OO programmers, I'd argue there are far better languages 
available - ones that provide the tools to make OOP easier, 
rather than harder, and give programmers choice over their 
design, instead of forcing a design upon them.

A language that claims to support OOP using classes, but provides 
no language mechanism to the programmer so they can explicately 
hide members, but rather ***INSISTS*** that all class members be 
wide open to use by all other code in the module, is just a joke 
- IMO.

Better for D to stop making that claim, and remove classes from 
the language.



 Feb 18 2023



prev sibling  parent reply ProtectAndHide <ProtectAndHide gmail.com>  writes:


On Saturday, 18 February 2023 at 07:49:03 UTC, RTM wrote:

 On Saturday, 18 February 2023 at 06:55:49 UTC, ProtectAndHide 
 wrote:


 More likely is comes from my experience .. otherwise I 
 wouldn't be surprised ;-)


 Now that's a screaming sign:

 https://media.licdn.com/dms/image/C4D12AQEymZALzWVDXQ/article-cover_image-shrink_600_2000/0/1629008577928?e=2147483647&v=beta&t=yBj1ft4wivYyPzpwtwlYFlBpvw_PwSgNqx_ixFIGcOM


 No, I think D is not for me.


 Implying that D language maintainers should prefer your 
 personal taste over modern practice?

 Don't like it, don't use it.


The more I look at D, the more I like C++.



 Feb 18 2023



 next sibling parent  ProtectAndHide <ProtectAndHide gmail.com>  writes:


On Saturday, 18 February 2023 at 21:23:24 UTC, ProtectAndHide 
wrote:


Here is (one example) of the change I would like to see in D:

if private is declared against a member inside a class (or 
struct), then that member is visible only inside that class or 
struct. That is what most programmers in the world would expect. 
(most, not all).

if you want open access to that class, from other code in the 
same module, you mark that class (or struct) as open.

e.g

class foo
{
  private int x; // visible in this class only

}

open class bar
{
  private int y; // visible throughout the module - the same as it 
currently works.
}

so all you'd have to do, is mark your class (or struct) as open, 
and then anyone reading your code will immediately know that 
other code in the module may form part of the specification of 
this class.

so simple.



 Feb 18 2023



prev sibling next sibling parent reply Adam D Ruppe <destructionator gmail.com>  writes:


On Saturday, 18 February 2023 at 21:23:24 UTC, ProtectAndHide 
wrote:

 The more I look at D, the more I like C++.


cya



 Feb 18 2023



 next sibling parent  ProtectAndHide <ProtectAndHide gmail.com>  writes:


On Saturday, 18 February 2023 at 22:03:48 UTC, Adam D Ruppe wrote:

 On Saturday, 18 February 2023 at 21:23:24 UTC, ProtectAndHide 
 wrote:

 The more I look at D, the more I like C++.


 cya


I bet that's what you say to anyone who dares want to have hidden 
members inside their class.

All the threads are public and on record ;-)



 Feb 18 2023



prev sibling  parent  ProtectAndHide <ProtectAndHide gmail.com>  writes:


On Saturday, 18 February 2023 at 22:03:48 UTC, Adam D Ruppe wrote:

 On Saturday, 18 February 2023 at 21:23:24 UTC, ProtectAndHide 
 wrote:

 The more I look at D, the more I like C++.


 cya


of course, I do have my own fork ;-)

where you CAN declare private members for your class.

and.. where all the importC nonsense, does not even exist in the 
compiler.

it's not public.. because I prefer private.



 Feb 18 2023



prev sibling  parent reply ProtectAndHide <ProtectAndHide gmail.com>  writes:


On Saturday, 18 February 2023 at 21:23:24 UTC, ProtectAndHide 
wrote:

 The more I look at D, the more I like C++.


I should correct that.


Swift, Javascript .. and the list goes on..

All D needed to provide, was a way to let the programmer declare 
a private member inside a class. But that is too much for the 
language to handle, and so objectionable to many D users, that it 
will never happen. I have no problem with that, because, i really 

Swift, Javascript .. and the list goes on..that you supposedly 
want to attract to D (although, I suspect nobody actually wants 
to attract them, since they'll expect to be able to declare a 
private member within a class.

So.. good luck with the .. ummm.. D thing.



 Feb 18 2023



 next sibling parent  thebluepandabear <thereabluepandabear protonmail.com>  writes:


On Sunday, 19 February 2023 at 00:21:42 UTC, ProtectAndHide wrote:

 On Saturday, 18 February 2023 at 21:23:24 UTC, ProtectAndHide 
 wrote:

 The more I look at D, the more I like C++.


 I should correct that.


 Swift, Javascript .. and the list goes on..

 All D needed to provide, was a way to let the programmer 
 declare a private member inside a class. But that is too much 
 for the language to handle, and so objectionable to many D 
 users, that it will never happen. I have no problem with that, 
 because, i really do have many other options - as do all the 

 on..that you supposedly want to attract to D (although, I 
 suspect nobody actually wants to attract them, since they'll 
 expect to be able to declare a private member within a class.

 So.. good luck with the .. ummm.. D thing.


Based. I've already switched to TypeScript, Java, etc. Goodbye D.



 Feb 18 2023



prev sibling  parent  thebluepandabear <thereabluepandabear protonmail.com>  writes:


On Sunday, 19 February 2023 at 00:21:42 UTC, ProtectAndHide wrote:

 On Saturday, 18 February 2023 at 21:23:24 UTC, ProtectAndHide 
 wrote:

 The more I look at D, the more I like C++.


 I should correct that.


 Swift, Javascript .. and the list goes on..

 All D needed to provide, was a way to let the programmer 
 declare a private member inside a class. But that is too much 
 for the language to handle, and so objectionable to many D 
 users, that it will never happen. I have no problem with that, 
 because, i really do have many other options - as do all the 

 on..that you supposedly want to attract to D (although, I 
 suspect nobody actually wants to attract them, since they'll 
 expect to be able to declare a private member within a class.

 So.. good luck with the .. ummm.. D thing.


Even if D did have the private feature, the ecosystem and 
community is too small for this language to be a viable option. 
Also D is not used on the job market, so good luck finding a D 
job.



 Feb 18 2023



prev sibling  parent  ProtectAndHide <ProtectAndHide gmail.com>  writes:


On Friday, 17 February 2023 at 04:43:11 UTC, RTM wrote:

 On Thursday, 16 February 2023 at 20:56:00 UTC, ProtectAndHide 
 wrote:

 Both the module type, and the class type need this capability.


 No, they are not.
 Look at Go.


Go does not have classes.



 Feb 16 2023



prev sibling next sibling parent reply ProtectAndHide <ProtectAndHide gmail.com>  writes:


On Thursday, 16 February 2023 at 02:26:44 UTC, Mike Parker wrote:

 On Wednesday, 15 February 2023 at 20:10:31 UTC, ProtectAndHide 
 wrote:


 What Mike is arguing, is that I don't need a 'data hiding' 
 mechanism for a user-defined type, because that is already 
 provided to me by the 'data hiding' mechanism of the module.

 That is his argument.

 My argument is that I want 'data hiding' mechanism at the 
 user-defined type level as well.

 Again, his argument is that i don't need it.. because...


 Wrong. I'm arguing  things:

 1. D has encapsulation (you say it doesn't).
 2. We don't need a new protection attribute or a redefinition 
 of private because D already provides the mechanism to give you 
 what you want.


Honestly. How hard is it for you to accept? It's so simple I 
could explain it to first year programmer!

It's really straight forward, obvious, correct, and can be 
demonstrated like this:

// foo type has no ability (at the type level)
// to hide anything from other code in the module.
// this is fact. I'm not making it up!
// There is nothing to argue against here. It's just fact.

module test;
 safe:

import std;


Javascript...programmers - beware!

void main()
{
     foo f = new foo;

     f.x = 20; // D provides no way to prevent this from occuring 
as there is no mechanism at the type level to do this. Instead 
you have to put foo in a module by itself, so no other code can 
access x. So EVERY user-defined type that wants data hiding from 
users of that type (including other code in the module using that 
type), must be in its own module.


     writeln(f.x);
}


I understand your argument completely. Just put foo in its own 
module. I get it.

What you don't get, is that I want such design decisions to be in 
my hands, and not yours.

That is, I want a mechanism at the type level as well.

You don't want me to have that. Well fine.

But at stop mispresenting what I'm saying. What I've stated 
above, is what I'm saying.. no more.. no less.



 Feb 15 2023



  parent  thebluepandabear <therealbluepandabear protonmail.com>  writes:


 But at stop mispresenting what I'm saying. What I've stated 
 above, is what I'm saying.. no more.. no less.


Well said.

Its not that hard to understand, folks.



 Feb 16 2023



prev sibling  parent reply ProtectAndHide <ProtectAndHide gmail.com>  writes:


On Thursday, 16 February 2023 at 02:26:44 UTC, Mike Parker wrote:

 On Wednesday, 15 February 2023 at 20:10:31 UTC, ProtectAndHide 
 wrote:


 What Mike is arguing, is that I don't need a 'data hiding' 
 mechanism for a user-defined type, because that is already 
 provided to me by the 'data hiding' mechanism of the module.

 That is his argument.

 My argument is that I want 'data hiding' mechanism at the 
 user-defined type level as well.

 Again, his argument is that i don't need it.. because...


 Wrong. I'm arguing  things:

 1. D has encapsulation (you say it doesn't).


My code in my previous post should make it clear what I'm saying. 
Stop misrepresenting my argument.


 2. We don't need a new protection attribute or a redefinition 
 of private because D already provides the mechanism to give you 
 what you want.


First, who is 'we'? Likely the programmers that do need it, have 
decided to go elsewhere (where they can get it, and have likely 
had it, for decades - not in some obscure language, but in the 
most major languages being used.).

Second, you don't provide what I want. You can keep saying that 
you do, but that doesn't change it.


D does not. So don't say it does, until it does...and that day 
will come ;-)



 Feb 15 2023



  parent  ProtectAndHide <ProtectAndHide gmail.com>  writes:


On Thursday, 16 February 2023 at 02:56:28 UTC, ProtectAndHide 
wrote:


What a joke. Even Javascript can do this (and the compile will 
enforce it too).

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Private_class_fields



 Feb 15 2023



prev sibling  parent  ProtectAndHide <ProtectAndHide gmail.com>  writes:


On Wednesday, 15 February 2023 at 19:44:50 UTC, ProtectAndHide 
wrote:


"The basic support for programming with data abstraction consists 
of facilities for defining a set of operations (functions and 
operators) for a type and for restricting the access to objects 
of the type to that set of operations."

D does not enable this. It only supports it, because the 
programmer has to revert to 'data hiding techniques' at the 
module level, instead of at the type level.

D should enable programmers to express and utilise 'proper' 

enables programmers to do this.

What is 'Object-Oriented Programming'? (1991 revised version) 
Bjarne Stroustrup

https://www.stroustrup.com/whatis.pdf



 Feb 15 2023



prev sibling  parent  ProtectAndHide <ProtectAndHide gmail.com>  writes:


On Wednesday, 15 February 2023 at 08:56:00 UTC, Mike Parker wrote:

 Our friend of many forum handles misses no opportunity to 
 return to this putrid horse corpse to beat it some more, but 
 the meaning of private isn't going to change. This is D's 
 approach to encapsulation.


It seems the only beating go on here, is the beating your handing 
out.

If someone raises a comment about type private, and you all jump 
in any beat on him, then who is the real victim here?

Try to keep it about language design, and stop getting personal.



 Feb 15 2023



prev sibling  parent  ProtectAndHide <ProtectAndHide gmail.com>  writes:


On Wednesday, 15 February 2023 at 07:23:39 UTC, thebluepandabear 
wrote:

 On Wednesday, 15 February 2023 at 02:14:30 UTC, Mike Parker 
 wrote:

 On Wednesday, 15 February 2023 at 01:16:00 UTC, 
 thebluepandabear wrote:


 I think what you could say is that D lacks _encapsulation_ 
 which is also an OOP concept. So D is partially OOP but not 
 fully OOP due to there being no encapsulation in the language.


 D does not lack encapsulation, it's just that the unit of 
 encapsulation is the module. Everything private in a module is 
 encapsulated from the perspective of the public API.

 If you really want to prevent anything inside a module from 
 accessing the private parts of a class, you can put the class 
 in its own module.

 Must we continue beating this horse?


 Why is the unit of encapsulation the module though? Makes no 
 sense.



It does make sense. But not if the language also provides 
user-defined types. That is explained in the Stroustup paper I 
cited.

That is, a language that provides modules as well as user-defined 
types, should provided encapsulation for both. D does that, but 
for user-defined types it doesn't in the context of other code in 
the same module as that type. That is why in D you are 'forced' 
to put that type in its own module 'just' to encapsulate it from 
other code that would have otherwise been in the same module.

No. It makes no sense. A user-defined type should be able to 
protect hidden data from other code within the same module. That 
really doesn't sound that extreme to me ;-)



 Feb 15 2023



prev sibling  parent reply forky <forky gmail.com>  writes:


On Friday, 10 February 2023 at 07:04:31 UTC, Max Samukha wrote:

 ...
 Having class-private doesn't preclude module-private. Dennis 
 even submitted a PR implementing class-private, but it stalled 
 because people couldn't agree on whether class-private should 
 be "private to class" or "private to class instance".


It likely the 'disagreement' was intentional .. i.e. to stall ;-)

But in any case, it should be class private.



 Feb 19 2023



  parent reply FeepingCreature <feepingcreature gmail.com>  writes:


On Monday, 20 February 2023 at 05:21:44 UTC, forky wrote:

 On Friday, 10 February 2023 at 07:04:31 UTC, Max Samukha wrote:

 ...
 Having class-private doesn't preclude module-private. Dennis 
 even submitted a PR implementing class-private, but it stalled 
 because people couldn't agree on whether class-private should 
 be "private to class" or "private to class instance".


 It likely the 'disagreement' was intentional .. i.e. to stall 
 ;-)

 But in any case, it should be class private.


There have now been three pages produced by three people all 
agreeing with each other.

At what point does it start being spam?



 Feb 19 2023



 next sibling parent  thebluepandabear <therealbluepandabear protonmail.com>  writes:


 But in any case, it should be class private.


 There have now been three pages produced by three people all 
 agreeing with each other.

 At what point does it start being spam?


Having a discussion !== spam.



 Feb 19 2023



prev sibling  parent  Mike Parker <aldacron gmail.com>  writes:


On Monday, 20 February 2023 at 06:26:34 UTC, FeepingCreature 
wrote:


 There have now been three pages produced by three people all 
 agreeing with each other.

 At what point does it start being spam?


Yes, it's all just noise now. Let's end it here. Further posts in 
this thread will be deleted.



 Feb 19 2023