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