"Karen Lanrap" <karen@digitaldaemon.com> wrote in message news:Xns984698A00AE21digitaldaemoncom@63.105.9.61...

> If you then say it is not an overloading of the assignment operator you have to give a reason, why it differs from overloading the assignment operator.
>
> I do not see any difference. So please explain. I am posting in the learn group with the aim to understand the language. If I would have a clear opinion on this matter I would post in the main D group.

When I talk about operator overloading, I mean in the sense of classes. Have a look at the Operator Overloading section of the spec.  opAdd, opSub, etc.  that kind of operator overloading.

I think you're taking the idea of "overloading" a bit literally.  When we say that "f = 4" is just syntactic sugar for "f(4)", I suppose that yes, in a very literal sense of the word, the assignment operator is overloaded to mean "function call" in this case.  However, it's not user defined, it's part of the language.  So I wouldn't really call it "overloaded."  It's the same thing as anything with multiple meanings in the language -- would you call the tilde (~) operator "overloaded" because it means both bitwise complement and array concatenation?

Since the user cannot control what the assignment operator means, it is not overloadable, and by that, I mean you cannot create an opAssign to change its semantics.

Stewart Gordon wrote:
> It's distinguishable at the moment by whether the lvalue is a variable or a function.
> 
> Trying to add a further dependence on the type of the rvalue would make the language more complicated and possibly harder to understand.

This harder understanding is introduced by the existing syntax sugar already.

You explain it yourself: reading any "x=y;" one has to know whether "x" is a variable or a function because of that syntax sugar.

But
1. what is the difference between a variable and a function?
2. why should one stop introducing further dependencies?


Number 1 may sound silly, but Walter has introduced the assignment to functions as means of a call---and thereby diluted the differences between both concepts.

In fact "real r='\n';" is already a dilution of what a variable is by means of implicit conversion.


Number 2 is only driving the properties of implicite conversions further into the control of the user.

"real r='\n';" could very well, and with an apropriate function f, be replaced by "real r=f('\n');" and this with the short hand to "real r=f='\n';"

Hasan Aljudy wrote:
>> Therefore its distinguishable whether a "=" is a call or an assignment.
> 
> Maybe to the compiler .. but to the user?

Tools are made to support our thinking---and tools influence the way we think:

When all you own is a hammer, every problem starts looking like a nail. (Abraham Maslow)

Karen Lanrap wrote:
> Tools are made to support our thinking---and tools influence the way we think:
> 
> When all you own is a hammer, every problem starts looking like a nail. (Abraham Maslow)

It is my impression that the Sapir-Whorf hypothesis is still hotly contended. Your argument seems to invoke it which seems like bad form. However you still get points for being able to attribute the hammer-nail quote to Maslow.

Karen Lanrap wrote:

> The answer is easy: the opCall for a reference of its own class
> should be disallowed.

 ...

> That is also easy: no qwert can have its own type as a single parameter. Otherwise show me an example.

I believe the original intention of opCall was to allow constructor (ctor) like behavior for structs which have no ctors. Given that origin I think you will find that if an opCall is defined it is in fact normal for it to have an overload which is its own type as a single parameter:

  struct Point
  {
    private:
      int x, y;
    public:
      /// Create a Point object given coords x and  y
      Point* opCall(int x, int y) { /* ... */ }

      /// Create a Point object given another Point
      Point* opCall(Point p) { /* ... */ }
  }

Karen Lanrap wrote:
> Stewart Gordon wrote:
>> It's distinguishable at the moment by whether the lvalue is a
>> variable or a function.
>>
>> Trying to add a further dependence on the type of the rvalue
>> would make the language more complicated and possibly harder to
>> understand. 
> 
> This harder understanding is introduced by the existing syntax sugar already.
> 
> You explain it yourself: reading any "x=y;" one has to know whether "x" is a variable or a function because of that syntax sugar.
<snip>

Not if one is interested primarily in what it does, rather than how it does it.  Which is the whole point of properties.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:

> Not if one is interested primarily in what it does, rather than how it does it.  Which is the whole point of properties.

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?

import std.stdio;
class C{
    int opCall( int p){
        return 2*p;
    }
}

class D{
    C c;
    ~this(){
        c=new C;
    }
}
void main(){
    auto d=new D;
    auto i=d.c=2;
}


As you might notice, we are right back from where we started.

Karen Lanrap wrote:
> Stewart Gordon wrote:
> 
>> Not if one is interested primarily in what it does, rather than
>> how it does it.  Which is the whole point of properties.
> 
> Why has this to be restricted to properties?
> What are properties at all?

A form of syntactic sugar designed to be used when it makes sense to the semantics of what is being done.

For example:

    class Matrix {
        ...
        uint width() { ... }
        uint width(int w) { ... }
        uint height() { ... }
        uint height(int h) { ... }
    }

then you can do something like

    Matrix m = new Matrix;
    m.width = 42;
    m.height = 105;
    writefln("%d %d", m.width, m.height);

The idea is that you are setting/getting the width and height of m, just as you would be if width and height were member variables of Matrix. Defining them as properties just enables more work to be done, e.g. to adjust the internal data structures to fit the new settings.

> Why is a member of a class that is a class with an opCall no property of that class?

Because it's already a member variable.  There's no need for it to be a property as well.

> import std.stdio;
> class C{
>     int opCall( int p){
>         return 2*p;
>     }
> }
> 
> class D{
>     C c;
>     ~this(){
>         c=new C;
>     }
> }

What kind of destructor is this, eh?

> void main(){
>     auto d=new D;
>     auto i=d.c=2;
> }
> 
> 
> As you might notice, we are right back from where we started.

What is what you're trying supposed to achieve over

    class D {
        int c(int p) {
            return 2*p;
        }
    }

???

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

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

Stewart Gordon wrote:

> Defining them as properties just enables more work to be done What is what you're trying supposed to achieve

Please read my answer to Mike Parkers post.