Mike Parker wrote:

> Cars have color. These could all be considered object properties. Can you name an object that has the property of opCall?

Assume we have some colors

  enum COLOR{ LIGHTBLUE, DARKBLUE, RED};

and a car with some colorable parts

  class Car
  {
    Roofliner roof;
    Seat[4] seats;
    Carpet carpet;
    this()
    {
      roof= new Roofs.Handmade;
      seats[0]= new Seats.Handicapped(OVERWEIGHT);
      seats[1]= new Seats.Standard;
      seats[2]= new Seats.Auxiliar(LEFT, TINY);
      // ...

Now I want to assign colors to the colorable parts

  Car car;
  void main()
  {
    car= new Car;
    car.roof= COLOR.LIGHTBLUE;
    seats[0]= COLOR.DARKBLUE;
    seats[1]= COLOR.RED
    // ...

But you say that I am not allowed to do this, because the colorable parts are no properties of the car?

I have to write

  Car car;
  void main()
  {
    car= new Car;
    with(car)
    {
      roof.color= COLOR.LIGHTBLUE;
      seats[0].color= COLOR.DARKBLUE;
      seats[1].color= COLOR.RED
    // ...

instead? Thereby explicitely saying that I mean the color each time?

How does this fit with "auto c='c';" implicit type inference? Why do I have to write

  COLOR col= seats[0].color;

when it would suffice to write:

  COLOR col= seats[0];

because of appropriate opCalls?

Karen Lanrap wrote:
> I have to write
> 
>   Car car;
>   void main()
>   {
>     car= new Car;
>     with(car)
>     {
>       roof.color= COLOR.LIGHTBLUE;
>       seats[0].color= COLOR.DARKBLUE;
>       seats[1].color= COLOR.RED
>     // ...
> 
> instead? Thereby explicitely saying that I mean the color each time? 

D supports anonymous structs, unions and enums.

Karen Lanrap wrote:
<snip>
> Now I want to assign colors to the colorable parts
>     Car car;
>   void main()
>   {
>     car= new Car;
>     car.roof= COLOR.LIGHTBLUE;
>     seats[0]= COLOR.DARKBLUE;
>     seats[1]= COLOR.RED
>     // ...
> 
> But you say that I am not allowed to do this, because the colorable parts are no properties of the car?

Correct.  Such notation would mean setting the roof itself or the seats themselves, not their respective colours.  The colour is not the component; it is merely a property of each component.

> <snip>
>  Why do I have to write
> 
>   COLOR col= seats[0].color;
> 
> when it would suffice to write:
> 
>   COLOR col= seats[0];
> 
> because of appropriate opCalls?

Two reasons.  Firstly, it wouldn't make sense - seats[0] is already a seat, it cannot be a colour at the same time.  Secondly, there's nothing appropriate about using opCall for something like this, even if it did work.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS-
PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on
the 'group where everyone may benefit.

Your example demonstrates very well why overriding assignments shouldn't be allowed.

# Car mycar;
# mycar = COLOR.RED; //!!!!!!!

How can a car turn to a red color? This is totally meaningless and bogus.

Color is a property of the car:
# mycar.color = COLOR.RED;

roof is a property of the car, but this doesn't justify using
# mycar.roof = COLOR.RED;
because you're not changing the property roof (well, you're changing its state) but rather, you're changing the "color" of the roof; so you're changing a property of roof, thus:
# mycar.roof.color = COLOR.RED;

What you're trying to do makes code totally unreadable.

Karen Lanrap wrote:
> Mike Parker wrote:
> 
>> Cars have color. These could all be considered object
>> properties. Can you name an object that has the property of
>> opCall?
> 
> Assume we have some colors
> 
>   enum COLOR{ LIGHTBLUE, DARKBLUE, RED};
> 
> and a car with some colorable parts
> 
>   class Car
>   {
>     Roofliner roof;
>     Seat[4] seats;
>     Carpet carpet;
>     this()
>     {
>       roof= new Roofs.Handmade;
>       seats[0]= new Seats.Handicapped(OVERWEIGHT);
>       seats[1]= new Seats.Standard;
>       seats[2]= new Seats.Auxiliar(LEFT, TINY);
>       // ...
> 
> Now I want to assign colors to the colorable parts
>     Car car;
>   void main()
>   {
>     car= new Car;
>     car.roof= COLOR.LIGHTBLUE;
>     seats[0]= COLOR.DARKBLUE;
>     seats[1]= COLOR.RED
>     // ...
> 
> But you say that I am not allowed to do this, because the colorable parts are no properties of the car?
> 
> I have to write
> 
>   Car car;
>   void main()
>   {
>     car= new Car;
>     with(car)
>     {
>       roof.color= COLOR.LIGHTBLUE;
>       seats[0].color= COLOR.DARKBLUE;
>       seats[1].color= COLOR.RED
>     // ...
> 
> instead? Thereby explicitely saying that I mean the color each time? 
> 
> How does this fit with "auto c='c';" implicit type inference? Why do I have to write
> 
>   COLOR col= seats[0].color;
> 
> when it would suffice to write:
> 
>   COLOR col= seats[0];
> 
> because of appropriate opCalls?
> 
>   

On Mon, 25 Sep 2006 16:49:16 -0600, Hasan Aljudy wrote:

> Your example demonstrates very well why overriding assignments shouldn't be allowed.
> 
> # Car mycar;
> # mycar = COLOR.RED; //!!!!!!!
> 
> How can a car turn to a red color? This is totally meaningless and bogus.
> 
> Color is a property of the car:
> # mycar.color = COLOR.RED;
> 
> roof is a property of the car, but this doesn't justify using
> # mycar.roof = COLOR.RED;
> because you're not changing the property roof (well, you're changing its
> state) but rather, you're changing the "color" of the roof; so you're
> changing a property of roof, thus:
> # mycar.roof.color = COLOR.RED;
> 
> What you're trying to do makes code totally unreadable.

Not to mention it doesn't address the situation when sub-objects have multiple properties...

  mycar.roof.color = COLOR.RED;
  mycar.roof.type  = SOFT_TOP;

you can't do that sort of thing by simply overloading opCall().

  mycar.roof = COLOR.RED;
  mycar.roof = SOFT_TOP;

Nah ... doesn't make much sense.


-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
26/09/2006 10:08:30 AM

Derek Parnell wrote:
>   mycar.roof = COLOR.RED;
>   mycar.roof = SOFT_TOP;
> 
> Nah ... doesn't make much sense.

Your argument holds for this code too:

import std.stdio;
enum COLOR{RED};
enum TYPE{SOFT_TOP};
class Car{
    void roof( COLOR c)
    {
    }
    void roof(TYPE t)
    {
    }
}
void main(){
    auto mycar= new Car;
    mycar.roof= COLOR.RED;
    mycar.roof= TYPE.SOFT_TOP;
}

Now please explain, why this is nearly senseless.

Hasan Aljudy wrote:

> What you're trying to do makes code totally unreadable.

It is already possible to write that way---with some inconsistencies.

If your argument of inreadability holds at all it also holds for overloading functions---but overloading functions is an accepted technic.

On Tue, 26 Sep 2006 11:45:30 +0300, Karen Lanrap <karen@digitaldaemon.com> wrote:

> Derek Parnell wrote:
>>   mycar.roof = COLOR.RED;
>>   mycar.roof = SOFT_TOP;
>>
>> Nah ... doesn't make much sense.
>
> Your argument holds for this code too:
>
> import std.stdio;
> enum COLOR{RED};
> enum TYPE{SOFT_TOP};
> class Car{
>     void roof( COLOR c)
>     {
>     }
>     void roof(TYPE t)
>     {
>     }
> }
> void main(){
>     auto mycar= new Car;
>     mycar.roof= COLOR.RED;
>     mycar.roof= TYPE.SOFT_TOP;
> }
>
> Now please explain, why this is nearly senseless.


I think the assignment operator causes 'trouble' here. You're trying to saying that 'roof' is red and soft top, but you're really saying (in terms of D) that red is assigned to 'roof' and then soft top. Maybe a new operator would clear things up:

    mycar.roof IS COLOR.RED;
    mycar.roof IS TYPE.SOFT_TOP;

(Note that lower cased 'is' is a reserved word in D.)

As long as there are no multiple properties using the same type, that will be unambiguous.


A shortcut for this could be:

    mycar.roof IS COLOR.RED, TYPE.SOFT_TOP;

or:

    mycar.roof IS COLOR.RED AND TYPE.SOFT_TOP;

Then you could write sentences like:

    mycar.roof IS COLOR.RED, STYLE.EXOTIC, AND TYPE.SOFT_TOP;

(Hmm, would this break the 'style of D' too much...?)

Karen Lanrap wrote:
> Hasan Aljudy wrote:
> 
>> What you're trying to do makes code totally unreadable.
> 
> It is already possible to write that way---with some inconsistencies.
> 
> If your argument of inreadability holds at all it also holds for overloading functions---but overloading functions is an accepted technic.

There is nothing inherently unreadable about overloading functions, nor is there anything inherently unreadable about property syntax. The problem is in how you are using these features. Consider this:

class MyClass
{
   void print(Object o) { writef(o); }
   void print(int i) { writef(i); }
   ...
}

There is no confusion about the following code:

Object o = new Object();
myClass.print(o);
myClass.print(10);

The method is overloaded, but perfectly readable. You can clearly see by the name that the method prints the argument passed, regardless of type. But that's not going to stop someone from implementing it this way:

class MyClass
{
   void print(Object o) { delete o; }
   void print(int i) { writef(i + 10); }
}

It's not the overloading that makes the code unreadable, but the implementation. How many users of MyClass will run into bugs because myClass.print(myObj) is deleting their object and not printing it? Or when every integer they output is 10 higher than it should be? The code is not doing what it appears to be, so it is unreadable.

What you are doing with properties is the same thing:

void main()
  {
    car= new Car;
    car.roof= COLOR.LIGHTBLUE;
    seats[0]= COLOR.DARKBLUE;
    seats[1]= COLOR.RED
    // ...

A Roof is *not* a Color. A Seat is *not* a Color. You are abusing the property syntax. The compiler cannot prevent you from such silliness. It is the responsibility of the programmer to follow accepted practice and to make the code clear and understandable.

The operator overload opAdd should perform an addition and not a multiplication, but nothing stops you from implementing a multiplication. If you were to do that, myClass + myClass suddenly takes on a meaning other than what is expected and the code becomes unreadable. The same thing is happening with your Car example. The following is how it *should* look:

car.roof.color = COLOR.LIGHTBLUE;
seats[0].color = COLOR.DARKBLUE;

Now the code is clear. Seats have the property of color, and Roofs have the property of color, so assigning a color to those properties makes sense. But assigning a color to a roof directly does not.

Just because you *can* do something doesn't mean you *should*. The syntax of the language can help you write readable code, but the compiler isn't a sentient being. It's up to you to stay within the bounds of intended use, name your methods clearly and meaningfully, and to make your code as readable as possible.

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

Have you ever thaught about the consequences of the "with"-statement?

In the sense of "with" would it any more readable to code:

prepend( COLOR) append( color){
  roof     = LIGHTBLUE;
  seats[0] = DARKBLUE;
  // ...

instead of:

  roof.color     = COLOR.LIGHTBLUE;
  seats[0].color = COLOR.DARKBLUE;
  // ...