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)){ ... }




Reply via email to