Why are opCall's not implicitely assignable?

[Lutger]

Karen Lanrap wrote:
<snip>
> This whole thread showed, that near to none is able to capture that 
> a property might have a complex structure. So complex that it might 
> be best expressed by the most complex structure of D: a class.

I beg to differ. The point, imo, is not that properties might or might 
not have a complex structure, but should have a simple structure from 
the users point of view: you know what it does when you see it used, 
like the - often abused - get/set idiom.

> I asked a question about the principles of the language D---and got 
> some answers led by personal opinions about coding style. How comes 
> that no answerer was able to convince Walter that his particular 
> style is suitable for an entry in the "Style Guide"?
> 
> 
>> It is all up to you:
> 
> No, it is not. D prohibits me to code the way I think. And the 
> posters in this thread want not only themselves beeing forced to 
> read the name of the same property over and over again, they also 
> force others to code superfluous words---and at the same time they 
> admire that they can replace a pair of parentheses by an equal 
> sign.
>
> That's mental inconsistency at its best.

I don't think so. The point is writing code that is understandable, by 
you and by others. The last one might be even more important, see below. 
Reading the name of the same property over and over is a lesser evil 
than it not being clear what is used with what: A = B.A is better than A 
= B where both mean A = A. Syntax should help understand symantics, 
which is why A = B.A is good syntactic sugar for A = B.A() but A = B is 
not. This is not 'just' style.

> Nobody even cared about the fact, that D is also intended for large 
> scale projects which might include british and american style 
> pronounciations, forcing every maintainer to exactly know whether 
> to write color or colour.

Understanding code is about conventions, thus it is more intersubjective 
than subjective. Maybe some way of expressing a problem is more 
understandable to you or me, but if it goes against the established 
conventions it is prudent to adapt to a different concept. If a team of 
programmers need programming constructs to hide their disagreement of 
spelling, I'd say they have more serious problems to deal with.


"Programming is for programmers, not computers." - Bartosz Milewski