Why are opCall's not implicitely assignable?

Derek Parnell derek at psyc.ward
Tue Sep 26 14:56:48 PDT 2006


On Tue, 26 Sep 2006 23:13:13 +0200, Ivan Senji wrote:

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

Ivan is very 'on the mark' here. 

This is just a simple example but it demonstrates the concept that using
overloading in this manner is not helpful to people who *read* programs.
Ok, the compiler might be able to sort things out but it doesn't make it
easy for humans to do that.

Further more, what might this below mean ... 


  car.roof = COLOR.RED;
  car.roof = COLOR.WHITE;

No it doesn't. Using fancy compiler 'tricks' I meant this (more readible
version) ...

 car.roof.topcoat   = COLOR.RED;
 car.roof.undercoat = COLOR.WHITE;

Explicitly documenting the subproperties is a guide to help people read the
code. Remember, programming languages are really for people to read.
Computers do better with machine language.

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"



More information about the Digitalmars-d-learn mailing list