Re: Driving Continuous Improvement in D
On Saturday, 2 June 2018 at 13:32:00 UTC, Basile B. wrote: Microbe, if you were a keyword for a protection attribute in a programming language, i would choose "smuck". To borrow a quote from someone else on this forum.. knock of the sex talk!. Anyway, increased membrane permeability leads to rupture, followed by death. Why should I exposed my objects to the toxic effects of the D module? And if encapsulation is not a 'quality' issue, then I don't know what is. In biology, encapsulation is the basis for life - it's why you and I exist. So my question is valid (even if you don't like it). Since the compiler won't protect my objects from the toxic effects of the D module, I am curious how dscanner can help.
Re: Driving Continuous Improvement in D
On Saturday, 2 June 2018 at 07:23:42 UTC, Mike Parker wrote: In this post for the D Blog, Jack Stouffer details how dscanner is used in the Phobos development process to help improve code quality and fight entropy. The blog: https://dlang.org/blog/2018/06/02/driving-continuous-improvement-in-d/ reddit: https://www.reddit.com/r/programming/comments/8nyzmk/driving_continuous_improvement_in_d/ As you know, surrounding code within a module can infilitrate the membrane structure of those types that use 'private' to protect their boundary (for example, the 'private' member in that struct, in that blog). Since the compiler is completely useless in such situations (as it conspires with the surrounding code 'to ensure that it can infiltrate your types'), what does dscanner bring to the table, if anything, to help the programmer to ensure such types don't die a quick death due to the cytotoxic effect the module has on such types? Or is this not considered a 'quality' issue in D?
