Why are opCall's not implicitely assignable?

[Mike Parker]

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;
    }
}