Why are opCall's not implicitely assignable?

Ary Manzana asterite at gmail.com
Wed Sep 27 11:11:51 PDT 2006


Mike Parker wrote:
> 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.

Sorry, I misunderstood you.

Anyway, I also wanted to slip the comment about properties and methods 
(processes). :-)



More information about the Digitalmars-d-learn mailing list