Bruno Medeiros wrote:
> Bill Baxter wrote:
>>
>> ---
>> Somewhat unrelated, but there still exists the annoyance in D that if
>> you have to functions with the same name and you want to take the
>> address of one of them, you can't.  Furthermore I can't think of a
>> reasonable syntax to do that easily.  For that reason,  I really think
>> the best getter and setter functionality in D would be something where
>> you have distinctly named *functions* getProp and setProp for when you
>> want/need functions mirroring samely-named *properties* for which only
>> property syntax would work.
>>
> 
> Hum, that reminds me of an idea I once had for properties: not using a keyword, but only convention, just as the op* methods for operator overload. Basicly one writes a property with getter and setter functions, like Java:
> 
> class Foo {
>   SomeBar getSomeBar();
>   void setSomeBar(SomeBar someBar);
> }
> 
> one can then access those functions normally, like Java, but one would then also be able to use a property with the same name of the getter/setter methods, but without 'get' or 'set', and with the capitalization of the first letter fixed, like this:
> 
>   Foo foo = ...;
>   SomeBar someBar = foo.someBar;
>   //same as: SomeBar someBar = foo.getSomeBar();
> 
>   foo.someBar = new SomeBar();
>   //same as: foo.setBar(new SomeBar());
> 
> This makes it easy to use Java-style code (for instance when porting Java code, or using libs like DWT, etc.).
> What I don't like here, is that this solution involves working with the capitalization/CamelCase of the property, which doesn't sound right. And what about properties that start with a capital letter?... :(

What's going on now is pretty much that except that there's no more symbol changing - it's just someBar() and someBar(SomeBar).

Andrei

"Michel Fortin" wrote
> On 2008-09-30 09:42:43 -0400, "Steven Schveighoffer" said:
>
>> "Michel Fortin" wrote
>>> On 2008-09-29 12:55:18 -0400, "Steven Schveighoffer" said:
>>>
>>>> Stdout.newline.formatln("Hi there {}", var);
>>>>
>>>> Is newline a property of Stdout, on which I'm calling formatln, or is newline a function that I'm calling, and then using the result of that function to call formatln?  Compare with:
>>>>
>>>> Stdout.newline().formatln("Hi there {}", var);
>>>>
>>>> There is no ambiguity.  newline is clearly a function, not a property.
>>>
>>> Interesting. To me both of these things have exactly the same meaning.
>>> Perhaps it's because I'm used to D, but I think it's more because I
>>> can't
>>> count how many times I've seen this pattern in C++:
>>>
>>> SomeSimgleton::Instance().doSomething();
>>>
>>> where Instance() is simply an accessor.
>>
>> Yes, that is a workaround for not having property constructs available.
>> The
>> intuitive label of 'property' comes from the name of the getter
>> 'Instance'.
>> It screams that you are getting the instance of the class, and it's well
>> accepted as a property.  What has happened is that instead of relying on
>> the
>> compiler to enforce what is a property and what is not, you are relying
>> on
>> the interpretation of English words.
>
> But one problem is that the distinction between a accessor (of a property) and a function is often matter to interpretation. In the case above, most likely the Instance() function will create the singleton object if it doesn't exist yet; seen that way it isn't a simple accessor. If you ask if Instance() should be a property or not, you're likely to get different answers from different people.

The difference is syntax-implied meaning.  A property is a field implemented as a function.  It is a form of information hiding and imposing access on a field, which could be a virtual field.  By specifically defining properties, I'm telling you, 'this is a field.  Access it like a field.  pay no attention to how the field is constructed, or whether it is actually a field or not'.  This allows me to later on make it a true field if it seems like the right decision.  Or to specify a guarantee about properties.

The other way around is already possible.  I can take a field that is already in use and make it into a property.  But the reverse is not so easy. Anyone who has accessed the field using parentheses would now have to go back and change all their code to remove the parentheses.

For example, with the magic of static constructors, I can change Instance from a property to an actual field, by initializing it in a static constructor.  Now every place you use Instance() (and there's probably a lot of them) is now invalid code.  If the *required* method of accessing Instance is without parens, then you notice no differences, and the interface to Instance remains the same.

As far as interpreting code, with the current state of affairs a function can be called like a field, which makes things more difficult to decipher. What is this symbol supposed to be?  It becomes an interpretation of the actual words used, which I don't argue isn't part of the equation anyways, but leaving it completely up to that is not as precise.  I have a real world example where someone thought a static constructor method I wrote was actually a property setter.  See this bug in Tango: http://www.dsource.org/projects/tango/ticket/1184  I never intended the static constructor to be a property, but it just works that way because the compiler matches the developer's request for a setter property by finding a static function which does nothing like the developer intended.  So it's a very hard bug to solve, and we couldn't solve it in the way I wanted, because the compiler cannot be forced not to look at all functions as possible properties.

I agree that there is a subjective line as to what makes a property and what does not.  What I propose is that we put the control of that line in the hands of the author, not the hands of the user.  If the author thinks it's better used as a property, that is their call.  It shouldn't be up to the user to say 'hey, I thought you meant function() here, you can't change it now!'  It's the same concept behind interfaces.

> Arguably, there are cases even more ambiguous than this one. The issue I want to bring is that without having a formal definition of what is a property and what is not -- one the compiler can enforce -- people will make different choices, not always coherent with each others, and you may very well find yourself having to call Instance() with parenthesis in one D lib and without parenthesis in another.

You end up with that situation anyways.  If you have a project written by more than one person, one developer might use parens, one might not for the *same library* not just different libraries.  Hell, I use the same function sometimes as property or function depending on how much I'm paying attention.  I don't like the inconsistency that allowing all noarg functions to potentially be properties fosters.

At least with a formal definition, the user of the lib knows what the author was trying to create, and uses the property in a forwards-compatible fashion.

>> But in a language like C#, you would define Instance as a property, not a function.  So it would never look like that.
>
> I could, but should I?
>
> I'm very interested in your criterions about why Instance would qualify to be a property and not as a function in this case.
>
> It's not just me. Just as an example, this article's author doesn't want
> to decide if Instance() should be a property or not:
> <http://www.yoda.arachsys.com/csharp/singleton.html>
> "Note that all of these implementations also use a public static property
> Instance as the means of accessing the instance. In all cases, the
> property could easily be converted to a method, with no impact on
> thread-safety or performance."

I guess what I should have said is that I would make it a property ;) Sometimes it's hard to envision a different point of view, but you are absolutely right, it could be considered a function instead.

My definition of what I would like to see in an accessor (mind you, this is my definition, and would only be valid for libraries I wrote.  Someone else could have a different definition, and that's fine with me) is something that consistently returns a value.  So if I called it twice without anything changing, it would return the same thing, and accessing it doesn't change what it returns next time.

So Instance qualifies because once it is constructed, it always returns the same thing.  Perfect example of a use for an accessor property (to me anyway).

If two different libraries use different accessing methods for Instance, that's fine.  At least it's consistent.  You are going to have a hard time enforcing design decisions over all the different libraries you use to be consistent.  But at least they should be consistent every time you use them.

>> In D, properties are equivalent to functions, so you have a choice as to whether to use the parentheses or not.  But that isn't the problem, the problem is really that you can call functions as properties.
>
> But what is the difference between a property and a function (beside the syntax?). I can find countless discussions on the net about this; interesting discussions but with no definitive answer. In the end, it all boils down to the author's feeling about his function/property, which may be the opposite from its user's.

The difference is the interface.  Which is the syntax, and that is important to me at least.  If you don't like the authors usage of properties, don't use the lib.  I don't see any other aspect of library design that leaves it up to the user as to how their functions/objects should be interfaced.  Why should the user be allowed to decide the property/function interface?

> I'd like very much to quote Bruce Wood from this discussion: <http://bytes.com/forum/thread478064.html>
>
> (feel free to comment the quote)
>
> """
> You see, it's not always so cut-and-dried.
>
> On the one hand, if you make something a property, you are implying that getting the information will be quick. So, if getting the information is slow, that is a hint that it shouldn't be a property.

This is the opinion of the author (and I have the same opinion), but it's not written in stone.  The only things that are written in stone (or I guess binary) are what the compiler guarantees.  These kinds of debates have no real true answer, so there is no way to enforce.  How would you enforce it anyways?

But you can enforce the interface, and that's what I want.

> On the other hand, you don't want to determine what is a property or not based upon implementation details. By doing so you're letting the internal guts of how your class works leak out into its interface with the outside world. That's bad style. So, something should be a property if it makes sense that it be a property.
>
> Certainly, anything that affects the state of the object in a manner more sophisticated than just "set this to that" should be a method. That's painfully obvious.

I disagree with that ;), but then again that's my opinion and there is no right answer.

> Similarly, an aspect of your class that can be read and set, even if setting it does more than just set a variable, should probably be a property. Reasonably straightfoward.
>
> However, sometimes the two design goals above-properties that return results quickly and not letting implementation determine interface-are at odds with each other, and you have to make a judgement call.
>
> In the case of my system, I had things that logically should be properties (from an interface point of view) but the object held only keys, not references to the objects themselves, so the "get" on the property has to fetch the object in question from the database. It was an open question whether to code:
>
> Supplier theSupplier = stockItem.Supplier;
>
> or
>
> Supplier theSupplier = stockItem.GetSupplier();
>
> I chose the former, preferring to hide the implementation (holding
> supplier UID, not supplier itself) rather than let it leak out that
> getting the supplier was actually a lot of work. In our case it's no
> problem, because we're a very small shop. In a different situation I
> might have gone for door #2.
> """

In my opinion, I'd always go for door #1 in that case.  But I'd probably use some sort of cache, where the lookup was implemented as a function, and the access of the value was done as a property afterwards.

> With the current approach in D, you just don't need to choose, just document what your function/property is doing and be done with it... well you may still have to choose about the name :-), so in a way the argument is still there, but what I mean is that I don't think we really need a black and a white syntax for one concept that may take many shades of gray.

We don't need a formal definition of what should or should not be a property.  But we need to allow the author to define what should or should not be a property.  Without doing this, you are making the interface inconsistent or ambiguous -- even if only from a syntax point of view.

>>> In my opinion, "newline" isn't a good function name for what it does
>>> because it has no verb. Having no verb makes it look like an accessor
>>> much
>>> more than the absence or presence of parenthesis.
>>
>> So newline() seems like a property to you more than 'start a new line'?
>> I
>> suppose I can see that, but consider if you were used to a system where
>> properties *prohibited* parentheses, and functions *required* them.  It
>> becomes less about interpretation of English vocabulary and more about
>> compiler-enforced interface.  I like that system better.
>
> But I'm still puzzled by what being a property means in opposition as if it was a function.
>
> The thing is that the compiler just can't guaranty anything about properties: it's really just another syntax for calling a function, a function the author has classified as a property by some subjective standard, a standard which will often differ between authors. Properties are often touted as an indicator for low-cost functions -- whatever "low-cost" means --, but even this fuzzy standard somewhat hinder the often seeked goal of separating interface and implementation.
>
> Without aggreement on a formal definition for properties and compiler enforcability, I find it very difficult to justify a formal syntax for properties.

But you have no problems allowing a library author to define what is an interface and what is a class?  Or what is a struct?  Or if a function should return by value or by reference?  Defining the interface is the job of the author, and the very very good reason behind that is so the author can change details without changing the interface to make upgrades easier for him *and* you.  If he cannot define the interface, then he cannot make changes without affecting someone.

-Steve

Andrei Alexandrescu wrote:
> Bruno Medeiros wrote:
>> Bill Baxter wrote:
>>>
>>> ---
>>> Somewhat unrelated, but there still exists the annoyance in D that if
>>> you have to functions with the same name and you want to take the
>>> address of one of them, you can't.  Furthermore I can't think of a
>>> reasonable syntax to do that easily.  For that reason,  I really think
>>> the best getter and setter functionality in D would be something where
>>> you have distinctly named *functions* getProp and setProp for when you
>>> want/need functions mirroring samely-named *properties* for which only
>>> property syntax would work.
>>>
>>
>> Hum, that reminds me of an idea I once had for properties: not using a keyword, but only convention, just as the op* methods for operator overload. Basicly one writes a property with getter and setter functions, like Java:
>>
>> class Foo {
>>   SomeBar getSomeBar();
>>   void setSomeBar(SomeBar someBar);
>> }
>>
>> one can then access those functions normally, like Java, but one would then also be able to use a property with the same name of the getter/setter methods, but without 'get' or 'set', and with the capitalization of the first letter fixed, like this:
>>
>>   Foo foo = ...;
>>   SomeBar someBar = foo.someBar;
>>   //same as: SomeBar someBar = foo.getSomeBar();
>>
>>   foo.someBar = new SomeBar();
>>   //same as: foo.setBar(new SomeBar());
>>
>> This makes it easy to use Java-style code (for instance when porting Java code, or using libs like DWT, etc.).
>> What I don't like here, is that this solution involves working with the capitalization/CamelCase of the property, which doesn't sound right. And what about properties that start with a capital letter?... :(
> 
> What's going on now is pretty much that except that there's no more symbol changing - it's just someBar() and someBar(SomeBar).

Pretty much, but not exactly the same, because in this way you can't distinguish a property from a normal method call. The idea is to be able to distinguish two different concepts: properties and "procedures".

> 
> Andrei
> 

Andrei Alexandrescu wrote:
> Bruno Medeiros wrote:
>> Andrei Alexandrescu wrote:
>>> Bill Baxter wrote:
>>>> On Tue, Sep 30, 2008 at 4:08 AM, KennyTM~ <kennytm@gmail.com> wrote:
>>>>> I think the distinction of with and without () is pretty stylistic, because
>>>>> the same argument can even be applied to operator overloading (does a=b
>>>>> means pointing the variable a to b, or calling a.opAssign(b)?)
>>>>>
>>>>> For me, I would use () if the function do modify the object itself.
>>>>
>>>> I think the counter-argument to what I just said is that if properties
>>>> had to be declared explicitly then at least we would know that .y is
>>>> either a field or else something the designer *intended* to behave
>>>> like a property.  Which does tell us something.  It most likely means
>>>> that it's not an extremely heavy-weight operation, just a lightweight
>>>> accessor with maybe a little logic on top.  That could be wrong, but
>>>> in that case it's the class designer's fault for misleading us.
>>>
>>> So the logic is:
>>>
>>> "A field can be accessed with a.b, but not with a.b(). Therefore if someone writes a.b, it may be a field or code, but it someone writes a.b() it will always be code. Given that a field is cheap and code ranges from cheap to expensive, good style is to have a.b always refer to cheap stuff, and a.b() always refer to not-expected-to-be-cheap stuff."
>>>
>>> I agree with that logic. It makes for a nice convention. (That convention is already broken by the built-in dup and sort, but let past mistakes be past mistakes.) My response to that is that concerns of keeping the language simple and of facilitating generic code are counterarguments that should be weighed in as well.
>>>
>>
>> In what way does that convention/style go against facilitating generic code?
> 
> A generic function writing obj.symbol cannot work across objects that implement symbol as a computed property vs. a field.
> 
> 
> Andrei

I'm not following. If 'obj.symbol' is syntactically available and is valid code, shouldn't the generic function work ok regardless of whether 'symbol' is a computed property or a field?
I mean, what is even the difference from the status quo?

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Andrei Alexandrescu Wrote:

> No. Not at all. For consistency you must assert together something with something else. If there are two possible and equivalent syntaxes for a feature that's not lack of consistency. It's waste. We'd be talking about consistency if at most "syntax in context A should be the same as syntax in context B". But if the context is irrelevant to the syntax then we're not quite talking about consistency.

Consistency or economy of syntax I think you are avoiding the issue which is that we need something that fulfills our requirements.

And those are:

* A way to specify that one or two functions behave exactly as a field without ambiguity. (Assignment, reading, taking an address, etc.)

* A way to specify that a function doesn't behave as a field:

writelfn = 3;

* A way to change from field to property and back without silently affecting client code (which might be out of our control).

* And some others that I can find right now.

Until now the only proposal that fits these requirements involves adding another keyword which you are reluctant to accept.

Personally I prefer the python property decorator but I don't think it fares well with the D style:

|    @Property
|    def name:
|        def fget():
|        def fset():
|        def fdel():

Probably something along the lines of C# 3.0 property declaration its better suited for D:

|    public string Name { get; set; }

And I don't think that backwards compatibility is an issue on D2. We already have several breaking changes (cost, invariant, et al) and this is an easy one to fix.

Cheers.


PS: On second reading the post has something of a harsh tone but please be assured that this isn't a personal attack. English isn't my first language.

Andrei Alexandrescu wrote:
> Bruno Medeiros wrote:
>> Andrei Alexandrescu wrote:
>>> Benji Smith wrote:
>>>> Andrei Alexandrescu wrote:
>>>>> I stated two principles of language design. They could be true or false. They are up there for debate. They are subjective, because aside from some basics, language design is subjective.
>>>>>
>>>>> The principles are:
>>>>>
>>>>> 1) A language should minimize the number of syntactic constructs that are semantically and/or pragmatically meaningless.
>>>>>
>>>>> 2) The more frequently-used constructs should be given syntactic priority over the less-used constructs, particularly when the latter are also at risk of breaking the first principle.
>>>>
>>>> I'd like to propose another principle of language design:
>>>>
>>>> 3) Consistency -- The expression of a semantic construct should always use the same syntax. Likewise, multiple uses of the same syntactic constructs should always result in the same semantics.
>>>
>>> Consistency is good, but that's not consistency.
>>>
>>> http://www.merriam-webster.com/dictionary/consistency
>>>
>>> agreement or harmony of parts or features to one another or a whole :
>>> correspondence  ; specifically : ability to be asserted together without
>>> contradiction
>>>
>>
>> The concept of "consistency" has a more specialized meaning when applied to language design. (just has it has in other fields, like mathematics)
>> So I agree with benji that not having "The expression of a semantic construct should always use the same syntax" is not being consistent. (There are of course other situations where things can be inconsistent.)
> 
> No. Not at all. For consistency you must assert together something with something else. If there are two possible and equivalent syntaxes for a feature that's not lack of consistency. It's waste. We'd be talking about consistency if at most "syntax in context A should be the same as syntax in context B". But if the context is irrelevant to the syntax then we're not quite talking about consistency.
> 

I wasn't talking about the two cases of calling a zero-args function with parenthesis, and calling it without parenteshis (the "two possible and equivalent syntaxes for a feature"). That's not inconsistency, it's waste, I agree.
I was talking about the two cases of calling a zero-args function ("context A"), and a n-args function ("context B"). So here we can talk about consistency, like you defined: "syntax in context A should be the same as syntax in context B". As such, the syntax for both cases is more consistent if they both use parenthesis.

> 
>> If you don't agree with this definition of "consistency", I'm not gonna argue with that , just substitute it with "conzistency" or "foobar", or whatever and proceed.
> 
> No. Defining terms is important. If we have the wrong terms in mind when talking about something, communication is impeded.
> 

I agree.

>>>> Based on that principle, I'd argue that function-calling should either always use parentheses, or it should never use parentheses.
>>>
>>> Yah I'd like that too. It's economy of syntax.
>>>
>>
>> Then why are you not suggesting, or campaigning for, such change?
> 
> Because language design is putting many desiderata in agreement, not following one blindly.
> 

I don't get it. What other desiderata are in conflict? Those of other people, or other desiderata of your own? Because when you say "I'd like that too", I read that as meaning that, at least for your own, you would prefer if such change was implemented. (ie, weighting all your concerns, you still prefer the change)

>>>> Requiring parentheses for some function calls, but not for others violates the principle of consistency.
>>>
>>> No. It violates economy of syntax. There are many syntaxes for the same
>>> semantics. 
>>
>> It violates consistency, as defined above.
> 
> No. You can't define a term to mean whatever you want. I mean you can, but then it's hard to communicate.
> 

By "some functions" I meant n-args functions, and by "others" I meant zero-args functions. That gives: "[Putting] parenthesis for n-args function calls, but not for zero-args function calls violates the principle of consistency."
So we go back to the first point in this post.

>> It may violate economy of syntax as well (or it may be the same thing). Whatever. What I ask is, what would you suggest to fix it? Should all function calling not use parenthesis? And how would that syntax be?
> 
> I'm happy with how things are now except for the assignment that is accepted all to often. I suggested a simple fix for that.
> 
> 
> Andrei

I don't understand that. You stated "It violates economy of syntax.", so  it violates your Principle 1 of language design. So how can you be happy with that (apart from the assignment issue)? Does fixing this problem violate some other principle or concern of yours?

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Andrei Alexandrescu wrote:
> Bruno Medeiros wrote:
>> Sergey's argument (which is much more objective than subjective) is not strictly against omitting parenthesis, but rather against ambiguity (the dual possible ways to call zero-args functions), which as has been shown, creates various possibilities for bugs when you mix functions that return delegates. This ambiguity problem would also be resolved if omitting parenthesis would be *the only way* of calling functions with zero-args.
> 
> Yah, he made great points. There are ambiguities. The counter-argument is that that would make the syntax of calling functions with no arguments inconsistent with the syntax of calling function with arguments. The "()" is a degenerate case of "(a, b, c)". So it's hard to keep everybody happy.
> 

Yes, if we solved the ambiguity problem that way, we would make a lot of people unhappy (myself included). But if we solved the problem the *other way* (forbidding omittable parenthesis for normal zero-args function), it would make, that I know of, only one person unhappy (you).

Note that this would not preclude that we implement another way to have properties (see below).

> 
>> These other principles are:
>>
>> 3 - Consistency of syntax - The same language feature should use the same syntax, with as little variations as possible.
>  >
>> This principle fails here because when you have functions with parameters you have to use parenthesis, and only when you don't have arguments you omit the parenthesis. But the zero-args case should not be different from the n-args case. Of course, this could be solved by having a syntax for the n-args case that also doesn't use parenthesis (see my OP after Benji's thread)
> 
> Great. Yes, that is consistency. I swear that all I wrote above was before I saw this :o).
> 

Good, at least we agree on that after all.


>> But most importantly:
>> 4 - Common ground with other programming languages. There are several things that are common with many, if not all, of the mainstream programming languages (Java, C#, C/C++, Ruby, Python, etc.).
>> One of them is using parenthesis for calling functions! (See KennyTM's post with the table describing function calling for several languages.) Using parenthesis comes from math. And of that list, only VB 6, Pascal and Perl, have the possibility of omitting parenthesis. And frankly, VB6 and Pascal don't matter since they are pretty much obsolete. And Perl is language with a hack-ish nature, IMO. Even Lisp uses parenthesis for function calling! (even if in a different position, and even if it's pretty much the only syntax it has).
>> This is a subjective principle, I can't tell you to want to like having common ground with other languages, but c'mon... "writeln;"? Seriously?? That's just hideous.
> 
> I agree that 4 is a good principle. I'd even call it "consistency" - across languages that is. But let's not forget that C# defined an entire feature - properties - to fulfill what was perceived as a need. Also the Cecil language goes as far as requiring accessors for any field (and defining methods implicitly when missing). Eiffel also has properties that are obtained via syntactic conventions (getX and setX implement property x). People want to add properties to Java 7 (unfortunately the google search is clogged by a Java class called Properties so it needs some combing).
> 

Yes, I was going to call it "consistency with other programming languages", but renamed it so as to avoid confusion.
Anyways, we're not saying a properties feature is not useful. We're not saying to just remove the implicit property function call and be done with that. The suggestion is to *replace* the implicit property function call with some other way for implementing properties, so that we don't have the disadvantages of the implicit property function call.


> Eiffel also has properties
> that are obtained via syntactic conventions (getX and setX implement
> property x)

Hum, interesting, I just replied in another part of the thread with a suggestion that is just like that (and didn't know about it).

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

"Bruno Medeiros" wrote
> Andrei Alexandrescu wrote:
> > Eiffel also has properties
> > that are obtained via syntactic conventions (getX and setX implement
> > property x)
>
> Hum, interesting, I just replied in another part of the thread with a suggestion that is just like that (and didn't know about it).

In fact, C++.net did something similar in that if you defined a property x in C#, it really defined two hidden functions, get_x() and set_x() that could be called from C++.

But the new C++.net is much better, you can actually use and define real properties.

I consider this type of thing a hack, that probably shouldn't be used since we are talking about a developing language and not something that has decades of real-world use.  I personally think it was one of those Microsoft marketing things where they made C++.net so it could interact with other languages, but made it so ugly that you perceived C# as being soo much better ;)  But that's just the cynic in me.

All that is needed is a keyword to signify that a function is really a property, kind of like 'pure', and enforce the rules that have been discussed.  Since D2 is already getting new keywords and is almost backwards-incompatible with existing D1 code, I don't see this as a huge issue.

The other option is to do something funky with the syntax, like C# does (note that get, set, and value are contextual keywords in C#, so their keyword status is not universal):

int myproperty
{
  get
  {
      return _myprivateproperty;
  }
  set
  {
      return _myprivateproperty = value;
  }
}

In light of some other posts about overloading the set operators, I think actually it might be nicer to define set as a contextual function inside a property:

int myproperty
{
  get
  {
      return _myprivateproperty;
  }
  set(int value)
  {
      return _myprivateproperty = value;
  }
  set(string value)
  {
      return _myprivateproperty = to!(int)(value);
  }
}

I'm not a language designer, so I don't know if this falls within the rules of D grammar, but I definitely think this is one of the gems of C# syntax (note, no idea if C# invented this, but it's the first time I saw it).

The downside is that you can't really take addresses of the set/get functions, or could you with something like &myproperty.set?  That would be one reason to make the set/get symbols keywords.

-Steve

Ian Sakkis wrote:
> PS: On second reading the post has something of a harsh tone but
> please be assured that this isn't a personal attack. English isn't my
> first language.

Then revision before posting might have been an option. There's no "me" against "we". This is ridiculous. If a cabal was being created, please mail me the application papers.

Andrei

Bruno Medeiros wrote:
> Andrei Alexandrescu wrote:
>> Bruno Medeiros wrote:
>>> Andrei Alexandrescu wrote:
>>>> Bill Baxter wrote:
>>>>> On Tue, Sep 30, 2008 at 4:08 AM, KennyTM~ <kennytm@gmail.com>
>>>>> wrote:
>>>>>> I think the distinction of with and without () is pretty stylistic, because the same argument can even be applied to
>>>>>> operator overloading (does a=b means pointing the variable
>>>>>> a to b, or calling a.opAssign(b)?)
>>>>>> 
>>>>>> For me, I would use () if the function do modify the object
>>>>>> itself.
>>>>> 
>>>>> I think the counter-argument to what I just said is that if
>>>>> properties had to be declared explicitly then at least we
>>>>> would know that .y is either a field or else something the
>>>>> designer *intended* to behave like a property.  Which does
>>>>> tell us something.  It most likely means that it's not an
>>>>> extremely heavy-weight operation, just a lightweight accessor
>>>>> with maybe a little logic on top.  That could be wrong, but in that case it's the class designer's fault for misleading
>>>>> us.
>>>> 
>>>> So the logic is:
>>>> 
>>>> "A field can be accessed with a.b, but not with a.b().
>>>> Therefore if someone writes a.b, it may be a field or code, but
>>>> it someone writes a.b() it will always be code. Given that a
>>>> field is cheap and code ranges from cheap to expensive, good
>>>> style is to have a.b always refer to cheap stuff, and a.b()
>>>> always refer to not-expected-to-be-cheap stuff."
>>>> 
>>>> I agree with that logic. It makes for a nice convention. (That
>>>>  convention is already broken by the built-in dup and sort, but
>>>> let past mistakes be past mistakes.) My response to that is
>>>> that concerns of keeping the language simple and of
>>>> facilitating generic code are counterarguments that should be
>>>> weighed in as well.
>>>> 
>>> 
>>> In what way does that convention/style go against facilitating generic code?
>> 
>> A generic function writing obj.symbol cannot work across objects
>> that implement symbol as a computed property vs. a field.
>> 
>> 
>> Andrei
> 
> I'm not following. If 'obj.symbol' is syntactically available and is
>  valid code, shouldn't the generic function work ok regardless of
> whether 'symbol' is a computed property or a field?

What I meant is very simple. Generic code benefits from unified syntax.
Going with one convention across the board would make generic code
simpler. Going with the convention that expensive stuff is with "()" and cheap stuff is without "()" differentiates usage.

> I mean, what is even the difference from the status quo?

The discussion was about how things should behave in the future. If you ask me, I can live with the status quo save for the writeln = 3 which could become a poster child of belittling D.


Andrei