Why are opCall's not implicitely assignable?

Kristian kjkilpi at gmail.com
Tue Sep 26 02:29:03 PDT 2006


On Tue, 26 Sep 2006 11:45:30 +0300, Karen Lanrap <karen at 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...?)



More information about the Digitalmars-d-learn mailing list