Karen Lanrap wrote:
> Mike Parker wrote:
> 
>> make your code as readable as possible.
> 
> Without any measure of readability this requirement is as useful as the word user-friendly.

There are measures of readability, but I doubt there is such a measure everyone would agree on.

> In the sense of "with" would it any more readable to code:
> 
> prepend( COLOR) append( color){
>   roof     = LIGHTBLUE;
>   seats[0] = DARKBLUE;
>   // ...
> 

No it wouldn't be any more readable because it still wouldn't make *any* sense. Roof *is*not* LIGHTBLUE, it's color is LIGHTBLUE, seats[0] is *not* DARKBLUE, it is a Seat and it's color is DARKBLUE.


> instead of:
> 
>   roof.color     = COLOR.LIGHTBLUE;
>   seats[0].color = COLOR.DARKBLUE;
>   // ...

I read through this thread and still don't get it why you think that there is something wrong with this.

Karen Lanrap wrote:
> Mike Parker wrote:
> 
>> make your code as readable as possible.
> 
> Without any measure of readability this requirement is as useful as the word user-friendly.
> 

Readability is subjective, so there cannot be a proper measure of readability. So this point in discussion (whether your overload syntax should be used) is mostly a subjective point.
I too am of the opinion that such usage is not very elegant and that the more verbose form:
  car.roof.color = COLOR.LIGHTBLUE;
is preferable.


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Karen Lanrap wrote:
> Mike Parker wrote:
> 
>> make your code as readable as possible.
> 
> Without any measure of readability this requirement is as useful as the word user-friendly.
>
> COBOL is known as a language where everything is extremely readable.
>
> C and some other languages are known to be more readable than D
> because they distinguish between pointers ( ^, -> ) and fields ( . ).
>
> A dialect of BASIC declares itself to be more readable by allowing
> the point to be part of identifiers ( "a.b.c" is one legal
> identifier).
>
> Txl replaces "f(g(h(p)))" by "p[h][g][f]".
>
> Must I mention APL? ( to me its close to brainf***)

Sorry, our wires are crossed. "readability" in the sense of brace location and other syntactic issues isn't what I'm getting at. I'm talking more about self-documenting code:

void a();
void b();
void c();

What do the above methods do? Unless you see the implementation, you have no idea. Function names that are named clearly and are indicative of what they do in a given context should be plenty clear to anyone reading them. You can't divine the details without looking at the implementation, but all you need to know is that a method named 'print' will take its input and format to an output location somewhere. opAdd in the D world clearly is not the overload for the * operator. This is the readability I'm talking about.

Abusing the property syntax by trying to assign colors to 'roof' and 'seat' properties, which clearly aren't colors, is unreadable in the sense that it makes the 'roof' and 'seat' properties appear to be Color objects. Someone reading the code cannot see what is going on without looking at the implementation details of the Car class.

Whether or not they go cross-eyed from Lisp braces is another issue.

Mike Parker wrote:

> Abusing the property syntax by trying to assign colors to 'roof' and 'seat' properties, which clearly aren't colors, is unreadable in the sense that it makes the 'roof' and 'seat' properties appear to be Color objects.

Syntactical elements cannot be abused. Only coders feel abused when their semantic associations to syntactic elements are disturbed.

All you are saying is, that you are unable to spontanuously change the views on your objects.

Why is it helping your mental style of reading code if you are forced to change that view with constructs like "with"---or has anybody complains about the "with"-statement.

And if so, why don't you accept an "append"-statement?

Ivan Senji wrote:

> I read through this thread and still don't get it why you think that there is something wrong with this.

I _feel_ an inconsistency. If I would know that there is something wrong I would post in the main group.

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

... or would you appreciate a mechanism that prevents you from doing so?

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)

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

On Wed, 27 Sep 2006 07:56:48 +1000, Derek Parnell wrote:


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

Oops, I forgot to mention that making it easier to write is also a good thing so a syntax like ...

  with car.roof
  {
     .topcoat = COLOR.RED;
     .undercoat = COLOR.WHITE;
  }

is nice too.

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

Derek Parnell wrote:

>   with car.roof
>   {
>      .topcoat = COLOR.RED;
>      .undercoat = COLOR.WHITE;
>   }
> 
> is nice too.

Until someone says: topcoat is _not_ a color. It is concrete material that surely must have a property called color, but it is not a color itself: this code is totally unreadable for me.

(By the way: forgetting to delete a point can have desastrous results in D.)