On Monday, 5 November 2018 at 05:55:02 UTC, unprotected-entity wrote:
> On Saturday, 3 November 2018 at 21:28:22 UTC, Stanislav Blinov wrote:
>>
>> The only difference is that `func` became a member function. And now what? You can just as easily "forget" what's in your struct/class as in your whole module.
>
> ok. Now, what are your options then (assuming you want an independent type)?
>
> (option 1) define one encapsulated type, per module.
> (option 2) have a means for type independence within a module - i.e. selective hiding.

Option 3 - don't access private state unless you intend to. That's literally how you write implementations, in pretty much any language that has access modifiers.

> D only gives you one choice here, not two.

Nope. You can have a type spanning several modules. That's what packages do, among other things.

> I would say, that your response backs up my argument, that is, a second option might actually be worthwhile. perhaps, something like: __private

No, it really doesn't. Your argument was that the programmer might accidentally forget, and I've shown quite clearly that no keyword is going to protect them from that. If you can forget in module scope, you can forget in class scope. There can be only one solution: don't forget. As in: stop inventing imaginary examples. People, in practice, don't "accidentally" modify the guts of their own types. That horse is quite dead, I'm afraid.

> (now __private is everything private already is, but additionally, its private outside the scope of the type declaring it, and now, you'd get a compile time guarantee of  correctness - e.g. if you accidently tried to ignore that types independence.

No, you do not. You still have that same "problem" inside the type's definition.

> It's call 'type encapsulation' ;-)

If you're afraid of implicit conversions, define your own type that disallows them, problem solved. Has nothing to do with private. That is what's called 'type encapsulation'.

On Monday, 5 November 2018 at 09:03:59 UTC, Stanislav Blinov wrote:
> On Monday, 5 November 2018 at 05:55:02 UTC, unprotected-entity wrote:
>> On Saturday, 3 November 2018 at 21:28:22 UTC, Stanislav Blinov wrote:
>>>
>>> The only difference is that `func` became a member function. And now what? You can just as easily "forget" what's in your struct/class as in your whole module.
>>
>> ok. Now, what are your options then (assuming you want an independent type)?
>>
>> (option 1) define one encapsulated type, per module.
>> (option 2) have a means for type independence within a module - i.e. selective hiding.
>
> Option 3 - don't access private state unless you intend to. That's literally how you write implementations, in pretty much any language that has access modifiers.
>
>> D only gives you one choice here, not two.
>
> Nope. You can have a type spanning several modules. That's what packages do, among other things.
>
>> I would say, that your response backs up my argument, that is, a second option might actually be worthwhile. perhaps, something like: __private
>
> No, it really doesn't. Your argument was that the programmer might accidentally forget, and I've shown quite clearly that no keyword is going to protect them from that. If you can forget in module scope, you can forget in class scope. There can be only one solution: don't forget. As in: stop inventing imaginary examples. People, in practice, don't "accidentally" modify the guts of their own types. That horse is quite dead, I'm afraid.
>
>> (now __private is everything private already is, but additionally, its private outside the scope of the type declaring it, and now, you'd get a compile time guarantee of  correctness - e.g. if you accidently tried to ignore that types independence.
>
> No, you do not. You still have that same "problem" inside the type's definition.
>
>> It's call 'type encapsulation' ;-)
>
> If you're afraid of implicit conversions, define your own type that disallows them, problem solved. Has nothing to do with private. That is what's called 'type encapsulation'.

I'm glad you've worked only with excellent programmers, who in solitary write code in a module, knowing it to perfection, until the end of time.

And I'm also glad you did not have to debug inherited code, maybe before the packages existed, tens of thousands of lines, and to make sure you do not start you had to cut and sew classes and private structures, just to check that the intentions of the programmer, who perhaps was not as good as you are.

This your reiterate to every topic, thread, or question post on these forums with a "NO", is simply pathetic, as Manu has expounded a few weeks ago.

Get off your pedestal, and drop into the real life of those who program in D with colleagues not as perfect as you are.

On Monday, 5 November 2018 at 09:43:06 UTC, FooledDonor wrote:

>
> Get off your pedestal, and drop into the real life of those who program in D with colleagues not as perfect as you are.

So where are these teams of imperfect D programmers who are plagued by accidental modifications of private class members? Sociomantic? Funkwerk? Weka?

On Monday, 5 November 2018 at 11:07:11 UTC, Mike Parker wrote:
> On Monday, 5 November 2018 at 09:43:06 UTC, FooledDonor wrote:
>
>>
>> Get off your pedestal, and drop into the real life of those who program in D with colleagues not as perfect as you are.
>
> So where are these teams of imperfect D programmers who are plagued by accidental modifications of private class members? Sociomantic? Funkwerk? Weka?

You're right! How did I not think about it! I have to write on a public forum the name of the company and the name and surname of the colleagues I think are mediocre!

Plagued, guess it!

I deal with modules from well over 10k loc, I feel the lack of __private, during the study or debugging of certain monsters. You can believe it or not, it does not matter, it's your problem.

But frankly this attitude where EVERYTHING must be demonstrated when talking to you veterans of the forum, has reached ridiculous peaks. As someone wrote before me, you should seriously rethink your open mind.

I subscribed to this forum in the hope I'd get irregular updates on useful and interesting things related to the D language.

This thread as far as I see it had degenerated into a somewhat childish and unproductive waste of time, I wouldn't object to a moderator locking this thread

On 05.11.2018 15:19, Codifies wrote:
> I subscribed to this forum in the hope I'd get irregular updates on useful and interesting things related to the D language.
> 
> This thread as far as I see it had degenerated into a somewhat childish and unproductive waste of time, I wouldn't object to a moderator locking this thread
Unfortunately you're totally right and this is consequence of D popularity increasing. Before threads were much more professional and productive. Andrey decreased his participating in the forum due to this reason.

On 11/5/18 7:19 AM, Codifies wrote:
> I subscribed to this forum in the hope I'd get irregular updates on useful and interesting things related to the D language.
> 
> This thread as far as I see it had degenerated into a somewhat childish and unproductive waste of time, I wouldn't object to a moderator locking this thread

There is a troll here posting as multiple different aliases, who has tried this before, and continually comes back to harp on the same issue. It's why I haven't participated, he doesn't need to have more encouragement.

Just give it time, he will give up and go back to being a lurker. It would be good if people just stop responding here.

-Steve

On Mon, Nov 05, 2018 at 11:50:34AM -0500, Steven Schveighoffer via Digitalmars-d-announce wrote:
> On 11/5/18 7:19 AM, Codifies wrote:
> > I subscribed to this forum in the hope I'd get irregular updates on useful and interesting things related to the D language.
> > 
> > This thread as far as I see it had degenerated into a somewhat childish and unproductive waste of time, I wouldn't object to a moderator locking this thread
> 
> There is a troll here posting as multiple different aliases, who has tried this before, and continually comes back to harp on the same issue. It's why I haven't participated, he doesn't need to have more encouragement.
> 
> Just give it time, he will give up and go back to being a lurker. It would be good if people just stop responding here.
[...]

Yeah, after a while I realized that he was not sincere about contributing constructively, and I just stopped responding. It's simply not worth the time and effort, and it only generates more noise anyway. It's standard online forum advice, guys: don't feed the troll.


T

-- 
The most powerful one-line C program: #include "/dev/tty" -- IOCCC

On Monday, 5 November 2018 at 16:50:34 UTC, Steven Schveighoffer wrote:
>
> There is a troll here posting as multiple different aliases, who has tried this before, and continually comes back to harp on the same issue. It's why I haven't participated, he doesn't need to have more encouragement.
>
> Just give it time, he will give up and go back to being a lurker. It would be good if people just stop responding here.
>
> -Steve

it sounds like you're referring to me??

but which of my posts in this thread are trolling?

can you show me?

all most posts were resepectful, and were on the topic that I sought to discuss.

false accusations are NOT appreciated!

The problem is, I wanted to discuss the problems that are associated with public being the default, and private being 'kinda private'. It is the D TROLLS that ALWAYS come out to ruin that discussion by accusing me of wanting to change D.

That is self-evident - just go back and read this thread - if the truth matters to you.

I sought to have a decent, respectful discussion. Instead, I get D TROLLS coming out, who clearly hate OOP (and perhaps hate OO programmers), and start accusing me of wanting to turn D into an OOP language. No, I just wanted to discuss the potential benefits of increasing encapsulation within a module - that's it. Why is that so hard to do in the D forum? I don't get it.

Again, get your facts straight next time.

(of course, you'll likely never see this post, as there is a clear bias going on with the forum moderators too!)

On Wednesday, 31 October 2018 at 13:33:52 UTC, Stanislav Blinov wrote:
> On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki cattermole wrote:
>
>> But at the end of the day, it just depends on the scope of the module. Is it getting to large? If so, split.
>
> Yup. LOC aren't a particulalry informative metric. Documentation, comments, unit tests, blanks, all contribute to it. Split by scope, by concept, by responsibility, by any implementation-relevant metric, not by LOC. As the joke goes, your word processor is doomed to fail once it also starts sending out emails...

This is why the only measure is SLOC, not total lines, and one can measure SLOC easily with `dscanner --sloc` (for other languages I use sloccount). It probably counts unit tests though, which is unfortunate, but since my tests are always out-of-tree these days anyway...