Does D have too many features?

Timon Gehr timon.gehr at gmx.ch
Mon Apr 30 12:04:15 PDT 2012


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






More information about the Digitalmars-d mailing list