www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Properties

reply Vishaal <vishaal nospam.com> writes:
Properties, such as array.length, should return lvalues to allow:
a.length += 8;
or other similar statements.
Jan 07 2009
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Vishaal,

 Properties, such as array.length, should return lvalues to allow:
 a.length += 8;
 or other similar statements.

I think there is a (long standing) bug report about that one. Maybe if enough people gripe about it it will get fixed! (NOT said sarcastically!)
Jan 07 2009
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from BCS (ao pathlink.com)'s article
 Reply to Vishaal,
 Properties, such as array.length, should return lvalues to allow:
 a.length += 8;
 or other similar statements.

people gripe about it it will get fixed! (NOT said sarcastically!)

Yeah, this has been mentioned in the past before. The most obvious way to make it work w/o any breaking or significantly bulk-adding changes would be to define foo.length += 8 to mean foo = foo.length() + 8, or foo.length++ mean foo = foo.length + 1. This would be pure syntactic sugar, as it is when working with primitives. One problem that comes to mind is if, instead of length, which is presumably some kind of integer, you have a property for some user defined type with operator overloading. This user-defined type could define opAdd to do something arbitrarily different from opAddAssign. Even if we assume that no reasonable programmer would do this and treat this as a "who cares?" corner case, there's still the problem of opInc and opAddAssign being much cheaper in some cases than opAdd. For example, in some cases opAdd might require copying of a whole bunch of stuff, where opInc or opAddAssign just increments a single primitive under the hood. Bottom line is, unless we assume that properties of user-defined types aren't important, we need a better solution. Oh yeah, and on the more special case of arrays, which the compiler already treats as special, yes, foo.length += 2 should be legal. As far as I can tell, this is a no-brainer.
Jan 07 2009
next sibling parent Vishaal <vishaal nospam.com> writes:
dsimcha Wrote:

 == Quote from BCS (ao pathlink.com)'s article
 Reply to Vishaal,
 Properties, such as array.length, should return lvalues to allow:
 a.length += 8;
 or other similar statements.

people gripe about it it will get fixed! (NOT said sarcastically!)

Yeah, this has been mentioned in the past before. The most obvious way to make it work w/o any breaking or significantly bulk-adding changes would be to define foo.length += 8 to mean foo = foo.length() + 8, or foo.length++ mean foo = foo.length + 1. This would be pure syntactic sugar, as it is when working with primitives. One problem that comes to mind is if, instead of length, which is presumably some kind of integer, you have a property for some user defined type with operator overloading. This user-defined type could define opAdd to do something arbitrarily different from opAddAssign. Even if we assume that no reasonable programmer would do this and treat this as a "who cares?" corner case, there's still the problem of opInc and opAddAssign being much cheaper in some cases than opAdd. For example, in some cases opAdd might require copying of a whole bunch of stuff, where opInc or opAddAssign just increments a single primitive under the hood. Bottom line is, unless we assume that properties of user-defined types aren't important, we need a better solution. Oh yeah, and on the more special case of arrays, which the compiler already treats as special, yes, foo.length += 2 should be legal. As far as I can tell, this is a no-brainer.

The two methods aren't mutually exclusive. We could let users write opAddAssign if they want but if there would be no benefit (or if they don't care about memory) they wouldn't have to write an opAddAssign and the compiler would expand it. ++gripes.length; Sorry, gripes.length = gripes.length + 1;
Jan 07 2009
prev sibling next sibling parent reply Michiel Helvensteijn <nomail please.com> writes:
dsimcha wrote:

 Yeah, this has been mentioned in the past before.  The most obvious way to
 make it work w/o any breaking or significantly bulk-adding changes would
 be to define foo.length += 8 to mean foo = foo.length() + 8, or
 foo.length++ mean foo =
 foo.length + 1.  This would be pure syntactic sugar, as it is when working
 with primitives.
 
 One problem that comes to mind is if, instead of length, which is
 presumably some kind of integer, you have a property for some user defined
 type with operator
 overloading.  This user-defined type could define opAdd to do something
 arbitrarily different from opAddAssign.  Even if we assume that no
 reasonable programmer would do this and treat this as a "who cares?"
 corner case, there's still the problem of opInc and opAddAssign being much
 cheaper in some cases than
 opAdd.  For example, in some cases opAdd might require copying of a whole
 bunch of stuff, where opInc or opAddAssign just increments a single
 primitive under the hood.

I've always thought properties should work somewhat like this: property int length { get() { return this.len; } set(newLen) { this.len = newLen; } } The return-type of get is automatically int, as is the parameter-type of set. These two functions are automatically called when the property is used. int a = length; // int a = length.get(); length = 10; // length.set(10); In cases where read/write access is needed, the compiler can do this: length++; // int temp = length.get(); // temp++; // length.set(temp); This can work for any user-defined type, since we're using the same operator. If you want it done faster 'under the hood', you can use operator-overloads inside the property: property int length { get() { return this.len; } set(newLen) { this.len = newLen; } void opIncrement() { this.len++; } } -- Michiel
Jan 08 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Michiel Helvensteijn" <nomail please.com> wrote in message 
news:gk4oi2$14tv$1 digitalmars.com...
 dsimcha wrote:

 Yeah, this has been mentioned in the past before.  The most obvious way 
 to
 make it work w/o any breaking or significantly bulk-adding changes would
 be to define foo.length += 8 to mean foo = foo.length() + 8, or
 foo.length++ mean foo =
 foo.length + 1.  This would be pure syntactic sugar, as it is when 
 working
 with primitives.

 One problem that comes to mind is if, instead of length, which is
 presumably some kind of integer, you have a property for some user 
 defined
 type with operator
 overloading.  This user-defined type could define opAdd to do something
 arbitrarily different from opAddAssign.  Even if we assume that no
 reasonable programmer would do this and treat this as a "who cares?"
 corner case, there's still the problem of opInc and opAddAssign being 
 much
 cheaper in some cases than
 opAdd.  For example, in some cases opAdd might require copying of a whole
 bunch of stuff, where opInc or opAddAssign just increments a single
 primitive under the hood.

I've always thought properties should work somewhat like this: property int length { get() { return this.len; } set(newLen) { this.len = newLen; } } The return-type of get is automatically int, as is the parameter-type of set. These two functions are automatically called when the property is used. int a = length; // int a = length.get(); length = 10; // length.set(10); In cases where read/write access is needed, the compiler can do this: length++; // int temp = length.get(); // temp++; // length.set(temp); This can work for any user-defined type, since we're using the same operator. If you want it done faster 'under the hood', you can use operator-overloads inside the property: property int length { get() { return this.len; } set(newLen) { this.len = newLen; } void opIncrement() { this.len++; } }

Agreed. The current way is just sloppy and it bothers me constantly. *gripe* *gripe* *gripe* I would make two modifications to your suggestion though: 1. Like in C#, you shouldn't need to define paramater lists for "set" and "get". They're always going to be the same. In the case of "set", it's always going to be just the one param, and it'll be the new value, so just make a special predefined var. Something like: get { return this.len; } set { this.len = value; } // "value" (like in C#), or "$" or something like that 2. You shouldn't have to manually define a private var to go along with the property. In languages with real properties, the following idiom is used constantly: private int _var; public property int var { get { return _var; } set { _var = $; } void opIncrement() { _var++; } } Why should that be needed? It should be like this: public property int var { // int internalValue; // Automatically created (but named better) get { return internalValue; } set { internalValue = $; } void opIncrement() { internalValue++; } } In the minority of cases where a property doesn't need this variable, "internalValue" can just be optimized away.
Jan 08 2009
parent reply Michiel Helvensteijn <nomail please.com> writes:
Nick Sabalausky wrote:

 1. Like in C#, you shouldn't need to define paramater lists for "set" and
 "get". They're always going to be the same. In the case of "set", it's
 always going to be just the one param, and it'll be the new value, so just
 make a special predefined var. Something like:
 
 get { return this.len; }
 set { this.len = value; } // "value" (like in C#), or "$" or something
 like that

I have to disagree. By that logic, we would abolish parameter-names altogether and access formal parameters by number. set has a parameter, and the programmer should be able to name it. Also, removing the parentheses would be confusing. I believe it might be better to make them look like this, even: property int length { auto get() { .. } void set(auto name) { .. } } So they would clearly be function declarations.
 2. You shouldn't have to manually define a private var to go along with
 the property. In languages with real properties, the following idiom is
 used constantly:
 
 private int _var;
 public property int var {
    get { return _var; }
    set { _var = $; }
    void opIncrement() { _var++; }
 }
 
 Why should that be needed? It should be like this:
 
 public property int var {
    // int internalValue; // Automatically created (but named better)
    get { return internalValue; }
    set { internalValue = $; }
    void opIncrement() { internalValue++; }
 }
 
 In the minority of cases where a property doesn't need this variable,
 "internalValue" can just be optimized away.

If you really want that behavior, you should just use a public variable. Even changing it to a real property later would not matter for the public interface. -- Michiel
Jan 08 2009
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Michiel Helvensteijn wrote:
 Nick Sabalausky wrote:
 
 1. Like in C#, you shouldn't need to define paramater lists for "set" and
 "get". They're always going to be the same. In the case of "set", it's
 always going to be just the one param, and it'll be the new value, so just
 make a special predefined var. Something like:

 get { return this.len; }
 set { this.len = value; } // "value" (like in C#), or "$" or something
 like that

I have to disagree. By that logic, we would abolish parameter-names altogether and access formal parameters by number. set has a parameter, and the programmer should be able to name it.

It's very different. A setter has a very specific meaning: set some value. That's why it's called "value". Another name could be the name of the property ("len") or something like "newLen". Which other name would you use? A general function can have any kind of meaning, and so its parameters, and that's why it's ok to have names for them.
 
 Also, removing the parentheses would be confusing.

That's more a matter of taste. In C# I find this ok. I believe it might be
 better to make them look like this, even:
 
 property int length {
     auto get() { .. }
     void set(auto name) { .. }

name? But it's the length. :-P
Jan 08 2009
parent reply Michiel Helvensteijn <nomail please.com> writes:
Ary Borenszweig wrote:

 get { return this.len; }
 set { this.len = value; } // "value" (like in C#), or "$" or something
 like that

I have to disagree. By that logic, we would abolish parameter-names altogether and access formal parameters by number. set has a parameter, and the programmer should be able to name it.

It's very different. A setter has a very specific meaning: set some value. That's why it's called "value". Another name could be the name of the property ("len") or something like "newLen". Which other name would you use?

It's not for me to say. It should be up to the programmer. You've already shown that there are at least three possibilities. -- Michiel
Jan 08 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Michiel Helvensteijn wrote:
 Ary Borenszweig wrote:
 
 get { return this.len; }
 set { this.len = value; } // "value" (like in C#), or "$" or something
 like that

altogether and access formal parameters by number. set has a parameter, and the programmer should be able to name it.

value. That's why it's called "value". Another name could be the name of the property ("len") or something like "newLen". Which other name would you use?

It's not for me to say. It should be up to the programmer. You've already shown that there are at least three possibilities.

Yes, three. And that's it. That was my point. And they all have pretty much the same meaning. Well, unless you want to name it "nuevaLen", "novaLen", "nouvelleLen", etc. :-P
Jan 08 2009
parent reply Michiel Helvensteijn <nomail please.com> writes:
Ary Borenszweig wrote:

 It's very different. A setter has a very specific meaning: set some
 value. That's why it's called "value". Another name could be the name of
 the property ("len") or something like "newLen". Which other name would
 you use?

It's not for me to say. It should be up to the programmer. You've already shown that there are at least three possibilities.

Yes, three. And that's it. That was my point. And they all have pretty much the same meaning. Well, unless you want to name it "nuevaLen", "novaLen", "nouvelleLen", etc. :-P

Perhaps the implicit declaration "value" (or whatever *you* would call it) inadvertently overshadows a member variable with that name. That could result in a bug that would be pretty hard to find. -- Michiel
Jan 08 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Michiel Helvensteijn" <nomail please.com> wrote in message 
news:gk5f80$2lav$1 digitalmars.com...
 Ary Borenszweig wrote:

 It's very different. A setter has a very specific meaning: set some
 value. That's why it's called "value". Another name could be the name 
 of
 the property ("len") or something like "newLen". Which other name would
 you use?

It's not for me to say. It should be up to the programmer. You've already shown that there are at least three possibilities.

Yes, three. And that's it. That was my point. And they all have pretty much the same meaning. Well, unless you want to name it "nuevaLen", "novaLen", "nouvelleLen", etc. :-P

Perhaps the implicit declaration "value" (or whatever *you* would call it) inadvertently overshadows a member variable with that name. That could result in a bug that would be pretty hard to find.

Overshadowing is already a potential issue anyway, with or without properties. Even a user-defined name could still accidentally overshadow something. Also, using "$" could help minimize overshadowing, the only thing that could ever clash with that is the "array.length" shorthand inside array slices/indexes (and even that already has potential for clashing, specifically when using nested indexes).
Jan 08 2009
parent reply Michiel Helvensteijn <nomail please.com> writes:
Nick Sabalausky wrote:

 Perhaps the implicit declaration "value" (or whatever *you* would call
 it) inadvertently overshadows a member variable with that name. That
 could result in a bug that would be pretty hard to find.

Overshadowing is already a potential issue anyway, with or without properties. Even a user-defined name could still accidentally overshadow something.

Sure, but in that case both of the declarations are explicit. Now there's an invisible variable blocking a visible one. Could be quite confusing.
 Also, using "$" could help minimize overshadowing, the only 
 thing that could ever clash with that is the "array.length" shorthand
 inside array slices/indexes (and even that already has potential for
 clashing, specifically when using nested indexes).

Using $ just doesn't make much sense. To what lengths are you willing to go to avoid typing a few more characters? Or do you really find $ more readable? Who could guess that $ inside the set function stands for its invisible parameter? -- Michiel
Jan 08 2009
parent "Nick Sabalausky" <a a.a> writes:
"Michiel Helvensteijn" <nomail please.com> wrote in message 
news:gk5h9r$2p7g$1 digitalmars.com...
 Nick Sabalausky wrote:

 Perhaps the implicit declaration "value" (or whatever *you* would call
 it) inadvertently overshadows a member variable with that name. That
 could result in a bug that would be pretty hard to find.

Overshadowing is already a potential issue anyway, with or without properties. Even a user-defined name could still accidentally overshadow something.

Sure, but in that case both of the declarations are explicit. Now there's an invisible variable blocking a visible one. Could be quite confusing.

Possibly. But I've used it a lot in C# and never had a problem. And syntax highlighting can help (as well as the fact that C#'s "value" looks much more like a keyword than my purely tentative "newValue").
 Also, using "$" could help minimize overshadowing, the only
 thing that could ever clash with that is the "array.length" shorthand
 inside array slices/indexes (and even that already has potential for
 clashing, specifically when using nested indexes).

Using $ just doesn't make much sense. To what lengths are you willing to go to avoid typing a few more characters? Or do you really find $ more readable? Who could guess that $ inside the set function stands for its invisible parameter?

It's not so much about saving typing as the clarity that comes from consistency. And as with "array[0..$]", or the "a + b" stuff in phobos2's functional-style modules, it's easy if you're aware of it (you can't expect every new language feature to be obvious at a glance to someone who's never glanced at the docs). I'll grant that "$" may not be as descriptive as, say "newValue", but I'd certainly find it much more readable than having it named something completely different in every setter in the codebase.
Jan 08 2009
prev sibling next sibling parent reply Chad J <gamerchad __spam.is.bad__gmail.com> writes:
Michiel Helvensteijn wrote:
 Nick Sabalausky wrote:
 
 2. You shouldn't have to manually define a private var to go along with
 the property. In languages with real properties, the following idiom is
 used constantly:

 private int _var;
 public property int var {
    get { return _var; }
    set { _var = $; }
    void opIncrement() { _var++; }
 }

 Why should that be needed? It should be like this:

 public property int var {
    // int internalValue; // Automatically created (but named better)
    get { return internalValue; }
    set { internalValue = $; }
    void opIncrement() { internalValue++; }
 }

 In the minority of cases where a property doesn't need this variable,
 "internalValue" can just be optimized away.

If you really want that behavior, you should just use a public variable. Even changing it to a real property later would not matter for the public interface.

That's not quite why it was suggested. I actually like the idea. It is true that a public member would be preferred in the trivial case. In the general case though, people will have some internal value they are working with and whenever someone works with it they want side effects to happen. Here's an example: int nTimesVarRead = 0; public property int var { get { nTimesVarRead++; return internalValue; } set { internalValue = $; } } compare against: int nTimesVarRead = 0; int m_var; // Annoying extra declaration that is common practice. public property int var { get { nTimesVarRead++; return m_var; } set { m_var = $; } } Thus I rather like that idea. Perhaps, since the compiler knows the name of the property, the name of the generated internal value could just be the name of the property: public property int var { get { return var; } set { var = $; } } public property int foo { get { return foo; } set { foo = $; } } etc.
Jan 08 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Chad J:
 public property int var
 {
     get { return var; }
     set { var = $; }
 }
 
 public property int foo
 {
     get { return foo; }
     set { foo = $; }
 }

I think I have suggested something similar, time ago. The default situations you have shown may enjoy an even shorter syntax, for example: public property int var { get set } That can also become the following when you want only a getter or setter: public property int var { get } Or: public property int var { set } (I don't like all those repeated "foo"/"var", it's not much DRY. But at the moment I see no better solution, that works well for nested classes/structs too). Let's see if Walter likes all this. Bye, bearophile
Jan 08 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:gk5grh$2o8i$1 digitalmars.com...
 Chad J:
 public property int var
 {
     get { return var; }
     set { var = $; }
 }

 public property int foo
 {
     get { return foo; }
     set { foo = $; }
 }

I think I have suggested something similar, time ago. The default situations you have shown may enjoy an even shorter syntax, for example: public property int var { get set } That can also become the following when you want only a getter or setter: public property int var { get } Or: public property int var { set } (I don't like all those repeated "foo"/"var", it's not much DRY. But at the moment I see no better solution, that works well for nested classes/structs too).

Something like this: public property int var { get { return property; } set { property = $; } } Or something like this: public property int foo { get { return $; } set { $ = $new; } }
 Let's see if Walter likes all this.

 Bye,
 bearophile 

Jan 08 2009
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Nick Sabalausky wrote:
 "bearophile"<bearophileHUGS lycos.com>  wrote in message
 news:gk5grh$2o8i$1 digitalmars.com...
 Chad J:
 public property int var
 {
      get { return var; }
      set { var = $; }
 }

 public property int foo
 {
      get { return foo; }
      set { foo = $; }
 }

The default situations you have shown may enjoy an even shorter syntax, for example: public property int var { get set } That can also become the following when you want only a getter or setter: public property int var { get } Or: public property int var { set } (I don't like all those repeated "foo"/"var", it's not much DRY. But at the moment I see no better solution, that works well for nested classes/structs too).

Something like this: public property int var { get { return property; } set { property = $; } } Or something like this: public property int foo { get { return $; } set { $ = $new; } }
 Let's see if Walter likes all this.

 Bye,
 bearophile


I like the general idea, but why invent new words? how about this: public property int var { get { return this; } set { this = new; } } there's one issue with the above - what about the "this" of the container class/struct, but that's solved easily with "outer" just like in nested classes. it makes sense to me since the feature seems to be mainly syntax sugar for something like the following: class A { struct Prop { int internal; int opCall() { return internal; } void opAssign(int value) { internal = value; } } public Prop prop; ... } void main() { auto a = new A; int num = a.prop; a.prop = 9; ... }
Jan 08 2009
parent "Nick Sabalausky" <a a.a> writes:
"Yigal Chripun" <yigal100 gmail.com> wrote in message 
news:gk5t92$fu2$1 digitalmars.com...
 Nick Sabalausky wrote:
 "bearophile"<bearophileHUGS lycos.com>  wrote in message
 news:gk5grh$2o8i$1 digitalmars.com...
 Chad J:
 public property int var
 {
      get { return var; }
      set { var = $; }
 }

 public property int foo
 {
      get { return foo; }
      set { foo = $; }
 }

The default situations you have shown may enjoy an even shorter syntax, for example: public property int var { get set } That can also become the following when you want only a getter or setter: public property int var { get } Or: public property int var { set } (I don't like all those repeated "foo"/"var", it's not much DRY. But at the moment I see no better solution, that works well for nested classes/structs too).

Something like this: public property int var { get { return property; } set { property = $; } } Or something like this: public property int foo { get { return $; } set { $ = $new; } }
 Let's see if Walter likes all this.

 Bye,
 bearophile


I like the general idea, but why invent new words? how about this: public property int var { get { return this; } set { this = new; } } there's one issue with the above - what about the "this" of the container class/struct, but that's solved easily with "outer" just like in nested classes.

*smacks forehead* I completely forget about "outer". That's the only reason I didn't suggest "this". That is good. But using "new" in that particular way bothers me a little. What about making the new value a property of "this": set { this = this.new; } set { this = this.next; } set { this = this.prime; } // Math-style set { this = this.pending; } set { this = this.hcwgcwFNbchbSCCGUgucG; }
 it makes sense to me since the feature seems to be mainly syntax sugar for 
 something like the following:

 class A {
 struct Prop {
 int internal;
 int opCall() { return internal; }
 void opAssign(int value) { internal = value; }
 }
 public Prop prop;
 ...
 }

 void main() {
 auto a = new A;
 int num = a.prop;
 a.prop = 9;
 ...
 }

Good point.
Jan 08 2009
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Chad J" <gamerchad __spam.is.bad__gmail.com> wrote in message 
news:gk5fch$2ldo$1 digitalmars.com...
 Michiel Helvensteijn wrote:
 Nick Sabalausky wrote:

 2. You shouldn't have to manually define a private var to go along with
 the property. In languages with real properties, the following idiom is
 used constantly:

 private int _var;
 public property int var {
    get { return _var; }
    set { _var = $; }
    void opIncrement() { _var++; }
 }

 Why should that be needed? It should be like this:

 public property int var {
    // int internalValue; // Automatically created (but named better)
    get { return internalValue; }
    set { internalValue = $; }
    void opIncrement() { internalValue++; }
 }

 In the minority of cases where a property doesn't need this variable,
 "internalValue" can just be optimized away.

If you really want that behavior, you should just use a public variable. Even changing it to a real property later would not matter for the public interface.

That's not quite why it was suggested. I actually like the idea. It is true that a public member would be preferred in the trivial case. In the general case though, people will have some internal value they are working with and whenever someone works with it they want side effects to happen. Here's an example: int nTimesVarRead = 0; public property int var { get { nTimesVarRead++; return internalValue; } set { internalValue = $; } } compare against: int nTimesVarRead = 0; int m_var; // Annoying extra declaration that is common practice. public property int var { get { nTimesVarRead++; return m_var; } set { m_var = $; } } Thus I rather like that idea. Perhaps, since the compiler knows the name of the property, the name of the generated internal value could just be the name of the property: public property int var { get { return var; } set { var = $; } } public property int foo { get { return foo; } set { foo = $; } } etc.

That I don't like, for the same reason VB's syntax for returning a value from a function drives me nuts: Function Foo Foo = 7 End Function It's a DRY violation. Anytime you change the name of Foo, it's just that much more that also needs to be updated. And if you copy it to use as a starting point for another function, then again you have that much more to update. Granted, that can all be solved with an refactoring feature in the editor, but if I wanted my language to be reliant on IDE features, I'd use Java. As long as it's come up, this is another case that frequently annoys me: template foo(alias a /*...*/) { const char[] foo = /*some fancy code-generation here*/; //pragma(msg, "foo: "~foo); // for debugging the template } mixin(foo!(/*...*/)); I do that frequently, and when developing them I'm constantly changing names, and ever time I do, I have to change the name and then copy-paste the new name to at least three other places. PITA.
Jan 08 2009
parent Chad J <gamerchad __spam.is.bad__gmail.com> writes:
Nick Sabalausky wrote:

 It's a DRY violation. 

I agree, good call.
Jan 08 2009
prev sibling parent reply Miles <_______ _______.____> writes:
Chad J wrote:
 I actually like the idea.
 
 (...)
 
 int nTimesVarRead = 0;
 
 public property int var
 {
     get
     {
         nTimesVarRead++;
         return internalValue;
     }
 
     set { internalValue = $; }
 }

That defeats one of the purposes of properties. A property is usually an accessor for some member variable. You have two concepts: the property and the member variable; they MUST be declared separately, since they may have different attributes. For example, the underlying member variable may have any of public, protected or private visibility, while the property may also have any of public, protected or private visibility. Usually, the member variable is either protected or private, while the property is either public or protected. Also, the class itself, and any inner scopes, may want to access the underlying member variable directly, without going through the property accessors.
 Perhaps, since the compiler knows the name of the property, the name of
 the generated internal value could just be the name of the property:
 
 public property int var
 {
     get { return var; }
     set { var = $; }
 }

That is the question... the property is public, but var is private or protected? How does the class access var without triggering the property accessors?
Jan 08 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Miles" <_______ _______.____> wrote in message 
news:gk68q1$19g1$1 digitalmars.com...
 Chad J wrote:
 I actually like the idea.

 (...)

 int nTimesVarRead = 0;

 public property int var
 {
     get
     {
         nTimesVarRead++;
         return internalValue;
     }

     set { internalValue = $; }
 }

That defeats one of the purposes of properties. A property is usually an accessor for some member variable. You have two concepts: the property and the member variable; they MUST be declared separately, since they may have different attributes. For example, the underlying member variable may have any of public, protected or private visibility, while the property may also have any of public, protected or private visibility. Usually, the member variable is either protected or private, while the property is either public or protected. Also, the class itself, and any inner scopes, may want to access the underlying member variable directly, without going through the property accessors.

This proposal doesn't prevent any of that. Suppose our syntax was like in the example above. I would still be able to do something like this: --------------- protected int _var; public property char[] var { // char[] internalValue is still defined, // but gets optimized away since it's never used. get { return ToString(_var); } set { _var = ToInt($); } } --------------- Also, we could say that the "internalValue" attribute of "private" (or protected, maybe we could have a way to optionally allow it to be protected) means "private to the class that contains the property" instead of "only accessible to the code within the property definition". Then we could do: --------------- class Foo { public property int myProp { get { return internalValue; } set { internalValue = $; } } public bar() { Stdout.formatln("{}", myProp.internalValue); } } --------------- Although I think I'm starting to really like the syntax being developed in another branch of this thread...(also I think I'm going to expand it a little): --------------- module foo; class Foo { public property int myProp { get { return this; } set { this = this.new; } } // Shorthand for the same trivial accessors in "myProp" public property int myShorthandProp { get; set; } public property int readOnlyProp { get { return 7; } } public property int writeOnlyProp { set; } public property int polysemousProp { set { this = this.new; } get { return this; } set char[] { this = StringToInt(this.new); } // If we ever got overload-on-return-value get char[] { return IntToString(this); } } private property int privateProp { get; set; } public property int anotherProp { /* Change access attribute of internal value, default could be either protected or private. This doesn't affect Foo's ability to see or not see the internal value. This only affects Foo subclasses and code outside the module. */ protected this; get; // Foo can access anotherProp's setter, but everything else sees anotherProp as read-only. private set; } public bar() { auto a = myProp; // Ok, uses getter auto b = myProp.this; // Ok, internal value auto c = privateProp; // Ok, uses getter auto d = privateProp.this; // Ok, internal value auto e = writeOnlyProp; // Error: no getter auto f = writeOnlyProp.this; // Ok, since we're inside Foo } } module main; void main() { auto foo = new Foo(); auto a = myProp; // Ok, uses getter auto b = myProp.this; // Error: internal value is private to Foo auto c = privateProp; // Error: privateProp is private auto c = privateProp.this; // Error: privateProp is private auto e = writeOnlyProp; // Error: no getter auto f = writeOnlyProp.this; // Error: internal value is private to Foo } ---------------
 Perhaps, since the compiler knows the name of the property, the name of
 the generated internal value could just be the name of the property:

 public property int var
 {
     get { return var; }
     set { var = $; }
 }

That is the question... the property is public, but var is private or protected? How does the class access var without triggering the property accessors?

See above.
Jan 08 2009
parent Miles <_______ _______.____> writes:
Nick Sabalausky wrote:
 This proposal doesn't prevent any of that. Suppose our syntax was like in 
 the example above. I would still be able to do something like this:
 
 ---------------
 protected int _var;
 public property char[] var
 {
     // char[] internalValue is still defined,
     // but gets optimized away since it's never used.
 
     get { return ToString(_var); }
     set { _var = ToInt($); }
 }
 ---------------

The problem I see with this is that it complicates the implementation of properties. Properties are just collections of delegates, perhaps even optimized to contain only a single frame pointer for multiple function pointers. Properties may appear in contexts where you can't have member variables (e.g., interfaces).
 ---------------
 class Foo
 {
     public property int myProp
     {
         get { return internalValue; }
         set { internalValue = $; }
     }
 
     public bar()
     {
         Stdout.formatln("{}", myProp.internalValue);
     }
 }
 ---------------

Won't work, not like that. For the compiler, that is difficult to distinguish from calling the getter for myProp (that returns an int), and trying to access a member variable called "internalValue" from that int instance. The compiler could provide some syntax to disambiguate property's members from it's value's members. Perhaps: property(myProp).internalValue; In this case, property(...) tells the compiler to handle the argument as the property itself, without calling the getter. But requiring that syntax just sucks. I find it better to have the value in another variable.
Jan 09 2009
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Michiel Helvensteijn" <nomail please.com> wrote in message 
news:gk5b4m$2ekd$1 digitalmars.com...
 Nick Sabalausky wrote:

 1. Like in C#, you shouldn't need to define paramater lists for "set" and
 "get". They're always going to be the same. In the case of "set", it's
 always going to be just the one param, and it'll be the new value, so 
 just
 make a special predefined var. Something like:

 get { return this.len; }
 set { this.len = value; } // "value" (like in C#), or "$" or something
 like that

I have to disagree. By that logic, we would abolish parameter-names altogether and access formal parameters by number.

I don't think that follows at all. Function parameters have user-definable names because functions are a general concept that, for all the syntax is aware, could have any number of params that could each represent just about anything. Property getters/setters are different: A property getter is ALWAYS going to take nothing in and return a value of the same type as the property that represents the value of the property. Otherwise it wouldn't be a property getter. A property setter is ALWAYS going to return nothing and take in exactly one argument, of the same type as the property, and that value will ALWAYS represent the intended new value. Otherwise it wouldn't be a property setter. With this information, requiring a custom user-defined name for the setter parameter becomes completely frivolous. You may as well require people to make up their own names for "void", "if", "while" and "{some array here}.length": they're always going to mean the same thing so it's much better to have it standardized.
 set has a parameter, and
 the programmer should be able to name it.

 Also, removing the parentheses would be confusing. I believe it might be
 better to make them look like this, even:

 property int length {
    auto get() { .. }
    void set(auto name) { .. }
 }

 So they would clearly be function declarations.

What benefit would that provide? Downside: The fact that they're part of the language-defined property getter/setter syntax renders any explicitly-stated parameter and return-value information completely redundant. Of course, I'm aware that sometimes redundancy can be good since it can help catch errors, but this particular redundancy doesn't do anything to help catch errors. In fact, it could cause confusion because it obscures the fact that "get" and "set" are special function names within a "property" block. (Plus it's just not as clean-looking as a C#-style "get {} set{}") I suppose explicitly stating the return type and parameter lists could open the door for "multitype" properties that could "get" or "set" different types without relying on the caller to cast/convert. I'm not sure how I feel about that though...it might be nice...
 2. You shouldn't have to manually define a private var to go along with
 the property. In languages with real properties, the following idiom is
 used constantly:

 private int _var;
 public property int var {
    get { return _var; }
    set { _var = $; }
    void opIncrement() { _var++; }
 }

 Why should that be needed? It should be like this:

 public property int var {
    // int internalValue; // Automatically created (but named better)
    get { return internalValue; }
    set { internalValue = $; }
    void opIncrement() { internalValue++; }
 }

 In the minority of cases where a property doesn't need this variable,
 "internalValue" can just be optimized away.

If you really want that behavior, you should just use a public variable. Even changing it to a real property later would not matter for the public interface.

The bodies of those get's and set's were just trivial examples. I agree an actual property like that would be pointless. But a typical use-case for properties is to intercept accesses to a member variable and perform some sort of action on each access (validation, logging, updating a related value, etc). In other words, you still frequently need the "private int _x; property int x {}" idiom. In my experience, these sorts of things are the most common uses for properties, and even if they weren't it would be simple enough to optimize away the implied private var whenever it's not needed, so the feature would never cause any trouble, it would just help in many cases (plus provide a standardized name).
Jan 08 2009
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:gk5fo7$2m80$1 digitalmars.com...
 "Michiel Helvensteijn" <nomail please.com> wrote in message 
 news:gk5b4m$2ekd$1 digitalmars.com...
 Nick Sabalausky wrote:

 1. Like in C#, you shouldn't need to define paramater lists for "set" 
 and
 "get". They're always going to be the same. In the case of "set", it's
 always going to be just the one param, and it'll be the new value, so 
 just
 make a special predefined var. Something like:

 get { return this.len; }
 set { this.len = value; } // "value" (like in C#), or "$" or something
 like that

I have to disagree. By that logic, we would abolish parameter-names altogether and access formal parameters by number.

I don't think that follows at all. Function parameters have user-definable names because functions are a general concept that, for all the syntax is aware, could have any number of params that could each represent just about anything. Property getters/setters are different: A property getter is ALWAYS going to take nothing in and return a value of the same type as the property that represents the value of the property. Otherwise it wouldn't be a property getter. A property setter is ALWAYS going to return nothing and take in exactly one argument, of the same type as the property, and that value will ALWAYS represent the intended new value. Otherwise it wouldn't be a property setter. With this information, requiring a custom user-defined name for the setter parameter becomes completely frivolous. You may as well require people to make up their own names for "void", "if", "while" and "{some array here}.length": they're always going to mean the same thing so it's much better to have it standardized.

Sorry, Ary beat me to it. And much less verbosely ;)
Jan 08 2009
prev sibling parent reply Miles <_______ _______.____> writes:
Nick Sabalausky wrote:
 A property setter is ALWAYS going to return nothing and

Both the getter and the setter should return an rvalue. Properties exist so that they are interchangeable with real member variables. Something that is possible with member variables MUST also be possible with properties, in a transparent way for any code outside the class. For example: button.width = button.height = 50; // makes a square button Optimally, this should expand to either: button._set_width(button._set_height(50)); or button._set_height(50); button._set_width(button._get_height()); From the compiler point-of-view, the first is easier to implement.
 take in exactly one argument, of the same type as the property,
 and that value will ALWAYS represent the intended new value.

Also not true. It is fine to have method polymorphism for the setter. You may want to define property set(int value), set(Bigint value) and set(float value), all with different semantics.
Jan 08 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Miles" <_______ _______.____> wrote in message 
news:gk67hr$17d9$1 digitalmars.com...
 Nick Sabalausky wrote:
 A property setter is ALWAYS going to return nothing and

Both the getter and the setter should return an rvalue. Properties exist so that they are interchangeable with real member variables. Something that is possible with member variables MUST also be possible with properties, in a transparent way for any code outside the class. For example: button.width = button.height = 50; // makes a square button Optimally, this should expand to either: button._set_width(button._set_height(50)); or button._set_height(50); button._set_width(button._get_height()); From the compiler point-of-view, the first is easier to implement.

True, but my main point was, however the language ends up handling the details of property getters/setters, it's not going to be as general as ordinary functions, and thus certain aspects of the syntax can/should be simplified. But regarding your examples up there, the first form might be easier for the compiler to implement, but I think the second would be overall better. You're absolutely right that properties need to be able to return an rvalue from an assignment, but I see no reason why that can't or shouldn't be transparent to the person writing the property.
 take in exactly one argument, of the same type as the property,
 and that value will ALWAYS represent the intended new value.

Also not true. It is fine to have method polymorphism for the setter. You may want to define property set(int value), set(Bigint value) and set(float value), all with different semantics.

I'm still not 100% convinced that we should be using properties to do type conversions, although I suppose it may have some legitimate uses... I guess I'm just afraid of ending up with a situation where people start feeling compelled to make all of their properties explicitly compatible with every type under the sun. All of a sudden we'd be heading towards all-out dynamic typing, and start losing the benefits of static typing, and, and...then the sun explodes...or something...(I should stay off that slippery slope...) But anyway, even with the possibility of a property handling multiple types, I still don't think it means we can't or shouldn't have a nicely trimmed syntax for the more typical cases: property int x { set { this = this.new; } get { return this; } set char[] { this = StringToInt(this.new); } get char[] { return IntToString(this); } // If we ever got overload-on-return-value }
Jan 08 2009
parent reply Miles <_______ _______.____> writes:
Nick Sabalausky wrote:
 True, but my main point was, however the language ends up handling the 
 details of property getters/setters, it's not going to be as general as 
 ordinary functions, and thus certain aspects of the syntax can/should be 
 simplified.

In this case, simplifying would be more complex. Under the hood, when you define getters and setters, you are defining functions, and function overloading is an inherent feature of the language. In fact, the current "property" feature of D already supports many overloaded setters for different types, since they are just normal functions. For example, consider the property definition: public property int width { get() { return width; } set(int value) { width = value; } set(float value) { width = value + 0.5; } } That would generate overloaded functions with different signatures, lets say that, under the hood, the compiler generates: int __get_width(); int __set_width(int value); int __set_width(float value); Then, when code that accesses the property is compiled, something that looks like width = x; will, in fact, be threated as __set_width(x); and so, the compiler will choose the appropriate __set_width() function with the signature that matches the above call. So, restricting a property to have only a single setter will end up creating unnecessary restrictions for something that is already native to the language.
 You're absolutely right that properties need to be able to return an rvalue 
 from an assignment, but I see no reason why that can't or shouldn't be 
 transparent to the person writing the property.

They could, no problem.
 I'm still not 100% convinced that we should be using properties to do type 
 conversions, although I suppose it may have some legitimate uses...

It is not just about type conversions... it is that the feature is already something natural for the language.
 But anyway, even with the possibility of a property handling multiple types, 
 I still don't think it means we can't or shouldn't have a nicely trimmed 
 syntax for the more typical cases:
 
 property int x
 {
     set { this = this.new; }
     get { return this; }
 
     set char[] { this = StringToInt(this.new); }
     get char[] { return IntToString(this); } // If we ever got 
 overload-on-return-value
 }

Not for getters, please... the type of the getter should be the type of the property, or that would create a lot of complexity for the language (that is also the reason you don't overload functions based on the return type).
Jan 08 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Miles" <_______ _______.____> wrote in message 
news:gk6f9p$1jve$1 digitalmars.com...
 Nick Sabalausky wrote:
 True, but my main point was, however the language ends up handling the
 details of property getters/setters, it's not going to be as general as
 ordinary functions, and thus certain aspects of the syntax can/should be
 simplified.

In this case, simplifying would be more complex. Under the hood, when you define getters and setters, you are defining functions, and function overloading is an inherent feature of the language. In fact, the current "property" feature of D already supports many overloaded setters for different types, since they are just normal functions. For example, consider the property definition: public property int width { get() { return width; } set(int value) { width = value; } set(float value) { width = value + 0.5; } } That would generate overloaded functions with different signatures, lets say that, under the hood, the compiler generates: int __get_width(); int __set_width(int value); int __set_width(float value); Then, when code that accesses the property is compiled, something that looks like width = x; will, in fact, be threated as __set_width(x); and so, the compiler will choose the appropriate __set_width() function with the signature that matches the above call. So, restricting a property to have only a single setter will end up creating unnecessary restrictions for something that is already native to the language.
 You're absolutely right that properties need to be able to return an 
 rvalue
 from an assignment, but I see no reason why that can't or shouldn't be
 transparent to the person writing the property.

They could, no problem.
 I'm still not 100% convinced that we should be using properties to do 
 type
 conversions, although I suppose it may have some legitimate uses...

It is not just about type conversions... it is that the feature is already something natural for the language.

Ok, you've convinced me on this.
 But anyway, even with the possibility of a property handling multiple 
 types,
 I still don't think it means we can't or shouldn't have a nicely trimmed
 syntax for the more typical cases:

 property int x
 {
     set { this = this.new; }
     get { return this; }

     set char[] { this = StringToInt(this.new); }
     get char[] { return IntToString(this); } // If we ever got
 overload-on-return-value
 }

Not for getters, please... the type of the getter should be the type of the property, or that would create a lot of complexity for the language (that is also the reason you don't overload functions based on the return type).

Well, like I said, *If* we were to get overload-on-return-value. Not that I'm itching for it or anything. I've just seen the idea discussed before and if it hypothetically were to happen, then the above could work as a getter equivilent.
Jan 08 2009
parent reply Miles <_______ _______.____> writes:
Nick Sabalausky wrote:
 Well, like I said, *If* we were to get overload-on-return-value. Not that 
 I'm itching for it or anything. I've just seen the idea discussed before and 
 if it hypothetically were to happen, then the above could work as a getter 
 equivilent.

Ok. But I think such feature would create a mess. For example: int func1() { ... } char[] func1() { ... } void func2(int x) { ... } void func2(char[] x) { ... } func2(func1()); // what is the expected behavior? When you are inferring types, you need somewhere to anchor the compiler decision, either on the sender or on the receiver side.
Jan 09 2009
parent "Nick Sabalausky" <a a.a> writes:
"Miles" <_______ _______.____> wrote in message 
news:gk7fau$f38$1 digitalmars.com...
 Nick Sabalausky wrote:
 Well, like I said, *If* we were to get overload-on-return-value. Not that
 I'm itching for it or anything. I've just seen the idea discussed before 
 and
 if it hypothetically were to happen, then the above could work as a 
 getter
 equivilent.

Ok. But I think such feature would create a mess. For example: int func1() { ... } char[] func1() { ... } void func2(int x) { ... } void func2(char[] x) { ... } func2(func1()); // what is the expected behavior? When you are inferring types, you need somewhere to anchor the compiler decision, either on the sender or on the receiver side.

Like I said, I'm neither advocating nor condemning overload-on-return-value.
Jan 09 2009
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Bill Baxter" <wbaxter gmail.com> wrote in message 
news:mailman.343.1231465331.22690.digitalmars-d puremagic.com...
 On Fri, Jan 9, 2009 at 9:59 AM, Miles <_______ _______.____> wrote:
 Nick Sabalausky wrote:
 A property setter is ALWAYS going to return nothing and

Both the getter and the setter should return an rvalue. Properties exist so that they are interchangeable with real member variables.

Partly, but also properties exist to provide encapsulation of private state. So you gotta be careful when you say they should always return an lvalue.

He said "rvalue", not "lvalue". I actually made that same mistake the first couple times I read it.
Jan 08 2009
prev sibling next sibling parent Miles <_______ _______.____> writes:
Bill Baxter wrote:
 On Fri, Jan 9, 2009 at 9:59 AM, Miles <_______ _______.____> wrote:
 Both the getter and the setter should return an rvalue. Properties exist
 so that they are interchangeable with real member variables.

Partly, but also properties exist to provide encapsulation of private state. So you gotta be careful when you say they should always return an lvalue.

Wait! Read again what I said... getters and setters should return an *rvalue*, not lvalue. Everything else you said was based on the idea that accessors return lvalues, that wasn't what I said... There are some very special conditions where the getter MAY return an lvalue. But nothing else. The setter always returns rvalues. For example, if prop is a common property, defined as: public property int width { get() { return m_width; } set(Point value) { return m_width = value; } } Then the following code: x.width += 5; Should expand to something like (hopefully, optimized as far as possible): { auto tmp = x._get_width(); tmp += 5; x._set_width(tmp); } On the other hand, if the getter is defined to return an lvalue, like (tentative syntax): public property int width { ref get() { return m_width; } set(Point value) { return m_width = value; } } Then the compiler should be able to optimize the same code further: x._get_width() += 5; The same for member function calls if the property type is a structure or class.
Jan 08 2009
prev sibling parent reply Chad J <gamerchad __spam.is.bad__gmail.com> writes:
Miles wrote:
 
 Both the getter and the setter should return an rvalue. Properties exist
 so that they are interchangeable with real member variables. Something
 that is possible with member variables MUST also be possible with
 properties, in a transparent way for any code outside the class.
 

I agree, though let's not fool ourselves, there is at least one corner case: property int foo { get{ ... } set{ ... } } auto bar = &foo; what happens when someone writes this? I've tried this in C# and it is simply forbidden. I am OK with this, though I'd love it if there was a better way.
Jan 08 2009
next sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
Chad J wrote:
 Miles wrote:
 Both the getter and the setter should return an rvalue. Properties exist
 so that they are interchangeable with real member variables. Something
 that is possible with member variables MUST also be possible with
 properties, in a transparent way for any code outside the class.

I agree, though let's not fool ourselves, there is at least one corner case: property int foo { get{ ... } set{ ... } } auto bar =&foo; what happens when someone writes this? I've tried this in C# and it is simply forbidden. I am OK with this, though I'd love it if there was a better way.

that's solvable. as I noted in a previous post, a property seems to me to be mainly syntax sugar for a struct like in the following snippet: class A { struct Prop { int internal; int opCall() { return internal; } void opAssign(int value) { internal = value; } } public Prop prop; ... } void main() { auto a = new A; int num = a.prop; a.prop = 9; auto foo = &a.prop; // what happens here? ... } foo can be the address of "prop" (struct instance) in the above code. this means that: *foo = ...; is translated to *foo.opAssign(...); and similarly: auto bar = *foo; will be auto bar = *foo.opCall(); the only issue here is what will be the type of foo if D provides the syntax sugar for all this. maybe define such types as special property types - for a given property "foo" in class "Bar" the type of the property will be "Bar.__fooPropertyType".
Jan 09 2009
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-01-09 05:47:26 -0500, Yigal Chripun <yigal100 gmail.com> said:

 that's solvable. as I noted in a previous post, a property seems to me 
 to be mainly syntax sugar for a struct like in the following snippet:
 
 class A {
 	struct Prop {
 		int internal;
 		int opCall() { return internal; }
 		void opAssign(int value) { internal = value; }
 	}
 	public Prop prop;
 	...
 }

Hum, that doesn't really work. Getter and setters of the property have access to the whole class scope, and can call functions of that class. If you wanted to extract a property from a class, you'd have to do it by keeping a pointer to the class, not the property's value: class A { private int internal; struct Prop { A outerClass; int opCall() { return outerClass.internal; } void opAssign(int value) { outerClass.internal = value; } } public Prop prop; } -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 09 2009
parent Yigal Chripun <yigal100 gmail.com> writes:
Michel Fortin wrote:
 On 2009-01-09 05:47:26 -0500, Yigal Chripun <yigal100 gmail.com> said:

 that's solvable. as I noted in a previous post, a property seems to me
 to be mainly syntax sugar for a struct like in the following snippet:

 class A {
 struct Prop {
 int internal;
 int opCall() { return internal; }
 void opAssign(int value) { internal = value; }
 }
 public Prop prop;
 ...
 }

Hum, that doesn't really work. Getter and setters of the property have access to the whole class scope, and can call functions of that class. If you wanted to extract a property from a class, you'd have to do it by keeping a pointer to the class, not the property's value: class A { private int internal; struct Prop { A outerClass; int opCall() { return outerClass.internal; } void opAssign(int value) { outerClass.internal = value; } } public Prop prop; }

instead of manually doing it within the struct just do s/struct/class to my code. this will solve it since inner classes have an "outer" pointer to the containing class instance. I wasn't trying to give the best and most general solution, just to point out that there is a straight forward solution to this.
Jan 09 2009
prev sibling parent Miles <_______ _______.____> writes:
Chad J wrote:
 I agree, though let's not fool ourselves, there is at least one corner case:
 
 property int foo
 {
     get{ ... }
     set{ ... }
 }
 
 auto bar = &foo;
 what happens when someone writes this?

Yes, this is a corner case. If the getter is not set to return an lvalue, that makes as much sense as trying to get a reference from an rvalue, like &5.
 I've tried this in C# and it is simply forbidden.  I am OK with this,
 though I'd love it if there was a better way.

That is expected behavior. Although able to emulate variables, properties are not variables, and neither functions. They could be seen as a collection of delegates. In some cases, the compiler may allow you to retrieve individual delegates from the property through some syntax, like: auto bar = & property(foo).get;
Jan 09 2009
prev sibling next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Michiel Helvensteijn wrote:
 [Condensed: syntax sucks, let's introduce more!]

I might be old fashioned (get offa mah lawn!), but I've always found something like the following quite acceptable: class Foo { mixin(properties (" rw int bar; ro float baz; wo Foo zyzzy; ")); } I know I had a CTFE function lying around that would parse that and generate the code for it. I agree that C# has a nicer syntax for this, but with CTFE/templates and string mixins, we can have whatever syntax we damn well want. Hell, I used this in a prototype game engine to generate CVars; it'd generate the properties, the backing store, the hooking code, event registration, etc. One line generated about 10-20 lines of boilerplate for me; C# can't do that! Why change the language when you can just abuse it's already-existing features? :D -- Daniel "downs is my hero"
Jan 09 2009
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Daniel Keep (daniel.keep.lists gmail.com)'s article
 Why change the language when you can just abuse it's already-existing
 features? :D
    -- Daniel "downs is my hero"

This is precisely the attitude that left C++ with all of the cruft and baggage it has. Yes, if something can be implemented *elegantly, efficiently, and with clean syntax* in a library, then it doesn't belong in the core language. Yes, powerful language features like templates, mixins, operator overloading, etc. are great for abusing when you need something that's not universal enough to be in the core language. The flip side is that, the more you rely on libraries (whether your personal snippet library or an "official" library) that use hacks like this, the more you're building a house of cards. When you build hacks on top of other hacks, and build these on top of still more hacks (think STL), you're basically asking ugly syntax, odd corner cases, and the exposure of obscure implementation bugs. This is why things like arrays, strings and delegates belong in the core language. Since properties are just as universal, I believe the same argument can be made for them.
Jan 09 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
dsimcha wrote:
 == Quote from Daniel Keep (daniel.keep.lists gmail.com)'s article
 Why change the language when you can just abuse it's already-existing
 features? :D
    -- Daniel "downs is my hero"

This is precisely the attitude that left C++ with all of the cruft and baggage it has. Yes, if something can be implemented *elegantly, efficiently, and with clean syntax* in a library, then it doesn't belong in the core language. Yes, powerful language features like templates, mixins, operator overloading, etc. are great for abusing when you need something that's not universal enough to be in the core language.

Well I'm not so sure about that. In fact I'd go as far as saying you're contradicting yourself. The cruft and baggage is exactly left by unsuccessful language features that had to stay because, well, they were IN the language. For a good while, C++ has been rather liberal in adopting new and risky language features (exceptions, multiple inheritance, templates...) In contrast, for most of its existence, C++ has had an extremely thin library. An example of a bad library from the old days is iostreams, but hardly anyone considers that a major issue. It's not cruft and it's not baggage. It just sucks. :o) So your own logic inexorably leads to a conclusion opposite to your hypothesis: it's best to keep the language lean and keep one's options open, lest cruft and baggage will accumulate. Of course that, taken to an extreme, can lead to contortions and can do more harm than good. So moderation is likely the best way to go.
 The flip side is that, the more you rely on libraries (whether your personal
 snippet library or an "official" library) that use hacks like this, the more
 you're building a house of cards.

That's a bit odd. Are you saying that libraries are inherently less reliable than language features?
 When you build hacks on top of other hacks, and
 build these on top of still more hacks (think STL), you're basically asking
ugly
 syntax, odd corner cases, and the exposure of obscure implementation bugs. 
This
 is why things like arrays, strings and delegates belong in the core language.
 Since properties are just as universal, I believe the same argument can be made
 for them.

When I "think STL" I'm thinking of the best-defined library of general containers and algorithms. No other library I know goes to a longer length at defining its own behavior. Knowing STL makes me look with a rather critical eye at the loosely-defined libraries that accomplish (often sloppily) similar tasks usually featured with other languages. Andrei
Jan 09 2009
parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)
 Well I'm not so sure about that. In fact I'd go as far as saying you're
 contradicting yourself. The cruft and baggage is exactly left by
 unsuccessful language features that had to stay because, well, they were
 IN the language. For a good while, C++ has been rather liberal in
 adopting new and risky language features (exceptions, multiple
 inheritance, templates...) In contrast, for most of its existence, C++
 has had an extremely thin library. An example of a bad library from the
 old days is iostreams, but hardly anyone considers that a major issue.
 It's not cruft and it's not baggage. It just sucks. :o)
 So your own logic inexorably leads to a conclusion opposite to your
 hypothesis: it's best to keep the language lean and keep one's options
 open, lest cruft and baggage will accumulate.
 Of course that, taken to an extreme, can lead to contortions and can do
 more harm than good. So moderation is likely the best way to go.

I will admit that cruft and baggage were probably poor word choices to describe what I meant. I really meant things like odd syntax and weird corner cases caused by not having the core language know about very basic, frequently used things like arrays and strings.
 The flip side is that, the more you rely on libraries (whether your personal
 snippet library or an "official" library) that use hacks like this, the more
 you're building a house of cards.

reliable than language features?

In a way, yes. When building a feature into a language, you can do literally *anything* that is computationally feasible, such as define new syntax, make the compiler "know" about the feature at a high level, display good high-level error messages, etc. When you're defining something in a library, you're limited by existing constructs. Sometimes those existing constructs are enough to do what you want cleanly and elegantly. Sometimes (as in the OP's example) you have to resort to hacks. My point is that, when you have a low-level library feature A that's kind of a hack and does strange things in certain edge/error/unanticipated cases, and then you build a high-level library feature B on top of A using still more hacks, what are the odds that if something goes wrong with B, anyone will have any clue why? What are the odds that B won't have some frustrating, arbitrary limitations?
 When you build hacks on top of other hacks, and
 build these on top of still more hacks (think STL), you're basically asking
ugly
 syntax, odd corner cases, and the exposure of obscure implementation bugs. 
This
 is why things like arrays, strings and delegates belong in the core language.
 Since properties are just as universal, I believe the same argument can be made
 for them.

containers and algorithms. No other library I know goes to a longer length at defining its own behavior. Knowing STL makes me look with a rather critical eye at the loosely-defined libraries that accomplish (often sloppily) similar tasks usually featured with other languages. Andrei

Yes, STL (and Boost, etc.) are very high-quality libraries. The problem is that, because the core language doesn't "understand" anything in them, there's no shortage of things like clumsy syntax, inscrutible error messages for the tiniest errors, etc. This is not to say that all, or even most, of STL or Boost belong in the core C++ language, just the features that are both heavily used and would benefit greatly from the core language "understanding" them.
Jan 09 2009
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel Keep" <daniel.keep.lists gmail.com> wrote in message 
news:gk7nij$rlo$1 digitalmars.com...
 Michiel Helvensteijn wrote:
 [Condensed: syntax sucks, let's introduce more!]

I might be old fashioned (get offa mah lawn!), but I've always found something like the following quite acceptable: class Foo { mixin(properties (" rw int bar; ro float baz; wo Foo zyzzy; ")); } I know I had a CTFE function lying around that would parse that and generate the code for it. I agree that C# has a nicer syntax for this, but with CTFE/templates and string mixins, we can have whatever syntax we damn well want. Hell, I used this in a prototype game engine to generate CVars; it'd generate the properties, the backing store, the hooking code, event registration, etc. One line generated about 10-20 lines of boilerplate for me; C# can't do that! Why change the language when you can just abuse it's already-existing features? :D -- Daniel "downs is my hero"

String mixins are very powerful, and certainly welcome IMO, but they involve dynamically generating code by algorithmically splicing together little text snippets, and that's just very hack-ish. It's literally just like using classic-style ASP or PHP. That was too clumbsy even for the already-clumbsiness-embracing world of the web; that's why they're moving towards proper page-templating engines. I see the role of string mixins as being a handy way to hack together a piece of advanced functionality until a better more proper way comes along.
Jan 09 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Nick Sabalausky wrote:
 String mixins are very powerful, and certainly welcome IMO, but they involve 
 dynamically generating code by algorithmically splicing together little text 
 snippets, and that's just very hack-ish. It's literally just like using 
 classic-style ASP or PHP. That was too clumbsy even for the 
 already-clumbsiness-embracing world of the web; that's why they're moving 
 towards proper page-templating engines. I see the role of string mixins as 
 being a handy way to hack together a piece of advanced functionality until a 
 better more proper way comes along. 

I think the comparison is a bit loose; the problem with ASP and PHP was the way most people mixed processing logic and display. Here, there's a relatively clean separation. Yes, a language-level construct for this would be nice, but where do you draw the line? Personally, I'm a big believer in generic constructs. Let's pretend for a moment that we've got AST macros, and can specify that our macro uses { } instead of ( )... properties { rw int foo; ro float bar; } That might as well be a language construct! And D isn't as bad as C/C++ when it comes to inscrutible error messages; we at least have pragma(msg), although I admit it would be nice to have more control over where the compiler says an error comes from, and what the code responsible is. At the end of the day, my job is to make a computer do stuff. If string mixins help me reach that goal quicker [1], then I'm all for it. -- Daniel [1] Obviously, I don't mean "at all costs;" something like: mixin(/* a long, complex expression that produces a string */); is pretty obviously a bad idea for exactly the reasons you gave above. Something like: mixin(hhfk("kjiq9238*)&70394{")); is also a bad idea, for rather obvious reasons.
Jan 09 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel Keep" <daniel.keep.lists gmail.com> wrote in message 
news:gk8j4h$29fm$1 digitalmars.com...
 Nick Sabalausky wrote:
 String mixins are very powerful, and certainly welcome IMO, but they 
 involve dynamically generating code by algorithmically splicing together 
 little text snippets, and that's just very hack-ish. It's literally just 
 like using classic-style ASP or PHP. That was too clumbsy even for the 
 already-clumbsiness-embracing world of the web; that's why they're moving 
 towards proper page-templating engines. I see the role of string mixins 
 as being a handy way to hack together a piece of advanced functionality 
 until a better more proper way comes along.

I think the comparison is a bit loose; the problem with ASP and PHP was the way most people mixed processing logic and display. Here, there's a relatively clean separation.

It's not so much an issue of logic vs display (if you're using a somewhat literal definition of "display"), as it is an issue of proper ways to dynamically generate code regardless of whether the generated output is a "display" description or a description of yet more logic (ex, generating client-side JavaScript using classic ASP/PHP techniques is still rightly considered just as bad as if HTML were being generated). With that in mind, how do D string mixins have more logic/output separation than typical ASP or PHP? The actual implementation of the string-generating function (or template) still mixes logic with output. Suppose you wanted to make a mixin that generated a bunch of int declarations from a list of names. How would you implement that? With current D, it would have to be something like this: / / Pseudocode declareStuff(string[] names) // template or CTFE { // Template-style would be mostly the same, // but maybe slightly more functional than imperative. string str; foreach(name; names) str ~= "int "~name~";\n"; // \n helps with debugging return str; } Now compare that to a fairly typical method for generating a list in classic-ASP/PHP: / / Pseudocode generateList(string[] listElements) { string str= "<ul>"; foreach(elem; listElements) str ~= "<li>"~elem~"</li>\n"; return str~"</ul>"; } It's practically the same code, except that the web development world has been discovering that's in a bad style that leads to problems. Although, maybe string mixins could make use of proper logic/output separation if we had better CTFE. Then we could use something like ANTLR's StringTemplate lib. But maybe that would lead to unnecessarily long compile times? In any case, whenever I see "mixin(...);", even in my own code, I always think "hack". That's fine for obscure special-domain tools, but for something as common and as general as properties, it just comes across as a big kludge.
 Yes, a language-level construct for this would be nice, but where do you 
 draw the line?

IMO, Somewhere beyond "property syntax" ;-)
 Personally, I'm a big believer in generic constructs.  Let's pretend for a 
 moment that we've got AST macros, and can specify that our macro uses { } 
 instead of ( )...

 properties
 {
     rw int foo;
     ro float bar;
 }

If we had AST macros, and creating them was significantly cleaner than creating string mixins, then that would certainly reduce the need for language-level things like properties. However, I would still very much insist that something as common as properties would, at the very least, be part of the standard library. It wouldn't be good for the language to have twenty different custom property-syntax libs floating around.
Jan 09 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Nick Sabalausky:
 In any case, whenever I see "mixin(...);", even in my own code, I always 
 think "hack". That's fine for obscure special-domain tools, but for 
 something as common and as general as properties, it just comes across as a 
 big kludge.

I agree. String mixin are generally near-unreadable, and I hate to debug them. So it's better to use them as little as possible. If many D programs show a very common pattern (like certain usages of properties) it becomes a candidate to be included into the compiler and not done with string mixings anymore. (This also means you can see string mixings as feature laboratories: that is tests of features that may be added to future versions of the language. Just like plugins in Firefox). Bye, bearophile
Jan 09 2009
prev sibling parent reply =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel Keep wrote:
 
 
 Michiel Helvensteijn wrote:
 [Condensed: syntax sucks, let's introduce more!]

I might be old fashioned (get offa mah lawn!), but I've always found something like the following quite acceptable: class Foo { mixin(properties (" rw int bar; ro float baz; wo Foo zyzzy; ")); }

properties isn't just a question of access control (read/write, read only, or write only). It is also a way to execute arbitrary code each time the value is changed (or accessed), or to create properties that don't correspond to actual data fields (complex module and argument come to mind). How would you do that with mixins? (Not that it would be impossible, but the syntax would probably be horrible). Jerome - -- mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAklocvAACgkQd0kWM4JG3k8NCwCgm0+e/mOg3pfhpaqlnCGad/tA v2UAmwXZjHfyeGdLk5C2FthJxOW+924r =RNrq -----END PGP SIGNATURE-----
Jan 10 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
JÚr˘me M. Berger wrote:
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 Daniel Keep wrote:
 Michiel Helvensteijn wrote:
 [Condensed: syntax sucks, let's introduce more!]

something like the following quite acceptable: class Foo { mixin(properties (" rw int bar; ro float baz; wo Foo zyzzy; ")); }

properties isn't just a question of access control (read/write, read only, or write only).

For me, it *was* a case of access-control... at least, it was about 80% of the time. I'm a fan of interface-heavy design: make an interface for every distinct kind of functionality and pack them all together. That means I end up with a metric buttload (equivalent to about 42 imperial piles) of properties. And most of them were just accessors that needed to be in the interface; hence the functionality of the mixin.
 It is also a way to execute arbitrary code
 each time the value is changed (or accessed), ...

It's been a while since I used the code, and honestly I can't seem to track it down, but I recall that I could do this: mixin(properties(" rw int bar; ")); protected void bar_onSet(int newValue) { ... } There was also an *_onGet, and you could block setting a property by throwing an exception, I believe. Granted, this doesn't cover every possible use-case, but then it's not supposed to; it's supposed to make the 90% easier. It still did the assignment, since I felt you shouldn't be making properties that have a setter that doesn't set anything...
 ... or to create
 properties that don't correspond to actual data fields (complex
 module and argument come to mind).

If the property doesn't correspond to a physical field, then you're going to have to write the code to handle it from scratch. And no matter WHAT you do, it's eventually going to boil down to one or more functions. Which is EXACTLY how they currently work. What would be the point of making a special syntax when you can already do that? :P
 How would you do that with
 mixins? (Not that it would be impossible, but the syntax would
 probably be horrible).
 
 		Jerome

On a somewhat related note, I've often pondered writing a very limited D parser in CTFE to do this sort of thing more easily, but never got around to it, nevermind the CTFE memory bugs... -- Daniel
Jan 10 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel Keep" <daniel.keep.lists gmail.com> wrote in message 
news:gk9v33$1bvu$1 digitalmars.com...
 JÚr˘me M. Berger wrote:
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1

 Daniel Keep wrote:
 Michiel Helvensteijn wrote:
 [Condensed: syntax sucks, let's introduce more!]

something like the following quite acceptable: class Foo { mixin(properties (" rw int bar; ro float baz; wo Foo zyzzy; ")); }

properties isn't just a question of access control (read/write, read only, or write only).

For me, it *was* a case of access-control... at least, it was about 80% of the time. I'm a fan of interface-heavy design: make an interface for every distinct kind of functionality and pack them all together. That means I end up with a metric buttload (equivalent to about 42 imperial piles) of properties. And most of them were just accessors that needed to be in the interface; hence the functionality of the mixin.
 It is also a way to execute arbitrary code
 each time the value is changed (or accessed), ...

It's been a while since I used the code, and honestly I can't seem to track it down, but I recall that I could do this: mixin(properties(" rw int bar; ")); protected void bar_onSet(int newValue) { ... } There was also an *_onGet, and you could block setting a property by throwing an exception, I believe. Granted, this doesn't cover every possible use-case, but then it's not supposed to; it's supposed to make the 90% easier. It still did the assignment, since I felt you shouldn't be making properties that have a setter that doesn't set anything...
 ... or to create
 properties that don't correspond to actual data fields (complex
 module and argument come to mind).

If the property doesn't correspond to a physical field, then you're going to have to write the code to handle it from scratch. And no matter WHAT you do, it's eventually going to boil down to one or more functions. Which is EXACTLY how they currently work. What would be the point of making a special syntax when you can already do that? :P

Same reason we have "while" and "foreach" in addition to "for".
 How would you do that with
 mixins? (Not that it would be impossible, but the syntax would
 probably be horrible).

 Jerome

On a somewhat related note, I've often pondered writing a very limited D parser in CTFE to do this sort of thing more easily, but never got around to it, nevermind the CTFE memory bugs... -- Daniel

Jan 10 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Nick Sabalausky wrote:
 "Daniel Keep" <daniel.keep.lists gmail.com> wrote in message 
 news:gk9v33$1bvu$1 digitalmars.com...
 [snip]
 
 What would be the point of making a special syntax when you can already do 
 that? :P

Same reason we have "while" and "foreach" in addition to "for".

How is this: property int foo { get { return compute_value(); } } Appreciably better than this: int foo() { return compute_value(); } We have for and foreach because iteration is a *very* common use for a loop, and you can screw it up when using while. In this case, having property syntax for a computed field doesn't buy you anything whatsoever apart from more typing. Yes, property syntax can simplify some cases, but this isn't one of them. -- Daniel P.S. Please don't get my hopes up by quoting my entire post and then only replying to one line; I thought I'd get to argue about my "80%" if nothing else. :P
Jan 10 2009
next sibling parent reply Miles <_______ _______.____> writes:
Daniel Keep wrote:
 Yes, property syntax can simplify some cases, but this isn't one of them.

One good distinction properties and normal functions ought to make is that functions should never be called without (), and properties should never have () unless it has a function type. Current syntax allows crazy things like: ---------- exit = 1; // it is not an assignment x = toString = getenv = "PATH"; // creepy, but valid D if (fork == 1) // not comparing the value of a variable ---------- Also, currently, in D, if you have a property of a delegate type, you will have a mess. ---------- int func2() { return 42; } /* this is a property */ int function() prop() { return &func2; } void main() { auto x = prop; // ok, x is a func ptr auto y = prop(); // unexpected: y is not int :-( static assert (is(typeof(y) == int)); } ---------- With properties, you forbid the above syntaxes. So, what is "better" about properties is not shorter syntax, but giving proper semantics for a given symbol. Also, properties can be part of interfaces, enforcing derived classes to implement them in a given way.
Jan 10 2009
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Miles (_______ _______.____)'s article
 Daniel Keep wrote:
 Yes, property syntax can simplify some cases, but this isn't one of them.

that functions should never be called without ()

Why? This is really superfluous. I for one think that code is often more readable without the annoying empty parentheses around functions that don't take any arguments. This is especially true for member functions of classes and structs, even moreso when chaining them such as foo.bar.baz vs. foo().bar().baz().
 , and properties should
 never have () unless it has a function type.
 Current syntax allows crazy things like:
 ----------
 	exit = 1;	// it is not an assignment
 	x = toString = getenv = "PATH";	// creepy, but valid D
 	if (fork == 1)	// not comparing the value of a variable
 ----------

So? The spec is not there to prevent people from doing stupid things (making it harder to do stupid things *by accident* is a reasonable goal, but we're all consenting adults here). Anyone who would actually do stuff like this on purpose in their code is an idiot and deserves what they get. One could just as easily do some pretty stupid things with operator overloading, casts, templates, you name it. Just because stupid things *can* be done with a feature doesn't mean the feature should be removed.
 Also, currently, in D, if you have a property of a delegate type, you
 will have a mess.
 ----------
 	int func2() { return 42; }
 	/* this is a property */
 	int function() prop() {
 		return &func2;
 	}
 	void main() {
 		auto x = prop;		// ok, x is a func ptr
 		auto y = prop();	// unexpected: y is not int :-(
 		static assert (is(typeof(y) == int));
 	}
 ----------
 With properties, you forbid the above syntaxes.
 So, what is "better" about properties is not shorter syntax, but giving
 proper semantics for a given symbol.

Jan 10 2009
parent reply Miles <_______ _______.____> writes:
dsimcha wrote:
  I for one think that code is often more
 readable without the annoying empty parentheses around functions that don't
take
 any arguments.

It introduces ambiguities, and unexpected behavior, as I exemplified in the previous message. Parentheses (when following an identifier) has a precise meaning of calling the named function. That is something most modern procedural languages do, it is something programmers are used to. I see no advantage at giving the privilege to no-argument functions of being called without parentheses, while at the same time you lose the ability to distinguish between _calling_ the function from _referring_ to it.
 This is especially true for member functions of classes and
 structs,

Aren't these member functions good candidates to be made into real properties? If you want or need to use an identifier without parentheses, you have the option of making it into a property. Very simple.
 even moreso when chaining them such as foo.bar.baz vs. foo().bar().baz().

From your example, it appears that the purpose of foo and bar, and perhaps baz are to return instances, so they could just be turned into properties, and have the exact syntax you expect.
 So?  The spec is not there to prevent people from doing stupid things (making
it
 harder to do stupid things *by accident* is a reasonable goal, but we're all
 consenting adults here).  Anyone who would actually do stuff like this on
purpose
 in their code is an idiot and deserves what they get.  One could just as
easily do
 some pretty stupid things with operator overloading, casts, templates, you name
 it.  Just because stupid things *can* be done with a feature doesn't mean the
 feature should be removed.

You seem to be missing the point. In fact, you ignored the most important example in my previous message that shows how the current D's property syntax can be damaging. Also, your reasoning fails to take into account the difference between _allowing_ a certain syntax, and _incentivating_ bad usage.
Jan 10 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Bill Baxter" <wbaxter gmail.com> wrote in message 
news:mailman.378.1231643869.22690.digitalmars-d puremagic.com...
 On Sun, Jan 11, 2009 at 12:01 PM, Miles <_______ _______.____> wrote:
 dsimcha wrote:
  I for one think that code is often more
 readable without the annoying empty parentheses around functions that 
 don't take
 any arguments.

It introduces ambiguities, and unexpected behavior, as I exemplified in the previous message. Parentheses (when following an identifier) has a precise meaning of calling the named function. That is something most modern procedural languages do, it is something programmers are used to. I see no advantage at giving the privilege to no-argument functions of being called without parentheses, while at the same time you lose the ability to distinguish between _calling_ the function from _referring_ to it.

Not sure what you mean by that. It's just foo vs &foo in most cases. ...Except for some cases like where you're trying to return a delegate.

I'd consider those situations with delegates to be reason enough.
 I agree that 'except for' is not very pleasant.

 This is especially true for member functions of classes and
 structs,

Aren't these member functions good candidates to be made into real properties? If you want or need to use an identifier without parentheses, you have the option of making it into a property. Very simple.

He may want to retain the ability to pass it as a delegate to some other function too.

takesADelegate({ return foo.aProperty; }); takesADelegate((int newValue) { foo.aProperty = newValue }); Works with both variables and properties. Which is good, because the whole point of properties is to be used just like a variable. If you ever feel a need to use the property's actual setter or getter as a delegate, then something's been designed wrong. Also: void func(ref int x) {...} func(foo.aProperty); void func(int* x) {...} func(&foo.aProperty); *Should* work with both variables and properties (but might need some thinking in how to actually pull it off correctly. Someone mentioned C# just doesn't even bother with it.)
Jan 10 2009
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Nick Sabalausky wrote:
 void func(ref int x) {...}
 func(foo.aProperty);
 
 void func(int* x) {...}
 func(&foo.aProperty);
 
 *Should* work with both variables and properties (but might need some 
 thinking in how to actually pull it off correctly. Someone mentioned C# just 
 doesn't even bother with it.)

That just can't work without radically changing what a pointer is. Disallowing pointers to properties is really the best fix. If you really wanted, you might be able to wrap a getter/setter pair into a struct and pass that instead (and have default getter/setter templates for non-properties). It's probably easier to just pass in getter/setter delegates explicitly though.
Jan 12 2009
parent "Nick Sabalausky" <a a.a> writes:
"Frits van Bommel" <fvbommel REMwOVExCAPSs.nl> wrote in message 
news:gkfmr2$1n9j$1 digitalmars.com...
 Nick Sabalausky wrote:
 void func(ref int x) {...}
 func(foo.aProperty);

 void func(int* x) {...}
 func(&foo.aProperty);

 *Should* work with both variables and properties (but might need some 
 thinking in how to actually pull it off correctly. Someone mentioned C# 
 just doesn't even bother with it.)

That just can't work without radically changing what a pointer is. Disallowing pointers to properties is really the best fix. If you really wanted, you might be able to wrap a getter/setter pair into a struct and pass that instead (and have default getter/setter templates for non-properties). It's probably easier to just pass in getter/setter delegates explicitly though.

What if properties were internally defined to be a struct of two delegates (and maybe the internal value)? Although that would still leave an issue of compatibility between int* and (property int)*, and might prevent the intrnal value from being optimized away...
Jan 12 2009
prev sibling parent reply Miles <_______ _______.____> writes:
Bill Baxter wrote:
 Not sure what you mean by that.  It's just  foo vs &foo in most cases.
 ...Except for some cases like where you're trying to return a delegate.

It is more tied with the intuitive use of symbols. 'foo' is a function, add a '&' before and you take its address, add a '(...)' after and you make a call and take its return value. The implicit call syntax without parentheses breaks this intuitive use. In fact, if you follow the principle of orthogonality, instead of calling the function without parameters, it would be much more sensible to have 'foo' return the function address, and deprecate the address operator. Then you could have functions and function/delegate pointers with similar semantics (principle of least surprise). --------- int func1() { return 1; } auto a = func1; // 'a' is a pointer to func1 auto b = &func1; // ERROR, or deprecated way of above auto c = func1(); // calls func1 and returns int 1 int function() func2 = func1; auto d = func2; // 'd' is a pointer to func1 auto e = &func2; // 'e' is a ptr to ptr to func auto f = func2(); // calls func1 and returns int 1 --------- Note that this way you have less surprises. Both func1 (the real function) and func2 (pointer to function) behave in similar ways. In current D, 'a' will be different than 'd', while 'c' will be equal to 'f'. The reasoning for deprecating &func1 is that func1 is not a variable, neither it is an lvalue. But now it is quite already too late to fix this, unless we go through a long period of deprecating the current behavior, until we can implement the new sane one.
 He may want to retain the ability to pass it as a delegate to some
 other function too.  If you make properties distinct from functions,
 then I don't think this can be allowed.

Yes, they are basically two distinct, mutually exclusive, compromises. A property is syntax sugar to a collection of delegates (all of them share the same scope). Properties are "views" that aim to behave as much as possible as variables. Optimally, you must ignore completely if a given symbol is a property or a variable. So, it makes little sense to pass a property as a delegate to a function. But it is still possible, and the solution actually keeps the fundamental property that variables and properties should be almost indistinguishable: ---------- int m_prop; property int prop { get() { return m_prop } set(int value) { m_prop = value; } } // lets say that func expects a setter func1( (int value){ prop = value; } ); // and func2 expects a getter func2( (){ return prop; } ); ---------- See? You passed delegates to the functions, and you kept the compromise that the code doesn't make distinction between properties and variables. The following code (taking the property out) is still valid: ---------- int prop; func1( (int value){ prop = value; } ); func2( (){ return prop; } ); ----------
 So you'd need to have the
 property and a function that wraps the property.

Exactly, or, instead of a function, an inline delegate is enough. As shown above, you win because then the code becomes insensitive to whether prop is a property or a variable.
 Then you've just made more work for yourself.

This is such a corner case that I think that using inline delegates is a good enough solution.
    Hmm, maybe properties should be
 allowed to be turned into delegates.

The compiler could provide a syntax for that. Like I said, a property is just a collection of delegates under a single identifier. For example, tentative syntax: ---------- property int prop { ... } auto setter = property(prop).set; // setter has type 'void delegate(int)' auto getter = property(prop).get; // getter has type 'int delegate()' ---------- But I think this is a secondary feature (if we keep demanding solutions for the corner cases, we will never have the solution for the biggest problem). I could live fine without this feature.
Jan 11 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Miles:
 In fact, if you follow the principle of orthogonality, instead of
 calling the function without parameters, it would be much more sensible
 to have 'foo' return the function address, and deprecate the address
 operator. Then you could have functions and function/delegate pointers
 with similar semantics (principle of least surprise).

I agree.
 But now it is quite already too late to fix this, unless we go through a
 long period of deprecating the current behavior, until we can implement
 the new sane one.

Seeing how much experimental D2 is, I think there's time to fix design bugs still. Bye, bearophile
Jan 11 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:gkd3b0$fkb$1 digitalmars.com...
 Miles:
 In fact, if you follow the principle of orthogonality, instead of
 calling the function without parameters, it would be much more sensible
 to have 'foo' return the function address, and deprecate the address
 operator. Then you could have functions and function/delegate pointers
 with similar semantics (principle of least surprise).

I agree.
 But now it is quite already too late to fix this, unless we go through a
 long period of deprecating the current behavior, until we can implement
 the new sane one.

Seeing how much experimental D2 is, I think there's time to fix design bugs still.

Even if it weren't for that, I would still consider this important enough to be worth the hassle of changing it. It would be better than letting D forever maintain the cruft of a particularly bad design decision (no offense, Walter) in the same way that C++ would.
Jan 11 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Nick Sabalausky:
 Even if it weren't for that, I would still consider this important enough to 
 be worth the hassle of changing it. It would be better than letting D 
 forever maintain the cruft of a particularly bad design decision (no 
 offense, Walter) in the same way that C++ would.

But I am not sure that proposed idea is the best, because in Python (that acts like that) you often enough write for mistake: x = foo Forgetting the (). In this case x gets a (kind of) reference to foo and not to its result. You can do something similar in that D proposal: auto x = foo So I think &foo and foo() are more explicit and better (better == less error-prone), to represent the pointer/delegate/closure, and to represent the calling. Bye, bearophile
Jan 11 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:gkd53n$ikt$1 digitalmars.com...
 Nick Sabalausky:
 Even if it weren't for that, I would still consider this important enough 
 to
 be worth the hassle of changing it. It would be better than letting D
 forever maintain the cruft of a particularly bad design decision (no
 offense, Walter) in the same way that C++ would.

But I am not sure that proposed idea is the best, because in Python (that acts like that) you often enough write for mistake: x = foo Forgetting the (). In this case x gets a (kind of) reference to foo and not to its result. You can do something similar in that D proposal: auto x = foo So I think &foo and foo() are more explicit and better (better == less error-prone), to represent the pointer/delegate/closure, and to represent the calling.

Yes, but 1. As you indicated, it could only happen in D when using an initializer on an "auto". And 2. I would imagine that would probably get caught as soon x was used. But, if &foo is deemed to be better for referring to the function itself (ie without invoking), then using "foo" without "&" or "()" should be prohibited. (In fact, maybe that would be the ideal solution?)
Jan 11 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Nick Sabalausky:
 Yes, but 1. As you indicated, it could only happen in D when using an 
 initializer on an "auto". And 2. I would imagine that would probably get 
 caught as soon x was used.

You are right, Python being dynamically typed the situation is a little worse there.
 then using "foo" without "&" or "()" should be 
 prohibited. (In fact, maybe that would be the ideal solution?)

That's what I was saying, to disallow "foo" without () or &. It's not the ideal situation but to me it looks better than the current ones (of both Python and D1). Bye, bearophile
Jan 11 2009
parent Sergey Kovrov <kovrov gmail.com> writes:
On 1/11/2009 9:32 PM, Denis Koroskin wrote:
 I'd also note that using foo without either "&" or "()" is still
 necessary to get access to foo's set of properties:

 auto s = foo.stringof;
 auto m = foo.mangleof;
 // etc

As far as I understand calling built-in properties eg. ``foo.stringof()`` is not allowed. And it is not an lvalue. So no referencing of a built-in properties possible either. I find this behavior most suitable for properties. The only exception is built-in ``.reverse`` and ``.sort`` properties which seems counter intuitive to me to be used without (). I think this should be something callable (built-in functions, inherited methods, etc.) rather than properties. -- serg.
Jan 11 2009
prev sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Miles wrote:
 ---------
 	int func1() { return 1; }
 
 	auto a = func1;		// 'a' is a pointer to func1
 	auto b = &func1;	// ERROR, or deprecated way of above
 	auto c = func1();	// calls func1 and returns int 1
 
 	int function() func2 = func1;
 
 	auto d = func2;		// 'd' is a pointer to func1
 	auto e = &func2;	// 'e' is a ptr to ptr to func
 	auto f = func2();	// calls func1 and returns int 1
 ---------

So you consider functions to be a reference type, since the value of a function is not terribly useful. You want the declarations "void foo() {}" and "invariant(void function()) foo = {};" to be equivalent. This can work, provided you get properties. Otherwise you're back to Javaland.
Jan 12 2009
parent Miles <_______ _______.____> writes:
Christopher Wright wrote:
 So you consider functions to be a reference type, since the value of a
 function is not terribly useful. You want the declarations "void foo()
 {}" and "invariant(void function()) foo = {};" to be equivalent.

Yes, almost equivalent.
Jan 13 2009
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Miles wrote:
 Daniel Keep wrote:
 Yes, property syntax can simplify some cases, but this isn't one of them.

One good distinction properties and normal functions ought to make is that functions should never be called without (), and properties should never have () unless it has a function type. Current syntax allows crazy things like: ---------- exit = 1; // it is not an assignment x = toString = getenv = "PATH"; // creepy, but valid D if (fork == 1) // not comparing the value of a variable ----------

Walter and I see eye to eye that a possible solution would be to only allow the a = b syntax as an alternative for a(b) only if there's also a function a(). All of the above can be fixed within that framework.
 Also, currently, in D, if you have a property of a delegate type, you
 will have a mess.
 
 ----------
 	int func2() { return 42; }
 
 	/* this is a property */
 	int function() prop() {
 		return &func2;
 	}
 	
 	void main() {
 		auto x = prop;		// ok, x is a func ptr
 		auto y = prop();	// unexpected: y is not int :-(
 		static assert (is(typeof(y) == int));
 	}
 ----------
 
 With properties, you forbid the above syntaxes.

Well the above syntaxes could be forbidden other ways too. Andrei
Jan 10 2009
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:gkbtpo$1jq0$1 digitalmars.com...
 Miles wrote:
 Daniel Keep wrote:
 Yes, property syntax can simplify some cases, but this isn't one of 
 them.

One good distinction properties and normal functions ought to make is that functions should never be called without (), and properties should never have () unless it has a function type. Current syntax allows crazy things like: ---------- exit = 1; // it is not an assignment x = toString = getenv = "PATH"; // creepy, but valid D if (fork == 1) // not comparing the value of a variable ----------

Walter and I see eye to eye that a possible solution would be to only allow the a = b syntax as an alternative for a(b) only if there's also a function a(). All of the above can be fixed within that framework.

I think that's a big part of the problem though. The current strategy just leads to various fringe cases with their own specialized "solutions". I think we have sufficient reason to consider "implicit properties" a failed experiment.
Jan 10 2009
prev sibling next sibling parent Miles <_______ _______.____> writes:
Andrei Alexandrescu wrote:
 Walter and I see eye to eye that a possible solution would be to only
 allow the a = b syntax as an alternative for a(b) only if there's also a
 function a(). All of the above can be fixed within that framework.

That would only patch a single consequence of the much bigger core problem that is the current property syntax. Not to say that, although rare, it is perfectly possible to have write-only properties. I once wrote a microcontroller emulator that had a few write-only registers, serial port output, for example.
Jan 11 2009
prev sibling parent =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrei Alexandrescu wrote:
 Miles wrote:
 Daniel Keep wrote:
 Yes, property syntax can simplify some cases, but this isn't one of
 them.

One good distinction properties and normal functions ought to make is that functions should never be called without (), and properties should never have () unless it has a function type. Current syntax allows crazy things like: ---------- exit = 1; // it is not an assignment x = toString = getenv = "PATH"; // creepy, but valid D if (fork == 1) // not comparing the value of a variable ----------

Walter and I see eye to eye that a possible solution would be to only allow the a = b syntax as an alternative for a(b) only if there's also a function a(). All of the above can be fixed within that framework.

Jerome - -- mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAklqQ3cACgkQd0kWM4JG3k8TCACdG8B16tlHlJJuv5ct7gegvog3 HuAAmwb/ooNnVrtpkLIh7u/I3uUwpqXK =+nhK -----END PGP SIGNATURE-----
Jan 11 2009
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Miles" <_______ _______.____> wrote in message 
news:gkbk5p$14gr$1 digitalmars.com...
 So, what is "better" about properties is not shorter syntax, but giving
 proper semantics for a given symbol.

I'd say the point of properties is both a matter of clean implementation syntax and proper calling semantics/syntax. In the case of the calling semantics/syntax, I see it as essentially boiling down to an issue of "nouns vs verbs" and proper abstraction. The way I see it: Variables are the programming world's nouns, and functions are the programming world's verbs. Objects (nouns) have attributes (nouns) and are capable of doing things (verbs). Thus, things that are noun-like and can be thought of as an attribute of an object should be accessed using noun/variable syntax (this means no parentheses), and things that are conceptualized as actions the object can perform should be invoked using verb/function syntax (this means parentheses). Although if you're merely *referring* to a verb/function (as in the phrase "the act of walking"), then you're using the verb as a noun and should refer to the verb with the standard noun syntax (no parens). Example of proper design strategy: We want to programmatically represent the noun of "color". First thing we need is a type. There's no built-in, so we need to define a custom type, a class. Next thing we need is a list of attributes and actions associated with "color": Actions (things color can do): Color isn't a physical object so there's not much it can actually do: - Inspire an Artist (Artist being the grammatical "direct object", and therefore the parameter) Attributes (things color has): - Hue - Saturation - Brightness/Darkness - Red component - Green component - Blue component - Yellow component - Cyan component - Magenta component - Transparency/Opaqueness - Shininess - etc... Now to translate into (psuedo)code: void inspire(Artist artist) { /* magic code here */ } val hue; val saturation; val blackness; val red; val green; val blue; val yellow; val cyan; val magenta; val transparency val shininess; ("val", of course, being a type representing the range of "max".."min") Now at this point any sane programmer would see the redundancy (and potential for invalid, self-contradicting state) in storing HSV, RGB, *and* CMYK. They'd then probably choose a single internal format (we'll say RGB), and decide to calculate all of the redundant attributes from that. This is good design. But here's the part where many people go wrong. They say "Since I'm calculating HSVCM and Y, that means 'function'" (And yes, it does mean "function", but only on the *implementation* side.) Then they do something like this: val getHue(); val getSaturation(); val getBlackness(); val red; // Might be changed to getRed() for consistency val green; val blue; val getYellow(); val getCyan(); val getMagenta(); Bad programmer! Bad, bad, bad programmer! Hue and Yellow aren't actions of color, they're attributes! Nouns, nouns, nouns! Turning them into verbs by sticking "get" in front just made a bastardized mockery out of high-level-language abstraction. Not only that but the implementation detail of "some of these are calculated instead of stored internally" has leaked out into the interface and slapped the idea of encapsulation in the face. At this point, D comes in and tries to solve the problem with omittable parens on functions. But that puts the onus on the caller. So what, the caller is now supposed to be defining the interface? That's dumb because the author of the class has already decided whether a particular member is a noun or a verb by naming it "red" instead of "getRed" or vice versa. If you've got something like "red component" that is conceptually understood as a noun, it should be accessed with noun syntax. Call it "good redundancy" (*nudge* *nudge* Walter?). Whether or not the class author decides to *implement* it as a computation or a simple memory access should not impact accessing it. As it is now, whenever a conceptual attribute is switched between variable and "property", the legality of sticking () on the end of it flip-flops. How is that desirable behavior?
Jan 10 2009
next sibling parent Michiel Helvensteijn <nomail please.com> writes:
Nick Sabalausky wrote:

 <Great Example>

Hear, hear! -- Michiel
Jan 11 2009
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:gkbuap$1khp$1 digitalmars.com...
 Objects (nouns) have attributes (nouns) and are capable of doing things 
 (verbs).

That should probably be: Objects (nouns) have attributes (adjectives/nouns) and are capable of doing things (verbs). But, of course, adjectives (just like "direct/indirect objects") are themselves nouns.
Jan 11 2009
next sibling parent reply John Reimer <terminal.node gmail.com> writes:
Hello Nick,

 But, of course, adjectives (just like "direct/indirect objects") are
 themselves nouns.
 

Umm... May I make a little correction here? Adjectives are not nouns. They are used to /describe/ nouns. -JJR
Jan 11 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"John Reimer" <terminal.node gmail.com> wrote in message 
news:28b70f8c119528cb42154f5d14e0 news.digitalmars.com...
 Hello Nick,

 But, of course, adjectives (just like "direct/indirect objects") are
 themselves nouns.

Umm... May I make a little correction here? Adjectives are not nouns. They are used to /describe/ nouns. -JJR

Maybe there's examples I'm not thinking of, and I'm certainly no natural language expert, but consider these: "red" "ball" "red ball" By themselves, "red" and "ball" are both nouns. Stick the noun "red" in front of ball and "red" becomes an adjectve. (FWIW, "dictionary.reference.com" lists "red" as both a noun and an adjective). The only adjectives I can think of at the moment (in my admittedly quite tired state) are words that are ordinarly nouns on their own. I would think that the distinguishing charactaristic of an adjective vs noun would be the context in which it's used. Maybe I am mixed up though, it's not really an area of expertise for me.
Jan 11 2009
next sibling parent reply John Reimer <terminal.node gmail.com> writes:
Hello Nick,

 "John Reimer" <terminal.node gmail.com> wrote in message
 news:28b70f8c119528cb42154f5d14e0 news.digitalmars.com...
 
 Hello Nick,
 
 But, of course, adjectives (just like "direct/indirect objects") are
 themselves nouns.
 

Adjectives are not nouns. They are used to /describe/ nouns. -JJR

natural language expert, but consider these: "red" "ball" "red ball" By themselves, "red" and "ball" are both nouns. Stick the noun "red" in front of ball and "red" becomes an adjectve. (FWIW, "dictionary.reference.com" lists "red" as both a noun and an adjective). The only adjectives I can think of at the moment (in my admittedly quite tired state) are words that are ordinarly nouns on their own. I would think that the distinguishing charactaristic of an adjective vs noun would be the context in which it's used. Maybe I am mixed up though, it's not really an area of expertise for me.

No problem. I am not saying a word can't be /used/ as an adjective and noun in different contexts. I'm just saying that they can't be an adjective and noun at the same time as your first post suggested. Grammatically, adjectives are not nouns (ever), even if the words themselves can be used as either in independent contexts; they just modify nouns. Like Jarett mentions, the fact that words that are adjectives in one context can shapeshift to another part of speech (the noun) in another, is immaterial to the definition: you just have to recognize when it happens and realize the change that has occurred in the part of speech. It something like how D uses the "!" prefix to instantiate a template and in another context uses it as a logical NOT. They can't mean both at the same time. They mean something different depending on where they are used. -JJR
Jan 11 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"John Reimer" <terminal.node gmail.com> wrote in message 
news:28b70f8c119bd8cb4246de86cc80 news.digitalmars.com...
 Hello Nick,

 "John Reimer" <terminal.node gmail.com> wrote in message
 news:28b70f8c119528cb42154f5d14e0 news.digitalmars.com...

 Hello Nick,

 But, of course, adjectives (just like "direct/indirect objects") are
 themselves nouns.

Adjectives are not nouns. They are used to /describe/ nouns. -JJR

natural language expert, but consider these: "red" "ball" "red ball" By themselves, "red" and "ball" are both nouns. Stick the noun "red" in front of ball and "red" becomes an adjectve. (FWIW, "dictionary.reference.com" lists "red" as both a noun and an adjective). The only adjectives I can think of at the moment (in my admittedly quite tired state) are words that are ordinarly nouns on their own. I would think that the distinguishing charactaristic of an adjective vs noun would be the context in which it's used. Maybe I am mixed up though, it's not really an area of expertise for me.

No problem. I am not saying a word can't be /used/ as an adjective and noun in different contexts. I'm just saying that they can't be an adjective and noun at the same time as your first post suggested. Grammatically, adjectives are not nouns (ever), even if the words themselves can be used as either in independent contexts; they just modify nouns. Like Jarett mentions, the fact that words that are adjectives in one context can shapeshift to another part of speech (the noun) in another, is immaterial to the definition: you just have to recognize when it happens and realize the change that has occurred in the part of speech.

I guess that's a difference between natural languages and oop-languages then. A member variable of an object typically /describes an attribute/ of the object, and thus makes it comparable to the notion of "adjective", but in an oop-language (and apperently unlike a natural language) that member object is itself either another object or a primitive.
 It something like how D uses the "!" prefix to instantiate a template and 
 in another context uses it as a logical NOT.  They can't mean both at the 
 same time.  They mean something different depending on where they are 
 used.

Ok, I see what you're saying.
Jan 12 2009
parent John Reimer <terminal.node gmail.com> writes:
Hello Nick,

 "John Reimer" <terminal.node gmail.com> wrote in message
 news:28b70f8c119bd8cb4246de86cc80 news.digitalmars.com...
 
 Hello Nick,
 
 "John Reimer" <terminal.node gmail.com> wrote in message
 news:28b70f8c119528cb42154f5d14e0 news.digitalmars.com...
 
 Hello Nick,
 
 But, of course, adjectives (just like "direct/indirect objects")
 are themselves nouns.
 

Adjectives are not nouns. They are used to /describe/ nouns. -JJR

natural language expert, but consider these: "red" "ball" "red ball" By themselves, "red" and "ball" are both nouns. Stick the noun "red" in front of ball and "red" becomes an adjectve. (FWIW, "dictionary.reference.com" lists "red" as both a noun and an adjective). The only adjectives I can think of at the moment (in my admittedly quite tired state) are words that are ordinarly nouns on their own. I would think that the distinguishing charactaristic of an adjective vs noun would be the context in which it's used. Maybe I am mixed up though, it's not really an area of expertise for me.

and noun in different contexts. I'm just saying that they can't be an adjective and noun at the same time as your first post suggested. Grammatically, adjectives are not nouns (ever), even if the words themselves can be used as either in independent contexts; they just modify nouns. Like Jarett mentions, the fact that words that are adjectives in one context can shapeshift to another part of speech (the noun) in another, is immaterial to the definition: you just have to recognize when it happens and realize the change that has occurred in the part of speech.

oop-languages then. A member variable of an object typically /describes an attribute/ of the object, and thus makes it comparable to the notion of "adjective", but in an oop-language (and apperently unlike a natural language) that member object is itself either another object or a primitive.

Yes, although natural languages and programming languages might share some similarities, natural langauges are going to be much more complex (even though both consist of grammars and alphabets). I know there's a whole science and theory of natural language analysis of which I'm mostly ignorant beyond a basic introduction. Much of the research of computer languages and compilers seems to have borrowed from the study of natural languages (see Noam Chomsky). I need to study it more myself. Also I just want to make clear that my explanation above was meant only to emphasize English grammar rules. I don't know enough about other natural langauges to make the statement universally applicable. There are some very "unusual" natural languages out there that will have a very different grammar such that, I suppose, they would seem to break the rules familiar to an English speaker. But, of course, a different language is not subject to the rules of the English grammar, so it should be no surprise. -JJR
Jan 12 2009
prev sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
Nick Sabalausky wrote:
 "John Reimer" <terminal.node gmail.com> wrote in message 
 news:28b70f8c119528cb42154f5d14e0 news.digitalmars.com...
 Hello Nick,

 But, of course, adjectives (just like "direct/indirect objects") are
 themselves nouns.

Umm... May I make a little correction here? Adjectives are not nouns. They are used to /describe/ nouns. -JJR

Maybe there's examples I'm not thinking of, and I'm certainly no natural language expert, but consider these: "red" "ball" "red ball" By themselves, "red" and "ball" are both nouns. Stick the noun "red" in front of ball and "red" becomes an adjectve. (FWIW, "dictionary.reference.com" lists "red" as both a noun and an adjective). The only adjectives I can think of at the moment (in my admittedly quite tired state) are words that are ordinarly nouns on their own. I would think that the distinguishing charactaristic of an adjective vs noun would be the context in which it's used. Maybe I am mixed up though, it's not really an area of expertise for me.

Incidentally... I used to do a lot of work in natural language processing, and our parsing heuristics were built to handle a lot of adjective/noun ambiguity. For example, in the phrase "car dealership", the word "car" is an adjective that modifies "dealership". For the most part, you can treat adjectives and nouns as being functionally identical, and the final word in a sequence of adjectives and nouns becomes the primary noun of the noun-phrase. --benji
Jan 12 2009
next sibling parent John Reimer <terminal.node gmail.com> writes:
Hello Benji,

 Nick Sabalausky wrote:
 
 "John Reimer" <terminal.node gmail.com> wrote in message
 news:28b70f8c119528cb42154f5d14e0 news.digitalmars.com...
 
 Hello Nick,
 
 But, of course, adjectives (just like "direct/indirect objects")
 are themselves nouns.
 

Adjectives are not nouns. They are used to /describe/ nouns. -JJR

natural language expert, but consider these: "red" "ball" "red ball" By themselves, "red" and "ball" are both nouns. Stick the noun "red" in front of ball and "red" becomes an adjectve. (FWIW, "dictionary.reference.com" lists "red" as both a noun and an adjective). The only adjectives I can think of at the moment (in my admittedly quite tired state) are words that are ordinarly nouns on their own. I would think that the distinguishing charactaristic of an adjective vs noun would be the context in which it's used. Maybe I am mixed up though, it's not really an area of expertise for me.

I used to do a lot of work in natural language processing, and our parsing heuristics were built to handle a lot of adjective/noun ambiguity. For example, in the phrase "car dealership", the word "car" is an adjective that modifies "dealership". For the most part, you can treat adjectives and nouns as being functionally identical, and the final word in a sequence of adjectives and nouns becomes the primary noun of the noun-phrase. --benji

Interesting. There is certainly room to play here. I never thought of this potential ambiguity of "nouns" and "adjectives" in a noun phrase. Thanks for the info. I'll look into this a little more. I guess Nick wasn't /that/ far of track. :) -JJR
Jan 12 2009
prev sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Benji Smith wrote:
 Nick Sabalausky wrote:
 "John Reimer" <terminal.node gmail.com> wrote in message 
 news:28b70f8c119528cb42154f5d14e0 news.digitalmars.com...
 Hello Nick,

 But, of course, adjectives (just like "direct/indirect objects") are
 themselves nouns.

Umm... May I make a little correction here? Adjectives are not nouns. They are used to /describe/ nouns. -JJR

Maybe there's examples I'm not thinking of, and I'm certainly no natural language expert, but consider these: "red" "ball" "red ball" By themselves, "red" and "ball" are both nouns. Stick the noun "red" in front of ball and "red" becomes an adjectve. (FWIW, "dictionary.reference.com" lists "red" as both a noun and an adjective). The only adjectives I can think of at the moment (in my admittedly quite tired state) are words that are ordinarly nouns on their own. I would think that the distinguishing charactaristic of an adjective vs noun would be the context in which it's used. Maybe I am mixed up though, it's not really an area of expertise for me.

Incidentally... I used to do a lot of work in natural language processing, and our parsing heuristics were built to handle a lot of adjective/noun ambiguity. For example, in the phrase "car dealership", the word "car" is an adjective that modifies "dealership".

It's a genitive phrase, not an adjective. You couldn't say "That dealership is car", for instance, but you could say "That is a dealership of cars."
 For the most part, you can treat adjectives and nouns as being 
 functionally identical, and the final word in a sequence of adjectives 
 and nouns becomes the primary noun of the noun-phrase.

No, you can't: "I gave the postman chlamydia." What is postman chlamydia?
 --benji

Jan 13 2009
parent John Reimer <terminal.node gmail.com> writes:
Hello Christopher,

 Benji Smith wrote:
 
 Nick Sabalausky wrote:
 
 "John Reimer" <terminal.node gmail.com> wrote in message
 news:28b70f8c119528cb42154f5d14e0 news.digitalmars.com...
 
 Hello Nick,
 
 But, of course, adjectives (just like "direct/indirect objects")
 are themselves nouns.
 

Adjectives are not nouns. They are used to /describe/ nouns. -JJR

natural language expert, but consider these: "red" "ball" "red ball" By themselves, "red" and "ball" are both nouns. Stick the noun "red" in front of ball and "red" becomes an adjectve. (FWIW, "dictionary.reference.com" lists "red" as both a noun and an adjective). The only adjectives I can think of at the moment (in my admittedly quite tired state) are words that are ordinarly nouns on their own. I would think that the distinguishing charactaristic of an adjective vs noun would be the context in which it's used. Maybe I am mixed up though, it's not really an area of expertise for me.

I used to do a lot of work in natural language processing, and our parsing heuristics were built to handle a lot of adjective/noun ambiguity. For example, in the phrase "car dealership", the word "car" is an adjective that modifies "dealership".

dealership is car", for instance, but you could say "That is a dealership of cars."
 For the most part, you can treat adjectives and nouns as being
 functionally identical, and the final word in a sequence of
 adjectives and nouns becomes the primary noun of the noun-phrase.
 

chlamydia?
 --benji
 


The reason I conceeded a little on this one is because of http://en.wikipedia.org/wiki/Noun_phrase. I'm not sure if wikipedia can be absolutely trusted... but this is beyond my grammatical knowledge to argue absolutely. In a sentence diagram, I would assume that adjectives would have to be distinctly positioned. In Benji's example, I assume practicality of implementation is what allows adjectives/nouns to be treated similarly, not necessarily strict adherence to grammatical rules. Just guessing... -JJR
Jan 13 2009
prev sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
John Reimer wrote:
 Hello Nick,
 
 But, of course, adjectives (just like "direct/indirect objects") are
 themselves nouns.

Umm... May I make a little correction here? Adjectives are not nouns. They are used to /describe/ nouns. -JJR

No programming language that I know distinguishes parts of an object (the hand of a body) from attributes of an object (the color of a ball). I think that's what he was getting at.
Jan 12 2009
parent John Reimer <terminal.node gmail.com> writes:
Hello Christopher,

 John Reimer wrote:
 
 Hello Nick,
 
 But, of course, adjectives (just like "direct/indirect objects") are
 themselves nouns.
 

They are used to /describe/ nouns. -JJR

(the hand of a body) from attributes of an object (the color of a ball). I think that's what he was getting at.

Yes, I was not critiquing his commentary on programming languages: it would have been dangerous for me to do so :). I was being (perhaps overly) nit-picky about his statement that incorrectly paralleled English grammar to the topic of discussion. -JJR
Jan 12 2009
prev sibling parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Sun, Jan 11, 2009 at 11:02 PM, Nick Sabalausky <a a.a> wrote:
 Maybe there's examples I'm not thinking of, and I'm certainly no natural
 language expert, but consider these:

 "red"
 "ball"
 "red ball"

 By themselves, "red" and "ball" are both nouns. Stick the noun "red" in
 front of ball and "red" becomes an adjectve. (FWIW,
 "dictionary.reference.com" lists "red" as both a noun and an adjective). The
 only adjectives I can think of at the moment (in my admittedly quite tired
 state) are words that are ordinarly nouns on their own.  I would think that
 the distinguishing charactaristic of an adjective vs noun would be the
 context in which it's used.

 Maybe I am mixed up though, it's not really an area of expertise for me.

That "red" can be used as both a noun and as an adjective is just a coincidence. Well, it's not entirely coincidental - there are many adjectives which have been nominalized like this. Some other languages (like Spanish) allow you to use an adjective as a noun, in which case it's like saying "<adjective> one" i.e. "el gordo" = "the fat [one]". In English, though, that process is far from productive. Consider the adjectives "sleepy", "hard", or "loud". There are of course nominalized forms of these - sleepiness, hardness, loudness - but they're separate words.
Jan 11 2009
prev sibling parent reply dsimcha <dsimcha yahoo.com> writes:
I'm starting to think that this properties thing is becoming a hopelessly
complicated solution to a very simple problem.  The issue that brought this to a
head in the first place was foo = foo + 1 vs. foo += 1.  Given that solving this
case properly seems like a rather difficult problem, the solution of just
defining
foo += 1 to mean foo = foo + 1 (which is what was originally proposed before
issues about properties of user-defined types were brought up) is starting to
look
appealing.  Yes, this might be inefficient on user defined types w/ operator
overloading, but so is the equivalent in other languages:

SomeObject temp = myClass.getFoo();
myClass.setFoo(temp + 1);

I figure the vast majority of cases are going to be primitive types anyhow
(mostly
ints), and if someone defines operator overloads such that foo += 1 produces
totally different observable behavior than foo = foo + 1, that's just too
ridiculously bad a design to even take seriously.  What do you think?  Is it
worth
ignoring a few hard cases in exchange for solving most cases simply and
elegantly
and without adding any new constructs?
Jan 10 2009
next sibling parent Chad J <gamerchad __spam.is.bad__gmail.com> writes:
dsimcha wrote:
 I'm starting to think that this properties thing is becoming a hopelessly
 complicated solution to a very simple problem.  The issue that brought this to
a
 head in the first place was foo = foo + 1 vs. foo += 1.  Given that solving
this
 case properly seems like a rather difficult problem, the solution of just
defining
 foo += 1 to mean foo = foo + 1 (which is what was originally proposed before
 issues about properties of user-defined types were brought up) is starting to
look
 appealing.  Yes, this might be inefficient on user defined types w/ operator
 overloading, but so is the equivalent in other languages:
 
 SomeObject temp = myClass.getFoo();
 myClass.setFoo(temp + 1);
 
 I figure the vast majority of cases are going to be primitive types anyhow
(mostly
 ints), and if someone defines operator overloads such that foo += 1 produces
 totally different observable behavior than foo = foo + 1, that's just too
 ridiculously bad a design to even take seriously.  What do you think?  Is it
worth
 ignoring a few hard cases in exchange for solving most cases simply and
elegantly
 and without adding any new constructs?

foo = foo + 1 vs foo += 1 is not the only issue here. Indeed, it is rather one of the less important ones, since it tends to give you a compile error instead of sending you on hours of debugging. Bill already mentioned that properties returning callable things were a problem. There's another one too: import tango.io.Stdout; struct Foo { char[] a = "Waait, something's wrong here."; } class Bar { Foo m_foo; Foo foo() { return m_foo; } // Interestingly, write properties are completely optional // when writing this kind of bug. // Foo foo( Foo value ) { return m_foo = value; } } void main() { auto b = new Bar(); b.foo.a = "Everything is fine."; Stdout( b.foo.a ).newline; //Prints "Waait, something's wrong here" // or writefln( b.foo.a ); if you prefer. } try it out (D1 code). This demonstrates how easy it is to write broken properties. It is related to foo = foo + 1 vs foo += 1 in that returning lvalues might solve both of these. However, as was mentioned before properties are not lvalues, so making properties always return lvalues may very well make more trouble for us.
Jan 10 2009
prev sibling parent reply Miles <_______ _______.____> writes:
dsimcha wrote:
 I figure the vast majority of cases are going to be primitive types anyhow
(mostly
 ints),

Yes, this is very true.
 and if someone defines operator overloads such that foo += 1 produces
 totally different observable behavior than foo = foo + 1, that's just too
 ridiculously bad a design to even take seriously.

Sure. It is bad coding style, it is ugly and the programmer who does this should be called for a meeting with his boss. But there are still ways to have sane behavior, even in such situations. See below.
 What do you think?  Is it worth
 ignoring a few hard cases in exchange for solving most cases simply and
elegantly
 and without adding any new constructs?

Instead, I think it is more sane to use temporaries. ---------- { auto tmp = __get_foo(); tmp += 1; __set_foo(foo); } ---------- It is the safest this way, principle of least surprise. If the caller does foo += 1, it will get that; if it does foo = foo + 1, it will still get that; if it does foo.call(), again, the behavior is still sane. We must first attack the semantics. This have sane semantics. Then let the compiler optimize that as far as possible. The compiler inlines the getter and setter calls, then optimizes away the temporary, etc.
Jan 11 2009
parent Benji Smith <dlanguage benjismith.net> writes:
Miles wrote:
 dsimcha wrote:
 I figure the vast majority of cases are going to be primitive types anyhow
(mostly
 ints),

Yes, this is very true.
 and if someone defines operator overloads such that foo += 1 produces
 totally different observable behavior than foo = foo + 1, that's just too
 ridiculously bad a design to even take seriously.

Sure. It is bad coding style, it is ugly and the programmer who does this should be called for a meeting with his boss. But there are still ways to have sane behavior, even in such situations. See below.
 What do you think?  Is it worth
 ignoring a few hard cases in exchange for solving most cases simply and
elegantly
 and without adding any new constructs?

Instead, I think it is more sane to use temporaries. ---------- { auto tmp = __get_foo(); tmp += 1; __set_foo(foo); } ---------- It is the safest this way, principle of least surprise. If the caller does foo += 1, it will get that; if it does foo = foo + 1, it will still get that; if it does foo.call(), again, the behavior is still sane. We must first attack the semantics. This have sane semantics. Then let the compiler optimize that as far as possible. The compiler inlines the getter and setter calls, then optimizes away the temporary, etc.

Or the compiler could prevent properties from returning mutable structs? class MyClass { private MyStruct _a; private MyStruct _b; public property a { const get { return _a; } // legal } public property a { get { return _b; } // compile-time error } } On the flip-side, the compiler could intervene at the call site, preventing modification of structs when directly accessed via a property invocation. Though I think the first solution is better. --benji
Jan 12 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Sun, Jan 11, 2009 at 12:01 PM, Miles <_______ _______.____> wrote:
 dsimcha wrote:
  I for one think that code is often more
 readable without the annoying empty parentheses around functions that don't
take
 any arguments.

It introduces ambiguities, and unexpected behavior, as I exemplified in the previous message. Parentheses (when following an identifier) has a precise meaning of calling the named function. That is something most modern procedural languages do, it is something programmers are used to. I see no advantage at giving the privilege to no-argument functions of being called without parentheses, while at the same time you lose the ability to distinguish between _calling_ the function from _referring_ to it.

Not sure what you mean by that. It's just foo vs &foo in most cases. ...Except for some cases like where you're trying to return a delegate. I agree that 'except for' is not very pleasant.
 This is especially true for member functions of classes and
 structs,

Aren't these member functions good candidates to be made into real properties? If you want or need to use an identifier without parentheses, you have the option of making it into a property. Very simple.

He may want to retain the ability to pass it as a delegate to some other function too. If you make properties distinct from functions, then I don't think this can be allowed. So you'd need to have the property and a function that wraps the property. Then you've just made more work for yourself. Hmm, maybe properties should be allowed to be turned into delegates. --bb
Jan 10 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Sun, 11 Jan 2009 21:52:27 +0300, bearophile <bearophileHUGS lycos.com> wrote:

 Nick Sabalausky:
 Yes, but 1. As you indicated, it could only happen in D when using an
 initializer on an "auto". And 2. I would imagine that would probably get
 caught as soon x was used.

You are right, Python being dynamically typed the situation is a little worse there.
 then using "foo" without "&" or "()" should be
 prohibited. (In fact, maybe that would be the ideal solution?)

That's what I was saying, to disallow "foo" without () or &. It's not the ideal situation but to me it looks better than the current ones (of both Python and D1). Bye, bearophile

Yes, this is the best design so far. I'd also note that using foo without either "&" or "()" is still necessary to get access to foo's set of properties: auto s = foo.stringof; auto m = foo.mangleof; // etc Other than that I'm absolutely agree with both of you. Too bad language designers don't participate in the discussion.
Jan 11 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Mon, Jan 12, 2009 at 4:07 AM, "J=E9r=F4me M. Berger" <jeberger free.fr> =
wrote:
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1

 Andrei Alexandrescu wrote:
 Miles wrote:
 Daniel Keep wrote:
 Yes, property syntax can simplify some cases, but this isn't one of
 them.

One good distinction properties and normal functions ought to make is that functions should never be called without (), and properties should never have () unless it has a function type. Current syntax allows crazy things like: ---------- exit =3D 1; // it is not an assignment x =3D toString =3D getenv =3D "PATH"; // creepy, but valid D if (fork =3D=3D 1) // not comparing the value of a variable ----------

Walter and I see eye to eye that a possible solution would be to only allow the a =3D b syntax as an alternative for a(b) only if there's also=


 function a(). All of the above can be fixed within that framework.


I'm guessing they thought of that and the answer is you can't, but write-only properties are a rare corner case. But either way, it doesn't solve the ambiguity problem. A callback setter/getter pair will still run into trouble because you can't tell if the getter wants to get the callback or actually call it. --bb
Jan 11 2009
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 12 Jan 2009 04:27:09 +0300, Sergey Kovrov <kovrov gmail.com> wrote:

 On 1/11/2009 9:32 PM, Denis Koroskin wrote:
 I'd also note that using foo without either "&" or "()" is still
 necessary to get access to foo's set of properties:

 auto s = foo.stringof;
 auto m = foo.mangleof;
 // etc

As far as I understand calling built-in properties eg. ``foo.stringof()`` is not allowed. And it is not an lvalue. So no referencing of a built-in properties possible either.

'&' and '()' were to be applied to foo rather that foo.property in the original message (i.e. &foo and foo()). I just provided example where neither '&' nor '()' were needed when accessing foo.
 I find this behavior most suitable for properties. The only exception is  
 built-in ``.reverse`` and ``.sort`` properties which seems counter  
 intuitive to me to be used without (). I think this should be something  
 callable (built-in functions, inherited methods, etc.) rather than  
 properties.

 -- serg.

Absolutely agree here.
Jan 11 2009
prev sibling next sibling parent Don <nospam nospam.com> writes:
dsimcha wrote:
 == Quote from BCS (ao pathlink.com)'s article
 Reply to Vishaal,
 Properties, such as array.length, should return lvalues to allow:
 a.length += 8;
 or other similar statements.

people gripe about it it will get fixed! (NOT said sarcastically!)

Yeah, this has been mentioned in the past before. The most obvious way to make it work w/o any breaking or significantly bulk-adding changes would be to define foo.length += 8 to mean foo = foo.length() + 8, or foo.length++ mean foo = foo.length + 1. This would be pure syntactic sugar, as it is when working with primitives. One problem that comes to mind is if, instead of length, which is presumably some kind of integer, you have a property for some user defined type with operator overloading. This user-defined type could define opAdd to do something arbitrarily different from opAddAssign. Even if we assume that no reasonable programmer would do this and treat this as a "who cares?" corner case,

It was recently pointed out in another thread that if prop is a class, it is currently nearly IMPOSSIBLE for prop += 8; to be the same as prop = prop + 8;. Properties therefore seem to be another important reason for fixing up operator overloading. there's
 still the problem of opInc and opAddAssign being much cheaper in some cases
than
 opAdd.  For example, in some cases opAdd might require copying of a whole
bunch of
 stuff, where opInc or opAddAssign just increments a single primitive under the
hood.

 
 Bottom line is, unless we assume that properties of user-defined types aren't
 important, we need a better solution.  Oh yeah, and on the more special case of
 arrays, which the compiler already treats as special, yes, foo.length += 2
should
 be legal.  As far as I can tell, this is a no-brainer.

Jan 08 2009
prev sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Sun, Jan 11, 2009 at 11:27 AM, dsimcha <dsimcha yahoo.com> wrote:
 == Quote from Miles (_______ _______.____)'s article
 Daniel Keep wrote:
 Yes, property syntax can simplify some cases, but this isn't one of them.

that functions should never be called without ()

Why? This is really superfluous. I for one think that code is often more readable without the annoying empty parentheses around functions that don't take any arguments. This is especially true for member functions of classes and structs, even moreso when chaining them such as foo.bar.baz vs. foo().bar().baz().
 , and properties should
 never have () unless it has a function type.
 Current syntax allows crazy things like:
 ----------
       exit = 1;       // it is not an assignment
       x = toString = getenv = "PATH"; // creepy, but valid D
       if (fork == 1)  // not comparing the value of a variable
 ----------

So? The spec is not there to prevent people from doing stupid things (making it harder to do stupid things *by accident* is a reasonable goal, but we're all consenting adults here). Anyone who would actually do stuff like this on purpose in their code is an idiot and deserves what they get. One could just as easily do some pretty stupid things with operator overloading, casts, templates, you name it. Just because stupid things *can* be done with a feature doesn't mean the feature should be removed.

I think the point is not that someone would do these things deliberately, it's that they might do them inadvertently. It's not that hard to end up with property names that sound like verbs or vice versa. Then the user of your code guesses that delay = true will be how to turn the 'delay' property on, and it compiles. But it turns out it it actually does a delay right then, and was really delay(bool yieldThread) or something like that, a parameterized action. All this just means one more thing you have to keep in mind while you're developing. You have to keep asking yourself "could somebody mistake this for a property?" every time you write a function with a short name. Or "could someone mistake this for an action?" when you think you're writing a property. Here's an issue I haven't seen discussed: What's the type of property foo? If a property can't be treated as a function, then it's type can't be the same as a function. It also can't be an int or whatever the referent type is. When you do __traits mojo and iterate over the members of the class, what should it return for a property? Not a killer I suppose, but there are probably more issues like that that would need to be dealt with that are more important than what the declaration syntax looks like. --bb
Jan 10 2009
prev sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
BCS wrote:
 Reply to Vishaal,
 
 Properties, such as array.length, should return lvalues to allow:
 a.length += 8;
 or other similar statements.

I think there is a (long standing) bug report about that one. Maybe if enough people gripe about it it will get fixed! (NOT said sarcastically!)

Gripe gripe gripe gripe gripe
Jan 07 2009
parent reply =?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:
Ellery Newcomer wrote:
 BCS wrote:
 Reply to Vishaal,

 Properties, such as array.length, should return lvalues to allow:
 a.length += 8;
 or other similar statements.

I think there is a (long standing) bug report about that one. Maybe if enough people gripe about it it will get fixed! (NOT said sarcastically!)

Gripe gripe gripe gripe gripe

Guriiiiipe. Gripe gripe. GRIPE.
Jan 07 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Alexander Pánek:
 Guriiiiipe. Gripe gripe. GRIPE.

Is this the second (redundant) system to vote for the most hated bugs? Bye, bearophile
Jan 08 2009
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
bearophile wrote:
 Alexander Pánek:
 Guriiiiipe. Gripe gripe. GRIPE.

Is this the second (redundant) system to vote for the most hated bugs? Bye, bearophile

Maybe we need a bot to monitor bugs' GPS [1]. You can never have too many redundant systems, afterall! -- Daniel P.S. Gripe gripe, gr-gr-gripe, GRIPE! [1] Gripes Per Second.
Jan 08 2009
prev sibling parent Mike James <foo bar.com> writes:
<fx chanting vikings in background>
Gripe, Gripe, Gripe. Gripe, Gripe, Gripe, Wonderful Gripe...

</fx>
Jan 08 2009
prev sibling next sibling parent Moritz Warning <moritzwarning web.de> writes:
On Thu, 08 Jan 2009 00:49:38 +0000, BCS wrote:

 Reply to Vishaal,
 
 Properties, such as array.length, should return lvalues to allow:
 a.length += 8;
 or other similar statements.

I think there is a (long standing) bug report about that one. Maybe if enough people gripe about it it will get fixed! (NOT said sarcastically!)

http://d.puremagic.com/issues/show_bug.cgi?id=808 *gripes*
Jan 07 2009
prev sibling next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Jan 9, 2009 at 9:59 AM, Miles <_______ _______.____> wrote:
 Nick Sabalausky wrote:
 A property setter is ALWAYS going to return nothing and

Both the getter and the setter should return an rvalue. Properties exist so that they are interchangeable with real member variables.

Partly, but also properties exist to provide encapsulation of private state. So you gotta be careful when you say they should always return an lvalue. Returning a straight 'ref T' is pretty much the same as making the member variable public, in terms of the encapsulation it gives you. class Foo { private int _data; ref int data() { return _data; } void data(int d) { data = d; do_something_very_important(); } } auto foo = new Foo; int*allyourdataisbelongtome = &Foo.data; Bye bye encapsulation. Now I can change your data all I want without you noticing. Also it means if I later realize I actually wanted data to be a float internally, I still have to keep an int member around to satisfy any client code that depends on getting an integer lvalue back. What I would like to see happen is that if a property setter doesn't return an lvalue, then the compiler will jigger things around to do everything in terms of calls to the setter. If it does return an lvalue then it will use it directly.
 Something
 that is possible with member variables MUST also be possible with
 properties, in a transparent way for any code outside the class.

 For example:

        button.width = button.height = 50;      // makes a square button

I agree that that should expand to something sensible, but that example doesn't actually require the setters to return an lvalue. A regular rvalue is fine for that. You'd only need to return an lvalue for something like: (button.height=50) += 3; Or for something like change_integer( button.height = 50 ); where change_integer takes a ref int. Using the lvalue returned from a property assignment is really not that common I think. Maybe I'm missing some big use case though. On the other hand, things like ++x do get used as lvalues more commonly I think. I'm fond of doing ++x%=N as a way to do a wrapped increment. :-) In C++, anyway. In D it gives me "x += 1 is not an lvalue". --bb
Jan 08 2009
prev sibling next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Jan 9, 2009 at 10:58 AM, Nick Sabalausky <a a.a> wrote:
 "Bill Baxter" <wbaxter gmail.com> wrote in message
 news:mailman.343.1231465331.22690.digitalmars-d puremagic.com...
 On Fri, Jan 9, 2009 at 9:59 AM, Miles <_______ _______.____> wrote:
 Nick Sabalausky wrote:
 A property setter is ALWAYS going to return nothing and

Both the getter and the setter should return an rvalue. Properties exist so that they are interchangeable with real member variables.

Partly, but also properties exist to provide encapsulation of private state. So you gotta be careful when you say they should always return an lvalue.

He said "rvalue", not "lvalue". I actually made that same mistake the first couple times I read it.

Wow. You're right. Maybe I need to change my font or something. Sorry for the rant about returning lvalues then! --bb
Jan 08 2009
prev sibling next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Jan 9, 2009 at 11:01 AM, Miles <_______ _______.____> wrote:
 Bill Baxter wrote:
 On Fri, Jan 9, 2009 at 9:59 AM, Miles <_______ _______.____> wrote:
 Both the getter and the setter should return an rvalue. Properties exist
 so that they are interchangeable with real member variables.

Partly, but also properties exist to provide encapsulation of private state. So you gotta be careful when you say they should always return an lvalue.

Wait! Read again what I said... getters and setters should return an *rvalue*, not lvalue. Everything else you said was based on the idea that accessors return lvalues, that wasn't what I said... There are some very special conditions where the getter MAY return an lvalue. But nothing else. The setter always returns rvalues. For example, if prop is a common property, defined as: public property int width { get() { return m_width; } set(Point value) { return m_width = value; } } Then the following code: x.width += 5; Should expand to something like (hopefully, optimized as far as possible): { auto tmp = x._get_width(); tmp += 5; x._set_width(tmp); } On the other hand, if the getter is defined to return an lvalue, like (tentative syntax): public property int width { ref get() { return m_width; } set(Point value) { return m_width = value; } } Then the compiler should be able to optimize the same code further: x._get_width() += 5; The same for member function calls if the property type is a structure or class.

Ok! I'm in agreement with you totally on all that. Sorry for the lvalue/rvalue mixup. --bb
Jan 08 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Sun, Jan 11, 2009 at 12:52 PM, dsimcha <dsimcha yahoo.com> wrote:
 I'm starting to think that this properties thing is becoming a hopelessly
 complicated solution to a very simple problem.  The issue that brought this to
a
 head in the first place was foo = foo + 1 vs. foo += 1.  Given that solving
this
 case properly seems like a rather difficult problem, the solution of just
defining
 foo += 1 to mean foo = foo + 1 (which is what was originally proposed before
 issues about properties of user-defined types were brought up) is starting to
look
 appealing.  Yes, this might be inefficient on user defined types w/ operator
 overloading, but so is the equivalent in other languages:

 SomeObject temp = myClass.getFoo();
 myClass.setFoo(temp + 1);

 I figure the vast majority of cases are going to be primitive types anyhow
(mostly
 ints), and if someone defines operator overloads such that foo += 1 produces
 totally different observable behavior than foo = foo + 1, that's just too
 ridiculously bad a design to even take seriously.  What do you think?  Is it
worth
 ignoring a few hard cases in exchange for solving most cases simply and
elegantly
 and without adding any new constructs?

Well, foo+=1 is not the only issue. It may have been the one that brought it to a head this time, but the issue has come up in the past with the focus on fixing the ambiguities around allowing functions to be called without (). Mainly I think that ambiguity relates to properties that return callable things. If foo is such a property then it's not clear how to call the thing returned by foo. I think the only way to make such things make sense and be consistent is to disallow the implicit function call stuff. --bb
Jan 10 2009
prev sibling next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 08 Jan 2009 03:45:08 +0300, Vishaal <vishaal nospam.com> wrote:

 Properties, such as array.length, should return lvalues to allow:
 a.length += 8;
 or other similar statements.

I'd like to point out another related issue that everyone seems to miss. The following code is taken from a GUI library: struct Rect { int x, y, width, height; void reset() { x = y = width = height = 0; } } class Control { //... Rect rect() { return _rect; } void rect(Rect newRect) { _resizeControl(newRect); } void _resizeControl(Rect rect) { // ... } private Rect _rect; //... } Imagine rect is not a property but a field, first. How would you mutate it? I'd do it as follows: Control c = new Control(); c.rect.reset(); c.rect.width = 100; Both lines do nothing when field replaced with a property. Code is broken but there is no complains from compiler. You should write the following code instead: Control c = new Control(); auto tmp = c.rect; tmp.reset(); c.rect = tmp; auto tmp = c.rect; tmp.width = 100; c.rect = tmp; but it doesn't look good. Compiler could be smarter in this regard - it could generate the code above automatically whenever a mutating method is called on a property. And here is also another issue I can't wait to be fixed. The following syntax: auto prop = foo.prop(); works for properties but not for fields, meaning that whenever code author decides to change it from property to field, user code is broken. Properties should not have optional braces! As a result, properties and fields can not be used interchangeably until issues above are fixed.
Jan 10 2009
next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Denis Koroskin wrote:
 On Thu, 08 Jan 2009 03:45:08 +0300, Vishaal <vishaal nospam.com> wrote:
 
 Properties, such as array.length, should return lvalues to allow:
 a.length += 8;
 or other similar statements.

I'd like to point out another related issue that everyone seems to miss.

C# also has that flaw. I ran into it a couple of times at work, and as a result, we have some types that could easily be POD structs but are classes instead. On the other hand, gmcs (the Mono compiler) errors out when you try modifying a struct that you access by a property, and the Microsoft compiler probably does as well: struct_prop.cs(24,21): error CS1612: Cannot modify a value type return value of `Foo.bar'. Consider storing the value in a temporary variable struct_prop.cs(3,8): (Location of the symbol related to previous error) struct_prop.cs(24,21): error CS0200: Property or indexer `Foo.bar' cannot be assigned to (it is read only) Compilation failed: 2 error(s), 0 warnings
Jan 11 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:
 On Thu, 08 Jan 2009 03:45:08 +0300, Vishaal <vishaal nospam.com> wrote:
 
 Properties, such as array.length, should return lvalues to allow:
 a.length += 8;
 or other similar statements.

I'd like to point out another related issue that everyone seems to miss. The following code is taken from a GUI library: struct Rect { int x, y, width, height; void reset() { x = y = width = height = 0; } } class Control { //... Rect rect() { return _rect; } void rect(Rect newRect) { _resizeControl(newRect); } void _resizeControl(Rect rect) { // ... } private Rect _rect; //... } Imagine rect is not a property but a field, first. How would you mutate it? I'd do it as follows: Control c = new Control(); c.rect.reset(); c.rect.width = 100; Both lines do nothing when field replaced with a property. Code is broken but there is no complains from compiler. You should write the following code instead: Control c = new Control(); auto tmp = c.rect; tmp.reset(); c.rect = tmp; auto tmp = c.rect; tmp.width = 100; c.rect = tmp; but it doesn't look good. Compiler could be smarter in this regard - it could generate the code above automatically whenever a mutating method is called on a property. And here is also another issue I can't wait to be fixed. The following syntax: auto prop = foo.prop(); works for properties but not for fields, meaning that whenever code author decides to change it from property to field, user code is broken. Properties should not have optional braces! As a result, properties and fields can not be used interchangeably until issues above are fixed.

This is a very strong argument. The issue is related to the fact that calling a member function is allowed on an rvalue, an anomaly that D inherited from C++. Andrei
Jan 11 2009
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Sun, 11 Jan 2009 07:50:03 +0300, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Miles wrote:
 Daniel Keep wrote:
 Yes, property syntax can simplify some cases, but this isn't one of  
 them.

that functions should never be called without (), and properties should never have () unless it has a function type. Current syntax allows crazy things like: ---------- exit = 1; // it is not an assignment x = toString = getenv = "PATH"; // creepy, but valid D if (fork == 1) // not comparing the value of a variable ----------

Walter and I see eye to eye that a possible solution would be to only allow the a = b syntax as an alternative for a(b) only if there's also a function a(). All of the above can be fixed within that framework.

It was criticized many times by different people as being a too complex and obscure rule. First, you allow to omit empty pair of braces. Now you understand that it was a bad idea as it bring to many problems and ambiguities. But instead of /fixing/ the source of the issues, you are trying to /reduce/ number of those issues (by narrowing range of cases where omitting parens allowed). That's a wrong way to go. You can reduce them, but you can't eliminate them entirely this way. It doesn't allow authors to define what is callable with property syntax and what is not. For example, I know many people that never use default function arguments because they cause too many problems with inheritance (some of them come from languages that doesn't allow them at all). Instead, the define two distinct functions: class Foo { int bar(int i) { // do something more intelligent here return i; } int bar() { // call main function with default arguments. // Default arguments may be overridden in derived class. return bar(42); } } And a Pandora's Box is open: Foo foo = new Foo(); foo.bar = -1; One more case - properties can not return references: class Foo { ref int bar() { return _bar; } private int _bar; } Foo foo = new Foo(); foo.bar = -1; test.d(17): function test.Foo.bar () does not match parameter types (int) test.d(17): Error: expected 0 arguments, not 1 Nevertheless, let's assume it is a bug and it will be fixed (one more case where optional parens feature causes a compiler bug). Then, what does the following code do: class Foo { ref int bar() { return _bar; } void bar(int i) { _bar = i; } private int _bar; } Foo foo = new Foo(); foo.bar = -1; // which one of the functions is called? Both are suitable. Compare it with the following one: class Foo { void bar(int i = 0) {} void bar() {} } Foo foo = new Foo(); foo.bar(); // which one is called? DMC result for reference: a.foo(); ^ test.cpp(20) : Error: ambiguous reference to symbol Had: A::foo() and: A::foo(int ) Besides, it has nothing to do with issue below:
 Also, currently, in D, if you have a property of a delegate type, you
 will have a mess.
  ----------
 	int func2() { return 42; }
  	/* this is a property */
 	int function() prop() {
 		return &func2;
 	}
 	
 	void main() {
 		auto x = prop;		// ok, x is a func ptr
 		auto y = prop();	// unexpected: y is not int :-(
 		static assert (is(typeof(y) == int));
 	}
 ----------
  With properties, you forbid the above syntaxes.

Well the above syntaxes could be forbidden other ways too. Andrei

They should not be forbidden, they should be allowed! Imagine a struct that emulates virtual behavior with methods as first-class objects: struct Message { string text; void delegate() show() // property getter { return _showDg; } void show(void delegate(ref Message message) dg) // property setter { _showDg = () { dg(this); } } private void delegate() _showDg; } auto showDg1 = (ref Message msg) { writefln(msg.text); } // output to stdout auto showDg2 = (ref Message msg) { MessageBox(0, "Message", msg.text, 0); } // show a message box Message message; message.text = "Hello World"; message.show = showDg1; message.show()(); // works but requires two pair of braces message.show = showDg2; message.show(); // this is a goal How would you /allow/ that? Why don't you see that non-mandatory parens bring more troubles than it /tries/ to solve.
Jan 10 2009