On 01/11/2018 2:42 AM, Stanislav Blinov wrote:
> Well, yes, it can be a litmus test, I guess. I meant to say that it isn't per se a deciding factor.

It is a deciding factor for me. Because it seems to be almost always correct. As I said, my rules are stricter than what most people have.

My preferences may or may not be applicable for others tho.

On 10/31/2018 3:48 AM, Sebastien Alaiwan wrote:
> I think there might be some confusion between "leaky abstraction" and "insufficient encapsulation".

Thanks for the excellent description of the difference.

On 10/31/2018 6:25 AM, 12345swordy wrote:
> Again what consist of a module of being "too large"?
> That seems to me that more of a art then a science.

If you're looking for a rigid rule, you won't find one.

But a good indicator is if it contains more than one abstraction that has nothing particular in common with each other.

On Wednesday, 31 October 2018 at 13:39:25 UTC, rikki cattermole wrote:
> On 01/11/2018 2:35 AM, 12345swordy wrote:
>> On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki cattermole wrote:
>>> On 01/11/2018 2:25 AM, 12345swordy wrote:
>>>> [...]
>>>
>>> Because it is.
>>>
>>> My rules (which tend to be a little stricter than most peoples) are:
>>>
>>> Soft split 1k LOC, hard split 3k LOC without a very good reason not to.
>>>
>>> But at the end of the day, it just depends on the scope of the module. Is it getting to large? If so, split.
>> Ok, you agree that it is subjective. Why is having more then one class per file "too large"?
>
> It doesn't. It is a group of related symbols. If it doesn't have function bodies (e.g. extern(C++) or COM) I would call that module to have too small of a scope.
Why do anyone have to create a file for every class if they wanted them to be encapsulated then? Why can't we put them in the same file if they are relativity small?

On Wednesday, 31 October 2018 at 13:24:10 UTC, Adam D. Ruppe wrote:
> On Wednesday, 31 October 2018 at 13:16:45 UTC, 12345swordy wrote:
>> I seen modules with more then thousand lines of code in the Phobos library.
>
> $ wc simpledisplay.d nanovega.d dom.d cgi.d
>   14152   54984  443111 simpledisplay.d
>   15289   63707  573986 nanovega.d
>    7159   24473  187572 dom.d
>    4132   16727  128299 cgi.d

This is an counter argument how?

On Wednesday, 31 October 2018 at 20:24:36 UTC, 12345swordy wrote:
> This is an counter argument how?

It isn't a counter argument (at least not to you).

Just saying that I wrote a 14,000 line module, and maintain a contributed 15,000 line one. It works for me! lol

On Wednesday, 31 October 2018 at 20:23:21 UTC, Walter Bright wrote:
> On 10/31/2018 6:25 AM, 12345swordy wrote:
>> Again what consist of a module of being "too large"?
>> That seems to me that more of a art then a science.
>
> If you're looking for a rigid rule, you won't find one.
>
> But a good indicator is if it contains more than one abstraction that has nothing particular in common with each other.

Sure thing, however I wonder why "protected package" doesn't exist for classes, seems to me a missing opportunity there.

On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki cattermole wrote:
> On 01/11/2018 2:25 AM, 12345swordy wrote:
>> On Wednesday, 31 October 2018 at 13:22:28 UTC, rikki cattermole wrote:
>>> On 01/11/2018 2:16 AM, 12345swordy wrote:
>>>> On Wednesday, 31 October 2018 at 05:42:26 UTC, Nicholas Wilson wrote:
>>>>> Running into such problems is a sign that your module is too large, and should become a package.
>>>> I seen modules with more then thousand lines of code in the Phobos library. What exactly consist a module of being "too large"? If having two classes in a module with around 200-300 lines of code "too large"?
>>>
>>> We have been splitting Phobos modules up:
>>>
>>> std.algorithm and most recently std.datetime
>>>
>>> They were MASSIVE as in 30k+ LOC massive.
>> 
>> That's nice.
>> Again what consist of a module of being "too large"?
>> That seems to me that more of a art then a science.
>
> Because it is.
>
> My rules (which tend to be a little stricter than most peoples) are:
>
> Soft split 1k LOC, hard split 3k LOC without a very good reason not to.
>
> But at the end of the day, it just depends on the scope of the module. Is it getting to large? If so, split.

I really do disagree.

It's is not at all, about LOC.

It is about clean architecture.

D module's do not promote clean architecture. Why? Because private state is exposed to all code within a module. What will happen to clean architecture, when you make that available to programmers? Well.. we get phobos like architecture.

Another thing to look for, is signs of code smell. I would include in this, unit tests calling private methods (which seems to be a popular thing for D programmers to do). Some will disagree that this is a code smell, but I have yet to see a good argument for why it is not.

Forget LOC. Look for good architecture, decoupling, modularity, encapsulation, information hiding....etc..etc... again, sadly, these concepts are not directly promoted when writing modules in D, since the module exposes everything to everything else in the module - and programmers will surely make use of any convenient hack that avoids them having to think about good architecture ;-)

On Thu, Nov 01, 2018 at 02:45:19AM +0000, unprotected-entity via Digitalmars-d-announce wrote: [...]
> Another thing to look for, is signs of code smell. I would include in this, unit tests calling private methods (which seems to be a popular thing for D programmers to do). Some will disagree that this is a code smell, but I have yet to see a good argument for why it is not.

White-box testing.

In principle, I agree with you that if your unittests are doing black-box testing, then they should definitely not be calling private methods.

However, limiting yourself to black-box testing means your private functions can be arbitrarily complex and yet it's not thoroughly tested. Sometimes you really do want a unittest to ensure the private method is doing what you think it's doing, and this requires white-box testing. This is especially important to prevent regressions, even if it seems redundant at first.  Only doing black-box testing means a later code change in the private method can subtly introduce a bug that's not caught by the unittest (because it cannot call a private method directly to verify this).


> Forget LOC. Look for good architecture, decoupling, modularity, encapsulation, information hiding....etc..etc... again, sadly, these concepts are not directly promoted when writing modules in D, since the module exposes everything to everything else in the module - and programmers will surely make use of any convenient hack that avoids them having to think about good architecture ;-)
[...]

Actually, code within a module *should* be tightly coupled and cohesive -- that's the whole reason to put that code inside a single module in the first place.  If two pieces of code inside a module are only weakly coupled or completely decoupled, that's a sign that they should not be in the same module at all.  Or at the very least, they should belong in separate submodules that are isolated from each other.

But besides all this, D's philosophy is about mechanism rather than policy.  The goal is to give the programmer the tools to do what he needs to do, rather than a bunch of red tape to dictate what he cannot do.  That's why we have @trusted, @system, and even asm.  The programmer is responsible for making sane architectural decisions with the tools he is given, rather than being told what (not) to do within the confines of his cell.  If you're looking for policy, maybe Java would suit you better. :-P


T

-- 
Nobody is perfect.  I am Nobody. -- pepoluan, GKC forum

On Thursday, 1 November 2018 at 03:10:22 UTC, H. S. Teoh wrote:
>
> Actually, code within a module *should* be tightly coupled and cohesive -- that's the whole reason to put that code inside a single module in the first place.  If two pieces of code inside a module are only weakly coupled or completely decoupled, that's a sign that they should not be in the same module at all.  Or at the very least, they should belong in separate submodules that are isolated from each other.

How does one determine, whether a 10,000 line module, is tightly coupled and cohesive?

Only the author can make that statement - which they naturally will, even if it's not true.

An outsider, seeking to verify that statement, has a hell of a job on their hands...(I for one, think code smell immediately).

As soon as you see a class interface in a module, in D, you have to assume their is other code in the module, perhaps down around line 9,900, that is bypassing its interface, and doing who knows what to it....

Sure, the author might be happy, but an auditor/code reviewer, will likely have a different view, when a 10,000 line module is shoved in front of them, and they know, that 'anything goes', 'all bets are off', inside the D module....

> But besides all this, D's philosophy is about mechanism rather than policy.  The goal is to give the programmer the tools to do what he needs to do, rather than a bunch of red tape to dictate what he cannot do.  That's why we have @trusted, @system, and even asm.  The programmer is responsible for making sane architectural decisions with the tools he is given, rather than being told what (not) to do within the confines of his cell.  If you're looking for policy, maybe Java would suit you better. :-P

I don't use a particular language. I'm more interested in design and architecture.

In the age of 'lock-down-everything', increased modularity is becoming more important. A monolithic module approach, is already outdated, and risky, in terms of developing secure, maintainable software....

I think providing an additional tool, to those who seek to use D, such as 'strict private' (syntax can be argued about), would aid better design - it can't make it any worse, that's for sure).

Although. I don't mean strict private like freepascal, but strict private, as in it inherits everything that private already does, but additionally, become private within the module too.

Is that really such a bad idea? Are there no programmers out there in the D world that might think this could be a good, additional tool, to give programmers, so they can better architect their solution?

The amount of push back in the D community on this idea, is really odd to me. I'm still trying to understand why that is. Are D programmers just hackers, insterested in getting their code to work, no matter what? Are their not enough Java/C# programmers coming to D - and bringing their design skills with them?