Why are opCall's not implicitely assignable?

[Mike Parker]

Karen Lanrap wrote:
> Ivan Senji wrote:
> 
> I already noticed that this NG is filled with posters refusing to 
> understand simple principles---but willing to press others into 
> principles they believe to be simple.
> 
> 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.
> 

Properties are a well-understood concept across several languages, it is 
you that are failing to understand them. If, indeed, you do want to use 
a class as a property nothing is stopping you from doing that. But ask 
yourself this, if the class were freestanding and *not* a property, 
would it make sense to assign another type to it?

class Roof { ... }
Roof myRoof = new Roof();
myRoof = Color.Blue;

In D, this will fail to compile, and for good reason. A roof is not a 
color, so assigning a color to a roof variable makes absolutely no sense 
whatsoever. The same concept holds true if a Roof object is a property 
of the car. The roof has properties itself. If you can't be bothered to 
type car.roof.color, that is not a failure of the language but a 
personal issue.

Dynamically typed languages like Python and Lua allow you to assign 
different types to the same variable, but D is not dynamically typed.

> 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"?

Properties are not unique to D. There's no reason to include anything 
about such a feature the style guide. It's a simple concept that many, 
many, programmers already comprehend.


> 
> 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.

Then perhaps you need to clue in that the way you are thinking about 
properties in statically typed languages is *wrong*. Just because you 
think something should be done a certain way doesn't mean that it is the 
commonly accepted way, nor does it mean it should be supported by the 
language. I don't know of any language that lets diverse people with 
different thought processes to code in their own unique style in such a 
way that the meaning is clear to all who read their code (though Perl 
surely tries).

> 
> That's mental inconsistency at its best.
> 
> 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.

Name one language that does? How is it even possible for the compiler to 
accept alternative spellings for the same variable? Some people use the 
preprocessor in C or C++ to fake it, but it isn't supported directly by 
either language.

> 
>> What point?
> 
> Ever heard of the module scope operator---or the D-style to 
> separate an operator by one space from its operands?

You can't delete operators in any language and expect the code to work 
as is. C,C++,Java,C# all have the . operator. C and C++ also have the -> 
operator. Try deleting those and see if your code compiles.

As for spacing, that *is* a personal choice. That gets back to 
readability in the text file (syntax). All C-based languages allow you 
to write a+b or a + b. You aren't required to follow any one particular 
style guide at all -- just recommended to.

No one is forcing you to follow commonly accepted standards, or even to 
use common sense. If you want to continue to say car.roof = Color.Blue, 
then go right ahead. But later on, when people are confused by your 
code, you will have only yourself to blame. If you never release any 
code to the world at large or never work on a team, then it really 
doesn't matter what you do.