Karen Lanrap wrote:
> Derek Parnell wrote:
> 
>>   with car.roof
>>   {
>>      .topcoat = COLOR.RED;
>>      .undercoat = COLOR.WHITE;
>>   }
>>
>> is nice too.
> 
> Until someone says: topcoat is _not_ a color. It is concrete material that surely must have a property called color, but it is not a color itself: this code is totally unreadable for me.

IMO (and knowing this NG) this is about a point in time where you will stop getting responses to your posts. It usually has something to do with a person refusing to understand a principal as basic as this one.

As for the example. It is all up to you: if topcoat is a color property then

   with car.roof
   {
      .topcoat = COLOR.RED;
      .undercoat = COLOR.WHITE;
   }

else (it is a property of type coat):

   with car.roof
   {
      .topcoat.color = COLOR.RED;
      .undercoat.color = COLOR.WHITE;
   }


> 
> (By the way: forgetting to delete a point can have desastrous results in D.)

What point?

Ivan Senji wrote:

> IMO (and knowing this NG) this is about a point in time where you will stop getting responses to your posts. It usually has something to do with a person refusing to understand a principal as basic as this one.

I already noticed that this NG is filled with posters refusing to understand simple principles---but willing to press others into principles they believe to be simple.

This whole thread showed, that near to none is able to capture that a property might have a complex structure. So complex that it might be best expressed by the most complex structure of D: a class.

I asked a question about the principles of the language D---and got some answers led by personal opinions about coding style. How comes that no answerer was able to convince Walter that his particular style is suitable for an entry in the "Style Guide"?


> It is all up to you:

No, it is not. D prohibits me to code the way I think. And the posters in this thread want not only themselves beeing forced to read the name of the same property over and over again, they also force others to code superfluous words---and at the same time they admire that they can replace a pair of parentheses by an equal sign.

That's mental inconsistency at its best.

Nobody even cared about the fact, that D is also intended for large scale projects which might include british and american style pronounciations, forcing every maintainer to exactly know whether to write color or colour.


> What point?

Ever heard of the module scope operator---or the D-style to separate an operator by one space from its operands?

Karen Lanrap wrote:
> Ivan Senji wrote:
> 
> I already noticed that this NG is filled with posters refusing to understand simple principles---but willing to press others into principles they believe to be simple.
> 
> This whole thread showed, that near to none is able to capture that a property might have a complex structure. So complex that it might be best expressed by the most complex structure of D: a class.
> 

Properties are a well-understood concept across several languages, it is you that are failing to understand them. If, indeed, you do want to use a class as a property nothing is stopping you from doing that. But ask yourself this, if the class were freestanding and *not* a property, would it make sense to assign another type to it?

class Roof { ... }
Roof myRoof = new Roof();
myRoof = Color.Blue;

In D, this will fail to compile, and for good reason. A roof is not a color, so assigning a color to a roof variable makes absolutely no sense whatsoever. The same concept holds true if a Roof object is a property of the car. The roof has properties itself. If you can't be bothered to type car.roof.color, that is not a failure of the language but a personal issue.

Dynamically typed languages like Python and Lua allow you to assign different types to the same variable, but D is not dynamically typed.

> I asked a question about the principles of the language D---and got some answers led by personal opinions about coding style. How comes that no answerer was able to convince Walter that his particular style is suitable for an entry in the "Style Guide"?

Properties are not unique to D. There's no reason to include anything about such a feature the style guide. It's a simple concept that many, many, programmers already comprehend.


> 
> No, it is not. D prohibits me to code the way I think. And the posters in this thread want not only themselves beeing forced to read the name of the same property over and over again, they also force others to code superfluous words---and at the same time they admire that they can replace a pair of parentheses by an equal sign.

Then perhaps you need to clue in that the way you are thinking about properties in statically typed languages is *wrong*. Just because you think something should be done a certain way doesn't mean that it is the commonly accepted way, nor does it mean it should be supported by the language. I don't know of any language that lets diverse people with different thought processes to code in their own unique style in such a way that the meaning is clear to all who read their code (though Perl surely tries).

> 
> That's mental inconsistency at its best.
> 
> Nobody even cared about the fact, that D is also intended for large scale projects which might include british and american style pronounciations, forcing every maintainer to exactly know whether to write color or colour.

Name one language that does? How is it even possible for the compiler to accept alternative spellings for the same variable? Some people use the preprocessor in C or C++ to fake it, but it isn't supported directly by either language.

> 
>> What point?
> 
> Ever heard of the module scope operator---or the D-style to separate an operator by one space from its operands?

You can't delete operators in any language and expect the code to work as is. C,C++,Java,C# all have the . operator. C and C++ also have the -> operator. Try deleting those and see if your code compiles.

As for spacing, that *is* a personal choice. That gets back to readability in the text file (syntax). All C-based languages allow you to write a+b or a + b. You aren't required to follow any one particular style guide at all -- just recommended to.

No one is forcing you to follow commonly accepted standards, or even to use common sense. If you want to continue to say car.roof = Color.Blue, then go right ahead. But later on, when people are confused by your code, you will have only yourself to blame. If you never release any code to the world at large or never work on a team, then it really doesn't matter what you do.

Ivan Senji escribió:
> Karen Lanrap wrote:
> ...
>    with car.roof
>    {
>       .topcoat = COLOR.RED;
>       .undercoat = COLOR.WHITE;
>    }
> 
> else (it is a property of type coat):
> 
>    with car.roof
>    {
>       .topcoat.color = COLOR.RED;
>       .undercoat.color = COLOR.WHITE;
>    }
> 
> 
>>
>> (By the way: forgetting to delete a point can have desastrous results in D.)
> 
> What point?

What Karen is saying is that your examples should be:

with (car.roof)
{
	topcoat = COLOR.RED;
	undercoat = COLOR.WHITE;
}

with (car.roof)
{
	topcoat.color = COLOR.RED;
	undercoat.color = COLOR.WHITE;
}

-- 
Carlos Santander Bernal

Karen Lanrap wrote:
<snip>
> This whole thread showed, that near to none is able to capture that a property might have a complex structure. So complex that it might be best expressed by the most complex structure of D: a class.

I beg to differ. The point, imo, is not that properties might or might not have a complex structure, but should have a simple structure from the users point of view: you know what it does when you see it used, like the - often abused - get/set idiom.

> I asked a question about the principles of the language D---and got some answers led by personal opinions about coding style. How comes that no answerer was able to convince Walter that his particular style is suitable for an entry in the "Style Guide"?
> 
> 
>> It is all up to you:
> 
> No, it is not. D prohibits me to code the way I think. And the posters in this thread want not only themselves beeing forced to read the name of the same property over and over again, they also force others to code superfluous words---and at the same time they admire that they can replace a pair of parentheses by an equal sign.
>
> That's mental inconsistency at its best.

I don't think so. The point is writing code that is understandable, by you and by others. The last one might be even more important, see below. Reading the name of the same property over and over is a lesser evil than it not being clear what is used with what: A = B.A is better than A = B where both mean A = A. Syntax should help understand symantics, which is why A = B.A is good syntactic sugar for A = B.A() but A = B is not. This is not 'just' style.

> Nobody even cared about the fact, that D is also intended for large scale projects which might include british and american style pronounciations, forcing every maintainer to exactly know whether to write color or colour.

Understanding code is about conventions, thus it is more intersubjective than subjective. Maybe some way of expressing a problem is more understandable to you or me, but if it goes against the established conventions it is prudent to adapt to a different concept. If a team of programmers need programming constructs to hide their disagreement of spelling, I'd say they have more serious problems to deal with.


"Programming is for programmers, not computers." - Bartosz Milewski

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.

BTW, I don't like the syntax for properties as they are now. If you have a void function that takes a parameter, it could be a property or a "process" that changes internally the instance, but shouldn't be seen as a property. How can you say which one is it? By looking at the class documentation (i.e., you write "this is a setter", "this is a getter", etc.). Neither in Java or in C# you have to document, because the set/get convention in Java or the syntax of C# allows you not to document it, and see it clearly in the code.

class Some {
  void process(int something) {
  }
}

If you write:

Some s = new Some();
s.process = 1;

the compiler shouldn't let you do that, because even the method "process" has the syntax of a property, it is not (meant to be) a property.

For me, it should be great to have a syntax similar to:

class Circle {

   public setter void radius(double r) { ... }
   public getter double radius() { ... }

   public void process(int some) { ... }
}

Now you can do:

Circle c = new Circle();
c.radius = 2.3;
c.process(2);

But you can't do:

Circle c = new Circle();
c.radius(2.3);
c.process = 2;

---
Ary

Carlos Santander wrote:
> Ivan Senji escribió:
>> Karen Lanrap wrote:
>> ...
>>    with car.roof
>>    {
>>       .topcoat = COLOR.RED;
>>       .undercoat = COLOR.WHITE;
>>    }
>>
>> else (it is a property of type coat):
>>
>>    with car.roof
>>    {
>>       .topcoat.color = COLOR.RED;
>>       .undercoat.color = COLOR.WHITE;
>>    }
>>
>>
>>>
>>> (By the way: forgetting to delete a point can have desastrous results in D.)
>>
>> What point?
> 
> What Karen is saying is that your examples should be:

Ooops, of course they should be without that ".", but are you sure that is what Karen is talking about? Hmm, have to reread...

Karen Lanrap wrote:
> Ivan Senji wrote:
> 
>> IMO (and knowing this NG) this is about a point in time where
>> you will stop getting responses to your posts. It usually has
>> something to do with a person refusing to understand a principal
>> as basic as this one.
> 
> I already noticed that this NG is filled with posters refusing to understand simple principles---but willing to press others into principles they believe to be simple.

Well that depends on ones point of view ;)

> 
> This whole thread showed, that near to none is able to capture that a property might have a complex structure. So complex that it might be best expressed by the most complex structure of D: a class.

I get this, probably most projects have properties that are classes.
And classes are reference types. Allowing opCall to be called in a property style would effectively mean overloading assignment which makes no sense for reference types.

No-overloading-of-assignment is a rule in D for a good reason, and allowing to go around this rule would be plain evil.


>> It is all up to you:
> 
> No, it is not. D prohibits me to code the way I think. 

Which new language doesn't make you think (at least sometimes) in a new way? (Change the way you think)

> And the posters in this thread want not only themselves beeing forced to read the name of the same property over and over again, they also force others to code superfluous words---and at the same time they admire that they can replace a pair of parentheses by an equal sign.
> 

Superfluous to someone is readable and self-documenting to someone else.

> That's mental inconsistency at its best.

Nowhere it is said that assignment can be overloaded (it can't be), and nowhere it is said that opCall is a property. Things would be inconsistent if
a(5) and a.opCall(5) worked and a.opCall = 5; didn't work.

This way there is no inconsistency.

Mental inconsistencies sometimes mean you have to accept something and/or change the way you think. Changing to D-thinking will free your mind (when compared for example to C++ programming)

> 
> Nobody even cared about the fact, that D is also intended for large scale projects which might include british and american style pronounciations, forcing every maintainer to exactly know whether to write color or colour.

And this doesn't have anything to do with anything,
ideally a library should have only one name and be consistent with it. But nothing prevents you from having

struct color{}
alias color colour;

And now anyone can write what ever they prefer.

> 
> 
>> What point?
> 
> Ever heard of the module scope operator

I get it now.

> or the D-style to separate an operator by one space from its operands?

And now I don't get what this means.

But I found out where the story about a "." comes from, Derek accidently left if in his example, and if he or anyone else tried to compile it he would get an error from the compiler about something not being a part of global scope. No disaster.

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.

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). :-)