'with' bug?

Faux Amis faux at amis.com
Mon Nov 5 00:37:50 PST 2012


On 05/11/2012 01:45, Chris Cain wrote:
> On Sunday, 4 November 2012 at 23:51:15 UTC, Faux Amis wrote:
>> In your last paragraph you are getting to my point in my other post:
>> I think there is nothing wrong with a module scope private var as in D
>> a module is the first encapsulation and adding a wrapper only adds noise.
>>
>> These are equivalent(from a good-coding pov):
>> ---
>> module a;
>>
>> private int i;
>> ---
>> module b;
>>
>> // annoying wrapper
>> //which makes it difficult to have a single b in the program
>> struct S{
>>  int i;
>> }
>> ---
>>
>> These are also equivalent:
>> ---
>> module a;
>>
>> int i;
>> ---
>> module b;
>>
>> struct S{
>>  static int i;
>> }
>> ---
>
> Like I said, I don't think it's something that should be banned
> outright, but I've seen many examples of code where someone didn't take
> the time to be explicit about the dependencies in their code and instead
> chose to "hide" it like you propose is appropriate. Trust me, as the
> person who has to maintain and extend their code, **I don't appreciate
> their laziness**.
>
> If you can, you should avoid such things. Module-scoped variables
> mitigate the problems, but they don't eliminate them.
>
> Also, bearophile's suggestion to try to make everything "pure" is a good
> idea. I write as much code as I can using immutable and pure and only
> relax those restrictions when the cost is far too great to maintain
> that. When I come back to the code later, I find it significantly easier
> to figure out for many of the reasons I outlined in my previous post.
>
> ---
> void bar(ref int b) {
>      //code using b
> }
> ---
>
> Is generally better than
>
> ---
> int b;
> void bar() {
>      // code using b
> }
> ---
>
> Even if b is only private module scoped. I've outlined the reasons why
> in my previous post.
>
> On Sunday, 4 November 2012 at 23:58:08 UTC, bearophile wrote:
>> Generally it's better to minimize the scope of variables.
>
> Quoted for truth.
>
> Heck, I've seen examples of code where instance variables were too
> liberally applied, like so:
>
> ---
> struct S {
>     int b;
>     void bar() {
>        // b is initialized and used in this scope, but no where else
>     }
>
>     // more code where b isn't used
> }
> ---
>
> is worse than:
>
> ---
> struct S {
>     void bar() {
>         int b = ...;
>         // use b
>     }
>
>     // more code
> }
> ---
>
> Now, maybe b used to be used elsewhere, (I can't say for sure...) but
> sometimes I wonder why people are so willing to let things like that
> leak out of the scope where it's used... it makes the next person's job
> much harder for no reason.

Ok, good to see that you are replying to incorrectly scoped variables, 
but this is not the point I am trying to make. I know you should always 
keep the scope as small as possible.

Can you think of a setting in which we have legitimate private struct 
members? If so, then add to this setting that you only want one 
instantiation of the data in this struct. As a solution, what is wrong 
with dropping the struct encapsulation? There is no other code except 
the struct in the module.

I sincerely want to know if there is any difference. As I understand it 
the scope is exactly the same or even smaller as you can't leak 
instances of modules as you can structs.




More information about the Digitalmars-d mailing list