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.
