On 04/30/2012 07:05 PM, H. S. Teoh wrote:
On Mon, Apr 30, 2012 at 06:54:31PM +0200, bearophile wrote:
H. S. Teoh:
Which means your code is at the mercy of the external library.
Upstream updates a class, and suddenly a whole bunch of code is
unnecessarily broken
How? (I think you are wrong again).
[...]
struct S {
int x;
}
void main() {
int y;
S s;
with(s) {
x = 1;
y = 2;
}
}
This works. Now suppose S is updated to:
struct S {
int x;
int y;
}
Now the program fails to compile because S.y conflicts with the local y.
This is bad because unrelated code
It is not unrelated.
is broken just by changing S: it breaks encapsulation.
No it does not. Changing an interface is bound to break code.
This is just a small example; imagine if a lot of
code uses S. Many places may break when S changes just because they
happen to use the wrong local variable names.
That is an extremely constructed argument. I cannot imagine that this
will ever be a problem in practice.
Whereas if you had _not_ used with, this is a non-problem, since you'd
be referring to s.x, and the fact that S now has a new member does not
break any existing code regardless of how it was named.
int* x = cast(int*)&s;
int y = *x;
S t = *cast(S*)&y;
static if(!is(typeof(S.y)){ ... }