@property needed or not needed?

Artur Skawina art.08.09 at gmail.com
Sun Dec 2 12:21:16 PST 2012


On 12/02/12 19:48, Rob T wrote:
> There's more than just @property that operate like variables.
> 
> Should we restrict this as well?
> 
> struct stdio
> {
>     void opAssign(T)( T a_arg )
>     {
>        writeln( a_arg );
>     }
> }
> 
> main()
> {
>     stdio writeln;
>     writeln = "hellow world";
> }
> 
> Conceptually, I don't see why we have to impose a difference
> between how variables are assigned and how functions are called.
> 
> A variable "=" assignment is simply a special case of a function
> call that is written for you by the compiler.
> 
> The example of opAssign shows that for some time now, there's
> been pressure to eliminate the difference in at least some cases,
> and allow the programmer to implement their own version of the
> assignment function call.
> 
> If you want to remove inconsistencies, then the way functions and
> variables are manipulated should be unified.
>
> If someone can honestly demonstrate a non-subjective reason why
> there must be a difference between function call and variable
> assignments, please show it. So far I've only seen arguments that
> boil down to "I don't like it".

Do you seriously think that there is no difference and would like
to have to decypher code like

   void main() {
      import std.stdio, std.math;
      writeln(sqrt=81);
   }

?

Having assignments act as calls for every random function is insane.
It can be done and is ok where the programmers decides this makes sense.
Your above stdio example is not such a case. [1]

artur

[1] But thanks for sharing it, I would have probably never thought of
    using a static opAssign otherwise...

   struct stdout {
      static void opAssign(T...)(T args) {
         import std.stdio;
         writeln(args);
      }
   }

   void main() {
      stdout = "It's a strange world";
   }




More information about the Digitalmars-d mailing list