Why are opCall's not implicitely assignable?

[Derek Parnell]

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