www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - property / getProperty() / setProperty()

reply Michel Fortin <michel.fortin michelf.com> writes:
I hope this proposal can rally more that divide... let's see.

Andrei said this in another thread about adding a property keyword in 
front of functions to make them properties:

 The problem is that it's all loss, no gain: the callee must make the
 decision whether the call must be with or without parens, and the caller
 must obey that decision. There is no guarantee gained, only effort.
I see your point Andrei: it's little gain to add a syntax that's just a modifier to a function to decide how you must call it. I also see the point of all those arguing that it's important to be able to distinguish between a property and an action, and that the english laguage is not expressive enough to make that distinction clear in a lot of cases. I know, I've written programming guidelines[1] and tried very hard to make this problem go away by mandating "is", "has" or a modal verb as a prefix for boolean attributes in the guidelines, only to be stuck with no solution for the "transform" example from Bill Baxter (thread "Properties - another one that gets me") which isn't boolean and for which you can't really add a prefix that makes sense. [1]: http://prowiki.org/wiki4d/wiki.cgi?DProgrammingGuidelines The best simple solution to that property problem I've seen up to now is to define "getProperty" and "setProperty" and have the compiler automatically check for these functions when it encounters the "property" symbol. Why do I favor "getThing" and "setThing" over "opGet_thing" and "opSet_thing"? Because the later are ugly. Please don't underestimate aestetics and readability as those are the key to make the language enjoyable to use and what the beginners will judge the language from. Also, the pattern will be pretty familiar to those comming from Java and elsewhere. And finally, for those who don't like having a property syntax, they can ignore properties completely and continue to use the get/set functions directly without making their code ugly. Here's an example: ~~~ int getValue(); void setValue(int x); setValue(1); /* property: */ value = 1; assert(getValue() == 1); /* property: */ assert(value == 1); ~~~ The problems this syntax should fix are: 1. the ambiguity between actions and properties: getValue()/setValue() are functions and thus actions named with verbs ("get" and "set"), but you can access them as the "value" property too, which is a noun that will call the function as necessary when an action is needed. (As a bonus, this makes "writeln = 2" illegal.) 2. the inconsistency for functions and properties returning something such as a delegate or a struct or class with an opCall member, where you absolutely need to write the function with a parenthesis to actually call the returned value. You can either call the function "getMyDelegate()(delegate_arg)" or use the property "myDelegate(delegate_arg)" just as you can with a field. This syntax doesn't solve the operator overloading issue. It isn't meant to do that either: properties should stay simple. The two small problems it pose are: 1. There's an ambiguity when another symbol is named after the property name that would call the get/set function. I suggest that this other symbol simply hide the property. 2. You need an uppercase algorithm in the compiler to be able to translate "property" to "setProperty" and "getProperty" and do the proper lookup. This works well for ASCII, but can it go messy with Unicode? To avoid converting to unicode upercase, we could use "get_thing" and "set_thing" (nicer than opGet/opSet), although that doesn't really fit with the coding standards of D. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Aug 01 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michel Fortin wrote:
 I hope this proposal can rally more that divide... let's see.
 
 Andrei said this in another thread about adding a property keyword in 
 front of functions to make them properties:
 
 The problem is that it's all loss, no gain: the callee must make the
 decision whether the call must be with or without parens, and the caller
 must obey that decision. There is no guarantee gained, only effort.
I see your point Andrei: it's little gain to add a syntax that's just a modifier to a function to decide how you must call it.
That's a great summary.
 I also see the point of all those arguing that it's important to be able 
 to distinguish between a property and an action, and that the english 
 laguage is not expressive enough to make that distinction clear in a lot 
 of cases.
I understand that point too.
 I know, I've written programming guidelines[1] and tried very 
 hard to make this problem go away by mandating "is", "has" or a modal 
 verb as a prefix for boolean attributes in the guidelines, only to be 
 stuck with no solution for the "transform" example from Bill Baxter 
 (thread "Properties - another one that gets me") which isn't boolean and 
 for which you can't really add a prefix that makes sense.
 
 [1]: http://prowiki.org/wiki4d/wiki.cgi?DProgrammingGuidelines
Good point.
 The best simple solution to that property problem I've seen up to now is 
 to define "getProperty" and "setProperty" and have the compiler 
 automatically check for these functions when it encounters the 
 "property" symbol.
 
 Why do I favor "getThing" and "setThing" over "opGet_thing" and 
 "opSet_thing"? Because the later are ugly. Please don't underestimate 
 aestetics and readability as those are the key to make the language 
 enjoyable to use and what the beginners will judge the language from. 
 Also, the pattern will be pretty familiar to those comming from Java and 
 elsewhere. And finally, for those who don't like having a property 
 syntax, they can ignore properties completely and continue to use the 
 get/set functions directly without making their code ugly.
I also like getThing and setThing more than get_thing and set_thing for defining a property called "thing". They both have problems, though: the former can't define a property starting with an uppercase letter, and the latter can't define a property starting with an underscore. (Symbols can't contain two underscores.) Ideas?
 Here's an example:
 
 ~~~
 int getValue();
 void setValue(int x);
 
 setValue(1);              /* property: */  value = 1;
 assert(getValue() == 1);  /* property: */  assert(value == 1);
 ~~~
 
 The problems this syntax should fix are:
 
 1. the ambiguity between actions and properties: getValue()/setValue() 
 are functions and  thus actions named with verbs ("get" and "set"), but 
 you can access them as the "value" property too, which is a noun that 
 will call the function as necessary when an action is needed. (As a 
 bonus, this makes "writeln = 2" illegal.)
Cool. If I only defined getEmpty, to I get to still use empty?
 2. the inconsistency for functions and properties returning something 
 such as a delegate or a struct or class with an opCall member, where you 
 absolutely need to write the function with a parenthesis to actually 
 call the returned value. You can either call the function 
 "getMyDelegate()(delegate_arg)" or use the property 
 "myDelegate(delegate_arg)" just as you can with a field.
Very nice solution indeed.
 This syntax doesn't solve the operator overloading issue. It isn't meant 
 to do that either: properties should stay simple.
Which issue are you referring to? +=?
 The two small problems it pose are:
 
 1. There's an ambiguity when another symbol is named after the property 
 name that would call the get/set function. I suggest that this other 
 symbol simply hide the property.
I wonder what should happen when this happens across scopes, e.g. in base and derived classes.
 2. You need an uppercase algorithm in the compiler to be able to 
 translate "property" to "setProperty" and "getProperty" and do the 
 proper lookup. This works well for ASCII, but can it go messy with Unicode?
Good question.
 To avoid converting to unicode upercase, we could use "get_thing" and 
 "set_thing" (nicer than opGet/opSet), although that doesn't really fit 
 with the coding standards of D.
Also, again, if you want to define "_thing" you'd have to write "get__thing" and "set__thing". Maybe we could lift the restriction about two underscores and only keep it for two leading underscores. Andrei
Aug 01 2009
next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, Aug 1, 2009 at 11:31 AM, Andrei
Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:

 To avoid converting to unicode upercase, we could use "get_thing" and
 "set_thing" (nicer than opGet/opSet), although that doesn't really fit with
 the coding standards of D.
Also, again, if you want to define "_thing" you'd have to write "get__thing" and "set__thing". Maybe we could lift the restriction about two underscores and only keep it for two leading underscores.
I'm pretty sure that's what the restriction is now (no leading double underscores). I don't think a__b is reserved.
Aug 01 2009
prev sibling next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, Aug 1, 2009 at 11:42 AM, Jarrett
Billingsley<jarrett.billingsley gmail.com> wrote:
 On Sat, Aug 1, 2009 at 11:31 AM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:

 To avoid converting to unicode upercase, we could use "get_thing" and
 "set_thing" (nicer than opGet/opSet), although that doesn't really fit =
with
 the coding standards of D.
Also, again, if you want to define "_thing" you'd have to write "get__th=
ing"
 and "set__thing". Maybe we could lift the restriction about two undersco=
res
 and only keep it for two leading underscores.
I'm pretty sure that's what the restriction is now (no leading double underscores). =A0I don't think a__b is reserved.
It is. "Identifiers starting with __ (two underscores) are reserved."
Aug 01 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jarrett Billingsley wrote:
 On Sat, Aug 1, 2009 at 11:42 AM, Jarrett
 Billingsley<jarrett.billingsley gmail.com> wrote:
 On Sat, Aug 1, 2009 at 11:31 AM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:

 To avoid converting to unicode upercase, we could use "get_thing" and
 "set_thing" (nicer than opGet/opSet), although that doesn't really fit with
 the coding standards of D.
Also, again, if you want to define "_thing" you'd have to write "get__thing" and "set__thing". Maybe we could lift the restriction about two underscores and only keep it for two leading underscores.
I'm pretty sure that's what the restriction is now (no leading double underscores). I don't think a__b is reserved.
It is. "Identifiers starting with __ (two underscores) are reserved."
Thanks. So it looks like get_property() and set_property() could fly. How does that sound? Andrei
Aug 01 2009
next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, Aug 1, 2009 at 11:54 AM, Andrei
Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Jarrett Billingsley wrote:
 On Sat, Aug 1, 2009 at 11:42 AM, Jarrett
 Billingsley<jarrett.billingsley gmail.com> wrote:
 On Sat, Aug 1, 2009 at 11:31 AM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:

 To avoid converting to unicode upercase, we could use "get_thing" and
 "set_thing" (nicer than opGet/opSet), although that doesn't really fi=
t
 with
 the coding standards of D.
Also, again, if you want to define "_thing" you'd have to write "get__thing" and "set__thing". Maybe we could lift the restriction about two underscores and only keep it for two leading underscores.
I'm pretty sure that's what the restriction is now (no leading double underscores). =A0I don't think a__b is reserved.
It is. "Identifiers starting with __ (two underscores) are reserved."
Thanks. So it looks like get_property() and set_property() could fly. How does that sound?
See my other reply.
Aug 01 2009
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:
 Thanks. So it looks like get_property() and set_property() could fly. 
 How does that sound?
Not too much good. Among the simpler solutions there's the 'property' attribute, that while not helping in reducing code (it makes code longer!) solves most problems, while being simple. It's the minimal solution that I think will work/fly. There are also other alternative (and a little more complex) solutions one of them more than one year ago. They aren't hard to learn. Bye, bearophile
Aug 01 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:
 Andrei Alexandrescu:
 Thanks. So it looks like get_property() and set_property() could fly. 
 How does that sound?
Not too much good. Among the simpler solutions there's the 'property' attribute, that while not helping in reducing code (it makes code longer!) solves most problems, while being simple. It's the minimal solution that I think will work/fly.
We can't throw keywords at problems like they're getting out of style. I've noticed that here every little problem gets solved by a little keyword. If not, some arcane new syntax. Nobody seems to care about rewriting, which I think is best. Andrei
Aug 01 2009
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Andrei Alexandrescu escribió:
 bearophile wrote:
 Andrei Alexandrescu:
 Thanks. So it looks like get_property() and set_property() could fly. 
 How does that sound?
Not too much good. Among the simpler solutions there's the 'property' attribute, that while not helping in reducing code (it makes code longer!) solves most problems, while being simple. It's the minimal solution that I think will work/fly.
We can't throw keywords at problems like they're getting out of style. I've noticed that here every little problem gets solved by a little keyword. If not, some arcane new syntax. Nobody seems to care about rewriting, which I think is best.
So what do you think about introducing attributes? Not only it will help not introducing new keyword, but it'll also *reduce* the amount of keywords that exist right now.
Aug 01 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ary Borenszweig wrote:
 Andrei Alexandrescu escribió:
 bearophile wrote:
 Andrei Alexandrescu:
 Thanks. So it looks like get_property() and set_property() could 
 fly. How does that sound?
Not too much good. Among the simpler solutions there's the 'property' attribute, that while not helping in reducing code (it makes code longer!) solves most problems, while being simple. It's the minimal solution that I think will work/fly.
We can't throw keywords at problems like they're getting out of style. I've noticed that here every little problem gets solved by a little keyword. If not, some arcane new syntax. Nobody seems to care about rewriting, which I think is best.
So what do you think about introducing attributes? Not only it will help not introducing new keyword, but it'll also *reduce* the amount of keywords that exist right now.
Attributes would be great, but you guys should stop asking me what I think and ask Walter. I seem to vaguely recall Walter isn't very excited about attributes. Andrei
Aug 01 2009
prev sibling next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, Aug 1, 2009 at 12:21 PM, Andrei
Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 bearophile wrote:
 Andrei Alexandrescu:
 Thanks. So it looks like get_property() and set_property() could fly. How
 does that sound?
Not too much good. Among the simpler solutions there's the 'property' attribute, that while not helping in reducing code (it makes code longer!) solves most problems, while being simple. It's the minimal solution that I think will work/fly.
We can't throw keywords at problems like they're getting out of style. I've noticed that here every little problem gets solved by a little keyword. If not, some arcane new syntax. Nobody seems to care about rewriting, which I think is best.
I don't know if you're just being passive-aggressive here or what. Is this a response to my post? I'll ask again: do you have any *technical* issues with the 'property' attribute suggestion?
Aug 01 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jarrett Billingsley wrote:
 On Sat, Aug 1, 2009 at 12:21 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 bearophile wrote:
 Andrei Alexandrescu:
 Thanks. So it looks like get_property() and set_property() could fly. How
 does that sound?
Not too much good. Among the simpler solutions there's the 'property' attribute, that while not helping in reducing code (it makes code longer!) solves most problems, while being simple. It's the minimal solution that I think will work/fly.
We can't throw keywords at problems like they're getting out of style. I've noticed that here every little problem gets solved by a little keyword. If not, some arcane new syntax. Nobody seems to care about rewriting, which I think is best.
I don't know if you're just being passive-aggressive here or what. Is this a response to my post? I'll ask again: do you have any *technical* issues with the 'property' attribute suggestion?
My main technical issue is throwing a keyword at a very minor issue. Once the keyword is in the mix, we need to define how it interacts with everything else (e.g., are properties overridable?) A solution based on rewrites is considerably simpler and more in according with the size of the problem. Andrei
Aug 01 2009
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Andrei Alexandrescu escribió:
 Jarrett Billingsley wrote:
 On Sat, Aug 1, 2009 at 12:21 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 bearophile wrote:
 Andrei Alexandrescu:
 Thanks. So it looks like get_property() and set_property() could 
 fly. How
 does that sound?
Not too much good. Among the simpler solutions there's the 'property' attribute, that while not helping in reducing code (it makes code longer!) solves most problems, while being simple. It's the minimal solution that I think will work/fly.
We can't throw keywords at problems like they're getting out of style. I've noticed that here every little problem gets solved by a little keyword. If not, some arcane new syntax. Nobody seems to care about rewriting, which I think is best.
I don't know if you're just being passive-aggressive here or what. Is this a response to my post? I'll ask again: do you have any *technical* issues with the 'property' attribute suggestion?
My main technical issue is throwing a keyword at a very minor issue. Once the keyword is in the mix, we need to define how it interacts with everything else (e.g., are properties overridable?) A solution based on rewrites is considerably simpler and more in according with the size of the problem.
The "property" just signals that the function is a property. But it's still a function and all of the previous rules that existed are still valid. I'll copy Jarrett's points here once more: 1. You can no longer call functions as properties that were never intended to be (writeln = 4; goes away). 2. The "obj.prop(args)" ambiguity goes away. *Either* obj.prop is a normal method function and (args) are passed to it, *or* obj.prop has the "property" attribute, and (args) are passed to its result. Stuff like "obj.prop[i]" is the same way. 3. There is no naming ambiguity. 4. There are no case issues. 5. It provides useful semantic information to tools, IDEs, and reflection. 6. It's nonintrusive and self-documenting. As you can see, the only thing that will change for users is point 1. Nothing else changes, no need to define new rules, new syntax, new nothing. It's as unobstrusive as possible (obviusly much better if attributes were already present in the language). About attributes, later I'll write a post about how attribute can be started to be implemented (not just the syntax, but what the compiler does with them).
Aug 01 2009
parent reply Rainer Deyke <rainerd eldwood.com> writes:
Ary Borenszweig wrote:
 The "property" just signals that the function is a property. But it's
 still a function and all of the previous rules that existed are still
 valid.
My problem with the 'property' syntax: Possibility 1: the property still acts like a function, so you can still do 'x.a()' when you mean 'x.a'. Possibility 2: the property does not act like a function, so you can no longer get a delegate to the property getter. Possibility 3: the property sometimes acts like a function and sometimes not, and you haven't defined the distinction. All three possibilities are messy, and I can't tell from your proposal which one will apply. get_foo/set_foo is better in this regard, plus it doesn't require yet another keyword. -- Rainer Deyke - rainerd eldwood.com
Aug 01 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Rainer Deyke escribió:
 Ary Borenszweig wrote:
 The "property" just signals that the function is a property. But it's
 still a function and all of the previous rules that existed are still
 valid.
My problem with the 'property' syntax: Possibility 1: the property still acts like a function, so you can still do 'x.a()' when you mean 'x.a'. Possibility 2: the property does not act like a function, so you can no longer get a delegate to the property getter. Possibility 3: the property sometimes acts like a function and sometimes not, and you haven't defined the distinction.
None of those are correct. See Jarrett's post. property { int x() { } int x(int a) { } } auto a = x; // OK auto a = x(); // Wrong x = 2; // OK x(2); // Wrong
Aug 01 2009
parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, Aug 1, 2009 at 2:38 PM, Ary Borenszweig<ary esperanto.org.ar> wrote=
:
 Rainer Deyke escribi=F3:
 Ary Borenszweig wrote:
 The "property" just signals that the function is a property. But it's
 still a function and all of the previous rules that existed are still
 valid.
My problem with the 'property' syntax: Possibility 1: the property still acts like a function, so you can still do 'x.a()' when you mean 'x.a'. Possibility 2: the property does not act like a function, so you can no longer get a delegate to the property getter. Possibility 3: the property sometimes acts like a function and sometimes not, and you haven't defined the distinction.
None of those are correct. See Jarrett's post. property { =A0int x() { } =A0int x(int a) { } } auto a =3D x; // OK auto a =3D x(); // Wrong x =3D 2; // OK x(2); // Wrong
And furthermore, I mentioned that &obj.foo would always get the address of the member 'foo' from 'obj', even if 'foo' was a property. But hey, it's not like it matters anyway. We're pissing in the ocean.
Aug 01 2009
parent Rainer Deyke <rainerd eldwood.com> writes:
Jarrett Billingsley wrote:
 On Sat, Aug 1, 2009 at 2:38 PM, Ary Borenszweig<ary esperanto.org.ar> wrote:
 auto a = x; // OK
 auto a = x(); // Wrong
 x = 2; // OK
 x(2); // Wrong
And furthermore, I mentioned that &obj.foo would always get the address of the member 'foo' from 'obj', even if 'foo' was a property.
That's the part of this proposal I don't like. The getter of a property is not the property itself, and should not have the same name. It's confusing that '&x.y' is a delegate but 'x.y' is not a method. In short, this proposal fails to fix the conceptual problem with the way properties are handled in D right now. -- Rainer Deyke - rainerd eldwood.com
Aug 01 2009
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:h51rnq$o2q$1 digitalmars.com...
 Jarrett Billingsley wrote:
 I'll ask again: do you have any *technical* issues with the 'property'
 attribute suggestion?
My main technical issue is throwing a keyword at a very minor issue.
Yeah, it is pretty minor, huh? I mean, it's not like it's been the center of discussion for the past week. And no one has ever complained about it before. Downplaying the size of the issue at hand doesn't make it go away.
 Once the keyword is in the mix, we need to define how it interacts with 
 everything else (e.g., are properties overridable?)
Of course they're overridable. They are *functions*. They do everything exactly the same as other functions. *All* the property attribute would do is enforce a property syntax at the use site instead of a function call syntax.
 A solution based on rewrites is considerably simpler and more in according 
 with the size of the problem.
A solution based on rewrites has a pretty horrible problem with name ambiguity. And this isn't even a technical concern; you're just saying again that the problem is minor. You have not presented any technical arguments against the property attribute suggestion. So let me get this straight: the property attribute would be better technically, but let's not throw more keywords at it; so instead we suggest attributes, but no, they don't have any useful purpose. WHAT.
Aug 01 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jarrett Billingsley wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:h51rnq$o2q$1 digitalmars.com...
 Jarrett Billingsley wrote:
 I'll ask again: do you have any *technical* issues with the 'property'
 attribute suggestion?
My main technical issue is throwing a keyword at a very minor issue.
Yeah, it is pretty minor, huh? I mean, it's not like it's been the center of discussion for the past week. And no one has ever complained about it before. Downplaying the size of the issue at hand doesn't make it go away.
 Once the keyword is in the mix, we need to define how it interacts with 
 everything else (e.g., are properties overridable?)
Of course they're overridable. They are *functions*.
Then why are you calling them properties? :o)
 They do everything 
 exactly the same as other functions.  *All* the property attribute would do 
 is enforce a property syntax at the use site instead of a function call 
 syntax.
Oh, so it is minor.
 A solution based on rewrites is considerably simpler and more in according 
 with the size of the problem.
A solution based on rewrites has a pretty horrible problem with name ambiguity. And this isn't even a technical concern; you're just saying again that the problem is minor. You have not presented any technical arguments against the property attribute suggestion. So let me get this straight: the property attribute would be better technically, but let's not throw more keywords at it; so instead we suggest attributes, but no, they don't have any useful purpose. WHAT.
I didn't say that. Andrei
Aug 01 2009
parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, Aug 1, 2009 at 1:38 PM, Andrei
Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:

 Of course they're overridable. =A0They are *functions*.
Then why are you calling them properties? :o)
Stop deliberately misunderstanding me.
 So let me get this straight: the property attribute would be better
 technically, but let's not throw more keywords at it; so instead we sugg=
est
 attributes, but no, they don't have any useful purpose.

 WHAT.
I didn't say that.
Whatever. Have fun designing your own language, Andrei. Must be nice.
Aug 01 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jarrett Billingsley wrote:
 On Sat, Aug 1, 2009 at 1:38 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 
 Of course they're overridable.  They are *functions*.
Then why are you calling them properties? :o)
Stop deliberately misunderstanding me.
Yeah, sorry. Low blow. I shouldn't have sent out that crap. Andrei
Aug 01 2009
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Andrei Alexandrescu escribió:
 bearophile wrote:
 Andrei Alexandrescu:
 Thanks. So it looks like get_property() and set_property() could fly. 
 How does that sound?
Not too much good. Among the simpler solutions there's the 'property' attribute, that while not helping in reducing code (it makes code longer!) solves most problems, while being simple. It's the minimal solution that I think will work/fly.
We can't throw keywords at problems like they're getting out of style.
Hey! Let's introduce pure functions --> the new "pure" keyword was added. Hey! Let's introduce functions that don't throw --> the new "nothrow" keyword was added. Hey! Let's introduce thread local storage --> "shared" and "__gshared" keyword added. Hey! Let's introduce... annotations and stop adding keywords for every new feature.
Aug 01 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ary Borenszweig wrote:
 Andrei Alexandrescu escribió:
 bearophile wrote:
 Andrei Alexandrescu:
 Thanks. So it looks like get_property() and set_property() could 
 fly. How does that sound?
Not too much good. Among the simpler solutions there's the 'property' attribute, that while not helping in reducing code (it makes code longer!) solves most problems, while being simple. It's the minimal solution that I think will work/fly.
We can't throw keywords at problems like they're getting out of style.
Hey! Let's introduce pure functions --> the new "pure" keyword was added. Hey! Let's introduce functions that don't throw --> the new "nothrow" keyword was added. Hey! Let's introduce thread local storage --> "shared" and "__gshared" keyword added. Hey! Let's introduce... annotations and stop adding keywords for every new feature.
For the record, I didn't like most of these. Andrei
Aug 01 2009
prev sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-08-01 11:31:17 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 Michel Fortin wrote:
 I hope this proposal can rally more that divide... let's see.
 
 Andrei said this in another thread about adding a property keyword in 
 front of functions to make them properties:
 
 The problem is that it's all loss, no gain: the callee must make the
 decision whether the call must be with or without parens, and the caller
 must obey that decision. There is no guarantee gained, only effort.
I see your point Andrei: it's little gain to add a syntax that's just a modifier to a function to decide how you must call it.
That's a great summary.
 I also see the point of all those arguing that it's important to be 
 able to distinguish between a property and an action, and that the 
 english laguage is not expressive enough to make that distinction clear 
 in a lot of cases.
I understand that point too.
 I know, I've written programming guidelines[1] and tried very hard to 
 make this problem go away by mandating "is", "has" or a modal verb as a 
 prefix for boolean attributes in the guidelines, only to be stuck with 
 no solution for the "transform" example from Bill Baxter (thread 
 "Properties - another one that gets me") which isn't boolean and for 
 which you can't really add a prefix that makes sense.
 
 [1]: http://prowiki.org/wiki4d/wiki.cgi?DProgrammingGuidelines
Good point.
 The best simple solution to that property problem I've seen up to now 
 is to define "getProperty" and "setProperty" and have the compiler 
 automatically check for these functions when it encounters the 
 "property" symbol.
 
 Why do I favor "getThing" and "setThing" over "opGet_thing" and 
 "opSet_thing"? Because the later are ugly. Please don't underestimate 
 aestetics and readability as those are the key to make the language 
 enjoyable to use and what the beginners will judge the language from. 
 Also, the pattern will be pretty familiar to those comming from Java 
 and elsewhere. And finally, for those who don't like having a property 
 syntax, they can ignore properties completely and continue to use the 
 get/set functions directly without making their code ugly.
I also like getThing and setThing more than get_thing and set_thing for defining a property called "thing". They both have problems, though: the former can't define a property starting with an uppercase letter,
Well, yes and no. You could map both the property "thing" and "Thing" to "setThing"/"getThing", thus making the first character of a property case-insensitive. That's a little awkward, though. But that's exactly what key-value coding does for getting and setting value in Objective-C [1]. [1]: http://developer.apple.com/documentation/Cocoa/Conceptual/KeyValueCoding/Concepts/Compliant.html and
 the latter can't define a property starting with an underscore. 
 (Symbols can't contain two underscores.) Ideas?
This has been shown to not be the case by Jarret. So set_thing and get_thing can work indeed. I don't like that underscore much though: it looks like a special syntax for properties that goes against the language style guidelines. Sure you can change the style guidelines to adopt them, but this syntax will still look out of place.
 Here's an example:
 
 ~~~
 int getValue();
 void setValue(int x);
 
 setValue(1);              /* property: */  value = 1;
 assert(getValue() == 1);  /* property: */  assert(value == 1);
 ~~~
 
 The problems this syntax should fix are:
 
 1. the ambiguity between actions and properties: getValue()/setValue() 
 are functions and  thus actions named with verbs ("get" and "set"), but 
 you can access them as the "value" property too, which is a noun that 
 will call the function as necessary when an action is needed. (As a 
 bonus, this makes "writeln = 2" illegal.)
Cool. If I only defined getEmpty, to I get to still use empty?
Exactly. You define "bool getEmpty()" and the compiler rewrites any call to a property "empty" as "getEmpty()".
 2. the inconsistency for functions and properties returning something 
 such as a delegate or a struct or class with an opCall member, where 
 you absolutely need to write the function with a parenthesis to 
 actually call the returned value. You can either call the function 
 "getMyDelegate()(delegate_arg)" or use the property 
 "myDelegate(delegate_arg)" just as you can with a field.
Very nice solution indeed.
 This syntax doesn't solve the operator overloading issue. It isn't 
 meant to do that either: properties should stay simple.
Which issue are you referring to? +=?
This, and any other operator of this kind (++, --, *=, etc.).
 
 The two small problems it pose are:
 
 1. There's an ambiguity when another symbol is named after the property 
 name that would call the get/set function. I suggest that this other 
 symbol simply hide the property.
I wonder what should happen when this happens across scopes, e.g. in base and derived classes.
And I wonder more what happens with the various protection attributes. :-)
 2. You need an uppercase algorithm in the compiler to be able to 
 translate "property" to "setProperty" and "getProperty" and do the 
 proper lookup. This works well for ASCII, but can it go messy with 
 Unicode?
Good question.
For instance, isn't ß a lowercase-only letter in German that gets traslated to SS in uppercase? (I'm not very familiar with German.) -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Aug 01 2009
prev sibling next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, Aug 1, 2009 at 10:14 AM, Michel Fortin<michel.fortin michelf.com> w=
rote:

 The best simple solution to that property problem I've seen up to now is =
to
 define "getProperty" and "setProperty" and have the compiler automaticall=
y
 check for these functions when it encounters the "property" symbol.

 Why do I favor "getThing" and "setThing" over "opGet_thing" and
 "opSet_thing"? Because the later are ugly. Please don't underestimate
 aestetics and readability as those are the key to make the language
 enjoyable to use and what the beginners will judge the language from. Als=
o,
 the pattern will be pretty familiar to those comming from Java and
 elsewhere. And finally, for those who don't like having a property syntax=
,
 they can ignore properties completely and continue to use the get/set
 functions directly without making their code ugly.

 Here's an example:

 ~~~
 int getValue();
 void setValue(int x);

 setValue(1); =A0 =A0 =A0 =A0 =A0 =A0 =A0/* property: */ =A0value =3D 1;
 assert(getValue() =3D=3D 1); =A0/* property: */ =A0assert(value =3D=3D 1)=
;
 ~~~

 The problems this syntax should fix are:

 1. the ambiguity between actions and properties: getValue()/setValue() ar=
e
 functions and =A0thus actions named with verbs ("get" and "set"), but you=
can
 access them as the "value" property too, which is a noun that will call t=
he
 function as necessary when an action is needed. (As a bonus, this makes
 "writeln =3D 2" illegal.)

 2. the inconsistency for functions and properties returning something suc=
h
 as a delegate or a struct or class with an opCall member, where you
 absolutely need to write the function with a parenthesis to actually call
 the returned value. You can either call the function
 "getMyDelegate()(delegate_arg)" or use the property
 "myDelegate(delegate_arg)" just as you can with a field.

 This syntax doesn't solve the operator overloading issue. It isn't meant =
to
 do that either: properties should stay simple.

 The two small problems it pose are:

 1. There's an ambiguity when another symbol is named after the property n=
ame
 that would call the get/set function. I suggest that this other symbol
 simply hide the property.

 2. You need an uppercase algorithm in the compiler to be able to translat=
e
 "property" to "setProperty" and "getProperty" and do the proper lookup. T=
his
 works well for ASCII, but can it go messy with Unicode?

 To avoid converting to unicode upercase, we could use "get_thing" and
 "set_thing" (nicer than opGet/opSet), although that doesn't really fit wi=
th
 the coding standards of D.
It's been mentioned before, and I'll mention it again: a simple 'property' attribute that can be applied to any function. No new syntax, no get/set/value 'magic' keywords, just 'property.' Applying it to a function makes the compiler enforce the property syntax when using the functions. Any function that doesn't have the property attribute - which should be most functions - can't be treated as one. It doesn't require any special support from the compiler beyond what it currently does. It doesn't require any 'magic'. It doesn't require any verbose syntax. It solves pretty much all the problems. 1. You can no longer call functions as properties that were never intended to be (writeln =3D 4; goes away). 2. The "obj.prop(args)" ambiguity goes away. *Either* obj.prop is a normal method function and (args) are passed to it, *or* obj.prop has the "property" attribute, and (args) are passed to its result. Stuff like "obj.prop[i]" is the same way. 3. There is no naming ambiguity. 4. There are no case issues. 5. It provides useful semantic information to tools, IDEs, and reflection. 6. It's nonintrusive and self-documenting. The *only* technical issue I can come up with is if you had "property ref X foo()", where foo returned a reference to some value type. Then you do "&obj.foo" - what does this get the address of? To that end, I suggest that &obj.foo always gets the address of the member or method 'foo' from object 'obj', and &(obj.foo) would get the address of the return value of obj.foo. The extra parens in there say "really, I want you to evaluate the thing inside *first*". Andrei, I don't know your thoughts on this. I know you don't like the idea of introducing new syntax but this is really as minimalistic as you can get. Do you have any technical issues with this proposal? Is there a reason why you would choose the opGet_foo/get_foo proposal over this?
Aug 01 2009
next sibling parent Marianne Gagnon <auria.mg gmail.com> writes:
Jarrett Billingsley Wrote:

 On Sat, Aug 1, 2009 at 10:14 AM, Michel Fortin<michel.fortin michelf.com>
wrote:
 
 The best simple solution to that property problem I've seen up to now is to
 define "getProperty" and "setProperty" and have the compiler automatically
 check for these functions when it encounters the "property" symbol.

 Why do I favor "getThing" and "setThing" over "opGet_thing" and
 "opSet_thing"? Because the later are ugly. Please don't underestimate
 aestetics and readability as those are the key to make the language
 enjoyable to use and what the beginners will judge the language from. Also,
 the pattern will be pretty familiar to those comming from Java and
 elsewhere. And finally, for those who don't like having a property syntax,
 they can ignore properties completely and continue to use the get/set
 functions directly without making their code ugly.

 Here's an example:

 ~~~
 int getValue();
 void setValue(int x);

 setValue(1);              /* property: */  value = 1;
 assert(getValue() == 1);  /* property: */  assert(value == 1);
 ~~~

 The problems this syntax should fix are:

 1. the ambiguity between actions and properties: getValue()/setValue() are
 functions and  thus actions named with verbs ("get" and "set"), but you can
 access them as the "value" property too, which is a noun that will call the
 function as necessary when an action is needed. (As a bonus, this makes
 "writeln = 2" illegal.)

 2. the inconsistency for functions and properties returning something such
 as a delegate or a struct or class with an opCall member, where you
 absolutely need to write the function with a parenthesis to actually call
 the returned value. You can either call the function
 "getMyDelegate()(delegate_arg)" or use the property
 "myDelegate(delegate_arg)" just as you can with a field.

 This syntax doesn't solve the operator overloading issue. It isn't meant to
 do that either: properties should stay simple.

 The two small problems it pose are:

 1. There's an ambiguity when another symbol is named after the property name
 that would call the get/set function. I suggest that this other symbol
 simply hide the property.

 2. You need an uppercase algorithm in the compiler to be able to translate
 "property" to "setProperty" and "getProperty" and do the proper lookup. This
 works well for ASCII, but can it go messy with Unicode?

 To avoid converting to unicode upercase, we could use "get_thing" and
 "set_thing" (nicer than opGet/opSet), although that doesn't really fit with
 the coding standards of D.
It's been mentioned before, and I'll mention it again: a simple 'property' attribute that can be applied to any function. No new syntax, no get/set/value 'magic' keywords, just 'property.' Applying it to a function makes the compiler enforce the property syntax when using the functions. Any function that doesn't have the property attribute - which should be most functions - can't be treated as one. It doesn't require any special support from the compiler beyond what it currently does. It doesn't require any 'magic'. It doesn't require any verbose syntax. It solves pretty much all the problems. 1. You can no longer call functions as properties that were never intended to be (writeln = 4; goes away). 2. The "obj.prop(args)" ambiguity goes away. *Either* obj.prop is a normal method function and (args) are passed to it, *or* obj.prop has the "property" attribute, and (args) are passed to its result. Stuff like "obj.prop[i]" is the same way. 3. There is no naming ambiguity. 4. There are no case issues. 5. It provides useful semantic information to tools, IDEs, and reflection. 6. It's nonintrusive and self-documenting.
This gets my vote. Clean, elegant, works well, looks good.
Aug 01 2009
prev sibling next sibling parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Sat, 01 Aug 2009 11:56:23 -0400, Jarrett Billingsley  
<jarrett.billingsley gmail.com> wrote:
 1. You can no longer call functions as properties that were never
 intended to be (writeln = 4; goes away).
*sigh* writeln = 4 doesn't compile and hasn't for a while. It would be nice if the examples were valid code.
Aug 01 2009
parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, Aug 1, 2009 at 12:21 PM, Robert Jacques<sandford jhu.edu> wrote:
 On Sat, 01 Aug 2009 11:56:23 -0400, Jarrett Billingsley
 <jarrett.billingsley gmail.com> wrote:
 1. You can no longer call functions as properties that were never
 intended to be (writeln = 4; goes away).
*sigh* writeln = 4 doesn't compile and hasn't for a while. It would be nice if the examples were valid code.
I'm a D1 user. It compiles in D1, because writeln (or writefln) is defined as a normal non-templated function. Here, have this instead: void foo(int){} foo = 5;
Aug 01 2009
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-08-01 11:56:23 -0400, Jarrett Billingsley 
<jarrett.billingsley gmail.com> said:

 It's been mentioned before, and I'll mention it again: a simple
 'property' attribute that can be applied to any function.  No new
 syntax, no get/set/value 'magic' keywords, just 'property.'  Applying
 it to a function makes the compiler enforce the property syntax when
 using the functions.  Any function that doesn't have the property
 attribute - which should be most functions - can't be treated as one.
 It doesn't require any special support from the compiler beyond what
 it currently does.  It doesn't require any 'magic'.  It doesn't
 require any verbose syntax.  It solves pretty much all the problems.
That wasn't addressed to me, but since I started this thread, I feel I should answer. What problems does your proposal solve that aren't solved by a naming convention and the compiler following that convention to enable the property syntax? From what I see, you prefer adding a property keyword over a naming convention. That's fine, but I think otherwise. Let's compare them on a technical level using your checklist:
 1. You can no longer call functions as properties that were never
 intended to be (writeln = 4; goes away).
Same as with a get/set prefix, except that you can now explicitly call getSomething()/setSomething() if you want (a minor advantage in my opinion).
 2. The "obj.prop(args)" ambiguity goes away.  *Either* obj.prop is a
 normal method function and (args) are passed to it, *or* obj.prop has
 the "property" attribute, and (args) are passed to its result.  Stuff
 like "obj.prop[i]" is the same way.
Either obj.prop binds to a real function, or it isn't really there and the compiler maps it to getProp/setProp as needed. Same thing for "obj.prop[i]", which would be equivalent to "obj.getProp()[i]" if there is no "prop" member in "obj". So both proposals are as good in this respect.
 3. There is no naming ambiguity.
A set/get prefix removes pretty much all ambiguity too. I mean, the current syntax is "T transform()" and you can't know if transform is a noun or a verb. With my prefix it's "T getTransform()" which makes it pretty clear what it does. With yours it's "property T transform()" and it's pretty clear too.
 4. There are no case issues.
Indeed. +1 for your proposal.
 5. It provides useful semantic information to tools, IDEs, and reflection.
With a get/set prefix too you can get useful information about what you can set and get too. Sure you assume that get means get and set means set, just like you assume that everything using the property keyword is really meant to be a property with your proposal. (Both systems can be abused as easily, that's my point.)
 6. It's nonintrusive and self-documenting.
I'm not sure if you'd find a get/set prefix non-intrusive or not (I don't), but I find it as self-documenting as a property keyword. And to compensate that +1 for you above, I'd point out that there is an alternative with no case issue (get_thing/set_thing) and that your proposal requires a keyword. I have nothing against your proposal. I prefer the aestetics of mine and I believe they're both pretty equal on technical ground.
 The *only* technical issue I can come up with is if you had "property
 ref X foo()", where foo returned a reference to some value type.  Then
 you do "&obj.foo" - what does this get the address of?  To that end, I
 suggest that &obj.foo always gets the address of the member or method
 'foo' from object 'obj', and &(obj.foo) would get the address of the
 return value of obj.foo.  The extra parens in there say "really, I
 want you to evaluate the thing inside *first*".
Interesting. That's a problem that doesn't exist with with the naming convention proposal. About your idea, I find it confusing that (&something) and &(something) may not have the same meaning. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Aug 01 2009
parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, Aug 1, 2009 at 4:01 PM, Michel Fortin<michel.fortin michelf.com> wrote:

 3. There is no naming ambiguity.
A set/get prefix removes pretty much all ambiguity too. I mean, the current syntax is "T transform()" and you can't know if transform is a noun or a verb. With my prefix it's "T getTransform()" which makes it pretty clear what it does. With yours it's "property T transform()" and it's pretty clear too.
class X { int foo; int getFoo() { return 5; } int blah() { return foo; /* um.. which? */ } }
 And to compensate that +1 for you above, I'd point out that there is an
 alternative with no case issue (get_thing/set_thing) and that your proposal
 requires a keyword.
Then let's introduce annotations and be done with it. No more pure, shared, __gshared, nothrow, and probably a whole slew of other silly attribute keywords.
 About your idea, I find it confusing that (&something) and &(something) may
 not have the same meaning.
That's true. Then again, how often do you need to get the address of a returned ref value?
Aug 01 2009
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-08-01 17:38:46 -0400, Jarrett Billingsley 
<jarrett.billingsley gmail.com> said:

 On Sat, Aug 1, 2009 at 4:01 PM, Michel Fortin<michel.fortin michelf.com> wrote:
 
 3. There is no naming ambiguity.
A set/get prefix removes pretty much all ambiguity too. I mean, the current syntax is "T transform()" and you can't know if transform is a noun or a verb. With my prefix it's "T getTransform()" which makes it pretty clear what it does. With yours it's "property T transform()" and it's pretty clear too.
class X { int foo; int getFoo() { return 5; } int blah() { return foo; /* um.. which? */ } }
Ok. There's two fronts on "ambiguity". You can have ambiguity in meaning, that's what I was talking about. By writing "setTransform()"/"getTransform()" you remove that ambiguity about "transform" being either a noun (property) or a verb (action). Having a keyword property does also removes that ambiguity. That's what I was talking about. Your example describe a syntaxic ambiguity when there's already a symbol named with the property name. There is a few way to solve that ambiguity: 1. Make it ambiguous (thus an error) to invoke foo at all. 2. Make foo, the variable, shadow the property. 3. Make the property shadow the variable. Number 3 is a bad idea because you have absolutely no way to access the field, even from inside the getter and setter. I'm not sure 2 is safe with multiple imported modules and with classes hierarchies. Number 1 is much restrictive, but you know when you're doing something fishy. - - - That said, a property keyword may also have some overloading problems to solve; it can't behave excaty as a function: class X { property void delegate(float) foo() { ... } property void foo(void delegate(float) f) { ... } void foo(float f) { ... } void blah() { foo(1.0); } // what is this? } You'll need a rule to forbid overloaded functions that mix property and non-property. That is, in class X and any derived class. Also, overload sets accross modules will need to be revised to become ambiguous when not all members are properties or non-properties. For instance, this would need to become ambiguous: module a; property void delegate(int) foo(); module b; int foo(float); module c; import a, b; unittest { foo(1); // which one? } This applies to a "getFoo()" syntax too.
 And to compensate that +1 for you above, I'd point out that there is an
 alternative with no case issue (get_thing/set_thing) and that your proposal
 requires a keyword.
Then let's introduce annotations and be done with it. No more pure, shared, __gshared, nothrow, and probably a whole slew of other silly attribute keywords.
To me, wether the keyword is "property" or a " property" annotation, I don't really care, both are fine with me. I still find "getFoo()"/"setFoo()" simpler and aesthetically better, but as I said before, the property keyword (be it a keyword or an annotation) is acceptable to me.
 About your idea, I find it confusing that (&something) and &(something) may
 not have the same meaning.
That's true. Then again, how often do you need to get the address of a returned ref value?
Every time you want to pass it to a C API. That said, perhaps I have a solution for that problem. The compiler could be smart about it, just like it already is when you take the address of an overloaded function: it could check if the variable you put the address into match the type of the property in addition to the type of the setter and the type of the getter. property ref int something(); property void something(int s); int delegate() getter = &something; // address of getter void delegate(int) setter = &something; // address of setter int* value = &something; // address of returned ref value Obviously, this doesn't work with auto, but that's a general problem with overloading, not something inehrent to properties. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Aug 01 2009
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:
 We can't throw keywords at problems like they're getting out of style. 
 I've noticed that here every little problem gets solved by a little 
 keyword. If not, some arcane new syntax.
I agree, attributes (or something like that) are a better solution to this (and other) problem. Anyway, this discussion is going in circles :-) Bye, bearophile
Aug 01 2009
parent reply aarti_pl <aarti interia.pl> writes:
bearophile pisze:
  > I agree, attributes (or something like that) are a better solution 
to this (and other) problem.

What you mean saying "attributes"? Probably I missed some posts...

BR
Marcin Kuszczak
(aarti_pl)
Aug 01 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
aarti_pl:
 What you mean saying "attributes"?<
See for example: http://en.wikipedia.org/wiki/Java_annotation It's not an esoteric thing, It's a way to add some extra semantics to a program. In a low-level language like D there are other possible purposes for annotations/attributes (that aren't useful in Java), you can add semantics that helps avoid bugs or can be used by the optimizer to increase the efficiency of the compiled program (GCC too has some of such function/variable attributes), I can show some examples. Bye, bearophile
Aug 01 2009
parent reply aarti_pl <aarti interia.pl> writes:
bearophile pisze:
 aarti_pl:
 What you mean saying "attributes"?<
See for example: http://en.wikipedia.org/wiki/Java_annotation It's not an esoteric thing, It's a way to add some extra semantics to a program. In a low-level language like D there are other possible purposes for annotations/attributes (that aren't useful in Java), you can add semantics that helps avoid bugs or can be used by the optimizer to increase the efficiency of the compiled program (GCC too has some of such function/variable attributes), I can show some examples. Bye, bearophile
Thanks for answer! I know Java annotations - I just didn't know what you meant saying "attribute". BR Marcin Kuszczak (aarti_pl)
Aug 01 2009
parent Ary Borenszweig <ary esperanto.org.ar> writes:
aarti_pl escribió:
 bearophile pisze:
 aarti_pl:
 What you mean saying "attributes"?<
See for example: http://en.wikipedia.org/wiki/Java_annotation It's not an esoteric thing, It's a way to add some extra semantics to a program. In a low-level language like D there are other possible purposes for annotations/attributes (that aren't useful in Java), you can add semantics that helps avoid bugs or can be used by the optimizer to increase the efficiency of the compiled program (GCC too has some of such function/variable attributes), I can show some examples. Bye, bearophile
Thanks for answer! I know Java annotations - I just didn't know what you meant saying "attribute".
always try to come up with the same things but with different names. :-P
Aug 01 2009