www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - private(this) vs LINT

reply Daniel N <no public.email> writes:
I was just thinking, if we had a standard linter, it could solve 
many issues without bloating the language, since the compiler 
exists as a library it should not be too difficult to maintain 
either.

This way we can both keep the cake and eat it.
Jun 27 2022
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
We have a standard linter, only it doesn't use semantic analysis which 
is what would be required for this.

But yes, dmd-fe should be used in tools like dscanner, dfmt and dcd.
Jun 27 2022
prev sibling next sibling parent forkit <forkit gmail.com> writes:
On Monday, 27 June 2022 at 20:23:26 UTC, Daniel N wrote:

 I was just thinking, if we had a standard linter, it could 
 solve many issues without bloating the language, since the 
 compiler exists as a library it should not be too difficult to 
 maintain either.

 This way we can both keep the cake and eat it.


I could not disagree more.

'classes' and 'information hiding' are 'entangled'.

I've seen many arguments against adding private(this), but no 
argument (that can be taken seriously), that you shouldn't be 
able to apply the 'information hiding' principle to a class.

In D, you're told you can do this by putting the class it's own 
module.

My argument, is that this principle is so tightly entangled with 
the class concept, that it should be availabe to do with the 
class type itself.

I think, in principle at least, my argument is a stronger 
argument, than the one-class-to-a-module argument.

But why you would want to bring a linter in to solve this, 
puzzles me even more than a language that supports classes, but 
doesn't having a means (an option) to apply the information 
hiding principle *within* the class type itself.

In terms of the ever increasing move towards being able to 
improve the provability of your code, then yes, a linter will 
have to come into play.
Jun 27 2022
prev sibling next sibling parent reply zjh <fqbqrr 163.com> writes:
On Monday, 27 June 2022 at 20:23:26 UTC, Daniel N wrote:

 I was just thinking, if we had a standard linter, it could 
 solve many issues without bloating the language, since the 
 compiler exists as a library it should not be too difficult to 
 maintain either.



`D` isn't it out of the box? Why do you need `'linter'`? If you 
need it, `Sb` is making a mistake.
Jun 27 2022
parent reply Daniel N <no public.email> writes:
On Tuesday, 28 June 2022 at 00:18:17 UTC, zjh wrote:

 On Monday, 27 June 2022 at 20:23:26 UTC, Daniel N wrote:

 I was just thinking, if we had a standard linter, it could 
 solve many issues without bloating the language, since the 
 compiler exists as a library it should not be too difficult to 
 maintain either.



 `D` isn't it out of the box? Why do you need `'linter'`? If you 
 need it, `Sb` is making a mistake.


I don't understand this argument, we deliver dub as a separate 
tool together with dmd it's not part of the dmd binary either, 
you still can use dub "out of the box", all you have to do is to 
include the official linter with the standard installation of dmd.
Jun 28 2022
parent reply zjh <fqbqrr 163.com> writes:
On Tuesday, 28 June 2022 at 13:49:16 UTC, Daniel N wrote:

 On Tuesday, 28 June 2022 at 00:18:17 UTC, zjh wrote:



 you still can use dub "out of the box", all you have to do is 
 to include the official linter with the standard installation 
 of dmd.


If you need `'linter'`, why not `'integrate'` to `'DMD'`, just 
like `'unittest'`.
I haven't used 'linter'. As a `'professional'` compiler,If dmd 
has `builtin` linter and added a switch. Wouldn't it be better?
Jun 28 2022
next sibling parent reply Daniel N <no public.email> writes:
On Tuesday, 28 June 2022 at 14:48:36 UTC, zjh wrote:

 On Tuesday, 28 June 2022 at 13:49:16 UTC, Daniel N wrote:

 On Tuesday, 28 June 2022 at 00:18:17 UTC, zjh wrote:



 you still can use dub "out of the box", all you have to do is 
 to include the official linter with the standard installation 
 of dmd.


 If you need `'linter'`, why not `'integrate'` to `'DMD'`, just 
 like `'unittest'`.
 I haven't used 'linter'. As a `'professional'` compiler,If dmd 
 has `builtin` linter and added a switch. Wouldn't it be better?


Yes, but I know Walter, he mentioned many times his dislike for 
compiler switches and warnings and he raised some very good 
points, which I partially agree with, but his dislike of switches 
is even stronger than mine.

Imagine four innocent small switches -A -B -C -D, if you can 
toggle all of these the result is a combinatorial explosion, 
because some bugs might only manifest in certain combinations and 
thus the required testing time increases greatly.

If "we" make our own tools with stricter warnings that can be 
tuned to everyones individual preference, there is 0 risk of 
compiler regressions.
Jun 28 2022
next sibling parent reply forkit <forkit gmail.com> writes:
On Tuesday, 28 June 2022 at 16:06:54 UTC, Daniel N wrote:

 Yes, but I know Walter, he mentioned many times his dislike for 
 compiler switches and warnings and he raised some very good 
 points, which I partially agree with, but his dislike of 
 switches is even stronger than mine.


Well. In this case, Walter is right ;-)



 Imagine four innocent small switches -A -B -C -D, if you can 
 toggle all of these the result is a combinatorial explosion, 
 because some bugs might only manifest in certain combinations 
 and thus the required testing time increases greatly.


That's why I would not accept the -fe thing you mention.

The correctness of my unittest should not depend on whether i 
remember to use a specific compiler switch.


 If "we" make our own tools with stricter warnings that can be 
 tuned to everyones individual preference, there is 0 risk of 
 compiler regressions.


There is a case to be made, for a linter, obviously.

I disagree strongly, that a linter should be used to verify the 
encapsulation of a class (in terms of what something like 
private(this) would do.)

This is not a 'personal preference'. I wish people would stop 
using that argument against the idea. The ability to selectively 
make member variables private to the class, is something millions 
of programmers have at their finger tips everyday, and have had 
it, for decades!

The principle of information hiding, is at the core of good 
programming practice.

Indeed, everything in a module is pretty much hiding something. I 
just cannot fathom why a programming language would not have an 
option to do that explicately for a class type. I've never heard 
an argument that makes even the slightest sense to me.

I do feel sad, that I cannot promote D over here in Australia, 
because it just fails to recognise the importance of this, in the 
life of millions of programmers.

It's an established idiom, that you cannot do in D. It's really 
sad. That code I presented is why I still don't use classes in D, 
even after using D for almost 7 years now.

Instead, people seem more interested in '=>' than encapsulation ??
Jun 28 2022
parent reply Daniel N <no public.email> writes:
On Tuesday, 28 June 2022 at 20:29:27 UTC, forkit wrote:

 On Tuesday, 28 June 2022 at 16:06:54 UTC, Daniel N wrote:


 The correctness of my unittest should not depend on whether i 
 remember to use a specific compiler switch.


But what if your favourite editor automatically highlighted the 
entire line with red?


 This is not a 'personal preference'. I wish people would stop 
 using that argument against the idea.


After being exposed to D, I usually end up trying to emulate it 
when I am forced to work in other languages. For this reason some 
of my C++ files are filled with 20+ friend declarations just so I 
can do what I want inside that file...

Some people hate goto and some love it.



 Jun 28 2022



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


On Tuesday, 28 June 2022 at 20:58:56 UTC, Daniel N wrote:

 But what if your favourite editor automatically highlighted the 
 entire line with red?


my favourite editor, is the one I wrote myself ;-)


 After being exposed to D, I usually end up trying to emulate it 
 when I am forced to work in other languages. For this reason 
 some of my C++ files are filled with 20+ friend declarations 
 just so I can do what I want inside that file...


But C++ gives *you* a choice right?

I'm not sure continuing to compare D to C++ is all that benefical 
anymore.

I'd recommend you have a look at Swift. Then try comparing D to 
Swift, and you will come to very different conclusions.



 Some people hate goto and some love it.


Again, *you* can choose to use goto, or not.

You *cannot* chose to 'explicately' declare private members, 
within the class itself. D has made the design choice for you. 
The are pros and cons for that decision. But the biggest con, is 
that this choice has been completely eliminated from the language.


Javascript.......

Those languages represent a pretty big portion of programmers 
worldwide - who may or may not use private member variable in 
their day to day tasks, but they all have the choice to do so, or 
not.

There's really no 'nice' way to frame this. Removing 'choice' for 
this very substantial idiom, is one of D's biggest design 
failures IMO. (yes, others have a different opinion, which of 
course is just fine. This is just mine).

I cannot use classes in a language where I have to **constantly** 
write notes in the code, just to remind myself, and others, to 
use the public interface, and not directly read/mutate a private 
member.

Again, that mistake I initially made in the unittest of that 
unsafeVector code I put in my post, was a *genuine* mistake I 
made only yesterday!

I don't know what the solution to that is. Put every unittest of 
a class in its own module perhaps?



 Jun 28 2022



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


On Tuesday, 28 June 2022 at 20:58:56 UTC, Daniel N wrote:


I'm reading a thesis at the moment, and I was just struck by this 
statement:

"the price of enabling cooperative interaction is that 
destructive interference is enabled as well."

Without something like private(this), hazardous interactions are 
inevitable, and will increase with scale (e.g. having 20+ friend 
functions in your class ;-)

Of course useless isolation is not ideal either.

Another quote from the thesis:

"As language and system designers, our goal is to help 
programmers move into the upper right corner, where the 
interactions needed for cooperation are enabled while minimizing 
the extent to which problematic interactions are thereby also 
enabled."

That is precisely what private(this) could help facilitate.



 Jun 28 2022



  parent reply The Zealot <zod zod.zod>  writes:


On Tuesday, 28 June 2022 at 22:03:54 UTC, forkit wrote:

 On Tuesday, 28 June 2022 at 20:58:56 UTC, Daniel N wrote:


 Without something like private(this), hazardous interactions 
 are inevitable, and will increase with scale (e.g. having 20+ 
 friend functions in your class ;-)


this is just not true. don't put the damm class in module scope 
if you don't want it accessible.
It's just your unwillingness to adjust your programming to the 
language that causes these problems. The language offers enough 
tools to deal with it, you just don't accept them as valid, 
because you are used to _your perceived correct way of proper 
encapsulation_.

In reality the encapsulation boder is totally arbitrary. And you 
have failed to even give one _real world_ example of a bug it 
would have prevented.
In reality, noone is randomly accessing private state. It's a non 
issue in languages that don't have the feature.

And im most cases i'd argue that private(this) would actually 
enurage bad code design, so there is reason not to have it, like 
goto.

Anyway, feel free to write a linter, i'm sure there are other 
people who would apreciate it.



 Jun 30 2022



  parent reply bauss <jj_1337 live.dk>  writes:


On Thursday, 30 June 2022 at 11:36:01 UTC, The Zealot wrote:

 On Tuesday, 28 June 2022 at 22:03:54 UTC, forkit wrote:

 On Tuesday, 28 June 2022 at 20:58:56 UTC, Daniel N wrote:


 Without something like private(this), hazardous interactions 
 are inevitable, and will increase with scale (e.g. having 20+ 
 friend functions in your class ;-)


 this is just not true. don't put the damm class in module scope 
 if you don't want it accessible.


Don't put  nogc, just stop GC allocations yourself.



 Jun 30 2022



  parent reply The Zealot <zod zod.zod>  writes:


On Thursday, 30 June 2022 at 11:37:30 UTC, bauss wrote:

 On Thursday, 30 June 2022 at 11:36:01 UTC, The Zealot wrote:

 On Tuesday, 28 June 2022 at 22:03:54 UTC, forkit wrote:

 On Tuesday, 28 June 2022 at 20:58:56 UTC, Daniel N wrote:


 Without something like private(this), hazardous interactions 
 are inevitable, and will increase with scale (e.g. having 20+ 
 friend functions in your class ;-)


 this is just not true. don't put the damm class in module 
 scope if you don't want it accessible.


 Don't put  nogc, just stop GC allocations yourself.


you can do that without  nogc ;) don't link in the GC.
But my point is you _should not_ put the class in module scope in 
the first place, it doen't belong there. if it has private parts, 
it is an implementation detail and should not be visible at all, 
but an _interface_ should be used. and if you need inheritance, 
it _should_ be placed in it's own module.

e.g.
```
interface Foo {
}
Foo fn() {
    static class Bar : Foo { int private_x; } // private_x access 
is limited to fn() scope
    return new Bar ();
}
```



 Jun 30 2022



  parent  Max Samukha <maxsamukha gmail.com>  writes:


On Thursday, 30 June 2022 at 14:55:47 UTC, The Zealot wrote:


 e.g.
 ```
 interface Foo {
 }
 Foo fn() {
    static class Bar : Foo { int private_x; } // private_x 
 access is limited to fn() scope
    return new Bar ();
 }
 ```


A way to success: impose an unnatural level of encapsulation and 
then offer a bunch of ugly kludges to work around that.



 Jun 30 2022



prev sibling  parent  zjh <fqbqrr 163.com>  writes:


On Tuesday, 28 June 2022 at 16:06:54 UTC, Daniel N wrote:


 If "we" make our own tools with stricter warnings that can be 
 tuned to everyones individual preference, there is 0 risk of 
 compiler regressions.


I don't really care. Anyway, at least I can use `advanced tools`.

It would be better if `'d'` had a more detailed introduction to 
the corresponding `'VIM'` tool. e.g. to complete the word, adding 
some `specific steps`. Otherwise, I can't use the tool after 
installing it.



 Jun 28 2022



prev sibling  parent  Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com>  writes:


On Tuesday, 28 June 2022 at 14:48:36 UTC, zjh wrote:

 If you need `'linter'`, why not `'integrate'` to `'DMD'`, just 
 like `'unittest'`.
 I haven't used 'linter'. As a `'professional'` compiler,If dmd 
 has `builtin` linter and added a switch. Wouldn't it be better?


Different projects have different guidelines and needs. Linting 
can also be a precursor to language changes, basically a low 
threshold way to test things out.



 Jun 28 2022



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


On Monday, 27 June 2022 at 20:23:26 UTC, Daniel N wrote:

 I was just thinking, if we had a standard linter, it could 
 solve many issues without bloating the language, since the 
 compiler exists as a library it should not be too difficult to 
 maintain either.

 This way we can both keep the cake and eat it.


I'm curious how a linter would have helped me here
(see the comment I had to make ***to myself** in the unittest 
section)

// ---
module test;

class unsafeVector
{
   private:
     size_t *elem;
     immutable size_t sz;

   public:
     this(size_t s)
     {
         elem = cast(size_t*)new size_t[s];
         sz = s;
     }

     auto ref opIndex(size_t i)
     {
         return elem[i];
     }

     auto ref opSlice(size_t start, size_t end)
     {
         return elem[start .. end];
     }

     auto ref opDollar()
     {
         return sz;
     }

     auto size()
     {
         return sz;
     }
}

// compile with: -unittest -main
unittest
{
     import std;

     unsafeVector v = new unsafeVector(5);

     // Initialise each element with a different value.
     // NOTE TO SELF: Be sure to use the public interface here.
     // Don't accidently use v.sz like I did intially.
     for (int i = 0; i < v.size(); i++)
     {
         v[i] = i+1;
     }

     assert(v[0..3] == [1,2,3] );
     assert(v[0..$] == [1,2,3,4,5]);
     assert(v[$-1] == 5);

     v[2] = 999;
     assert(v[2] == 999);
}

//-----



 Jun 27 2022



  parent  Daniel N <no public.email>  writes:


On Tuesday, 28 June 2022 at 03:52:08 UTC, forkit wrote:

 On Monday, 27 June 2022 at 20:23:26 UTC, Daniel N wrote:

 I was just thinking, if we had a standard linter, it could 
 solve many issues without bloating the language, since the 
 compiler exists as a library it should not be too difficult to 
 maintain either.

 This way we can both keep the cake and eat it.


 I'm curious how a linter would have helped me here
 (see the comment I had to make ***to myself** in the unittest 
 section)



     // Don't accidently use v.sz like I did intially.
     for (int i = 0; i < v.size(); i++)


dmd-fe would have told you don't use 'sz' as it is private.



 Jun 28 2022