Why are opCall's not implicitely assignable?

[Mike Parker]

Ary Manzana wrote:
> Mike Parker wrote:
>> Karen Lanrap wrote:
>>
>>> Why has this to be restricted to properties?
>>> What are properties at all?
>>> Why is a member of a class that is a class with an opCall no property 
>>> of that class?
>>
>> Conceptually, properties do not belong to a class (in the programming 
>> sense of 'class') but to a class of objects (in the object oriented 
>> design sense of 'class'). People have height and weight. Cars have 
>> color. These could all be considered object properties. Can you name 
>> an object that has the property of opCall?
>>
>> At the programming level, it is convenient to directly manipulate 
>> properties, rather than working with functions which may have 
>> cumbersome or inappropriate names. But making properties public and 
>> directly accessible is error prone. So a compromise is to manipulate 
>> the properties through methods, but hide the method calls behind 
>> assignment syntax (foo.prop = 1, i = foo.prop). Some languages provide 
>> no support for this at all (C++), some have standard naming 
>> conventions for methods but no direct support (Java), and some provide 
>> direct support (C#).
>>
>> I think C# got it right, in that property syntax explicitly declares a 
>> class member as a property and only members declared as such can be 
>> manipulated as properties. D's support for properties is rather weak, 
>> IMO, in that it isn't explicit. It doesn't enforce property syntax on 
>> property manipulators only. It can also, as in this case, lead to 
>> confusion.
>>
>> Just consider that not every class method should be used with property 
>> syntax, but only those intended to manipulate properties. Property 
>> manipulators should have the name of the property you want to 
>> manipulate (it need not be the same name as the actual member 
>> variable) and should do what they need to do to set and get a property 
>> - nothing more.
>>
>> class Foo
>> {
>>    private int _bar;
>>
>>    public void bar(int newBar)
>>    {
>>       _bar = newBar;
>>    }
>>
>>    public int bar()
>>    {
>>       return _bar;
>>    }
>> }
> 
> The typical example to give a counterexample for this it the class Circle:
> 
> class Circle
> {
>     private double _radius;
> 
>     public void radius(double r) {
>          _radius = r;
>     }
> 
>     public double radius() {
>         return _radius;
>     }
> 
>     public void area(double a) {
>          _radius = sqrt(a/PI);
>     }
> 
>     public double area() {
>          return PI * _radius * _radius;
>     }
> 
>     public void perimeter(double p) {
>         _radius = p / (2*PI);
>     }
> 
>     public double perimeter() {
>         return 2 * PI * _radius;
>     }
> 
> }
> 
> So: many properties, just one variable for all of them. And you can see 
> that you can use the radius, perimeter or area as the variable, and use 
> the one you want in your implementation according to which setter/getter 
> you think is going to be used the most.

How is that a counter-example? That's exactly how properties are 
supposed to work. Each property manipulator has the name of the property 
it is intended to manipulate and they each do only what they need to do 
to get and set the property. You don't even need to have a member 
variable at all if you can get away with it.

What my example is intended to demonstrate is that you should have one 
manipulator per property action (get/set) -- not one manipulator for 
multiple properties as Karen was demonstrating earlier.