Why are opCall's not implicitely assignable?

[Ivan Senji]

Karen Lanrap wrote:
> Bruno Medeiros wrote:
> 
>> the more verbose form:
>>    car.roof.color = COLOR.LIGHTBLUE;
>> is preferable.
> 
> Maybe, that from these few lines of code you are getting that 
> impression. But what if you are a member of a team that codes colors. 
> Would you be pleased to know, that every third word you code is the 
> word "color"?

What if roof and seat have other properties like name, id, manufacture year:

car.roof = LIGHTBLUE;
car.roof = 101; 	//this is an ID
car.roof = 1998;	//year

Call me crazy but that makes no sense.
The meaning of terms like: classes, objects, properties, fields are well 
defined throughout languages like D, Java, C#, C++ ...

But your example doesn't make sense in any of those languages. The point 
is that roof and seat should be objects having subproperties and not 
just methods emulating properties (not a very good emulation).

And to answer the question: no, I wouldn't mind typing color all over 
the place, but there are workarounds if this bothers someone (define 
unnamed enum, alias favorite colors...)

The problem isn't typing COLOR.something alot, the problem is assigning 
color to things that aren't colors. (Repeating myself but: roof !is 
color, and roof.color is color)