I was just working on some work code and noticed this line that I wrote a while ago:

public @property string userId(string file = __FILE__, size_t line = __LINE__) {


That's a getter, I always use it "getUser(userId);" etc..... but it "takes" two arguments.

If we require getters to have zero arguments, it will break this, and that will annoy me. We need to be careful about arbitrarily deciding something doesn't make sense and restricting it when there's no real technical reason for it.


(Wondering why I did this? If you aren't logged in, this throws a Not Logged In Exception. The file and line are passed to the exception constructor, meaning then the error message will tell me exactly where I forgot the nicer login check.

After wasting cumulative hours on similar problems in earlier iterations, I put this in there to eliminate that time sink.)

On Monday, January 28, 2013 00:18:15 Adam D. Ruppe wrote:
> I was just working on some work code and noticed this line that I wrote a while ago:
> 
> public @property string userId(string file = __FILE__, size_t
> line = __LINE__) {
> 
> 
> That's a getter, I always use it "getUser(userId);" etc..... but
> it "takes" two arguments.
> 
> If we require getters to have zero arguments, it will break this, and that will annoy me. We need to be careful about arbitrarily deciding something doesn't make sense and restricting it when there's no real technical reason for it.
> 
> 
> (Wondering why I did this? If you aren't logged in, this throws a Not Logged In Exception. The file and line are passed to the exception constructor, meaning then the error message will tell me exactly where I forgot the nicer login check.
> 
> After wasting cumulative hours on similar problems in earlier iterations, I put this in there to eliminate that time sink.)

I think that one of two things would be likely to happen were @property to stay and properly enforce that it be called with no parens:

1. Your function would be illegal because it had too many arguments.

2. It would be legal, but you could never call it with any arguments for file or line except the defaults, because there would be no syntactic way to do so.

But then again, if all you want is a getter and not a setter, and we allow optional parens to continue (which appears to be the case), then you wouldn't have to declare it as @property to get the syntax that you want. It just wouldn't be possible to guarantee that you could swap it out for a variable later without breaking code, since it would be possible for someone to call it with parens.

- Jonathan M Davis

On 01/27/2013 06:33 PM, Dicebot wrote:
> ...
> "unambiguous" == "I can understand semantics of code I have just read
> with as little additional context as possible"
> ...

In order to do that, it is necessary aware of the precise definitions, or at least specifications, of referenced declarations in any case. So by your definition, the current function call syntax is "unambiguous".

On 01/28/2013 12:34 AM, Timon Gehr wrote:
> On 01/27/2013 06:33 PM, Dicebot wrote:
>> ...
>> "unambiguous" == "I can understand semantics of code I have just read
>> with as little additional context as possible"
>> ...
>
> In order to do that, it is necessary

to be

> aware of the precise definitions,
> or at least specifications, of referenced declarations in any case. So
> by your definition, the current function call syntax is "unambiguous".

On Thu, 24 Jan 2013 03:34:42 -0500, Walter Bright <newshound2@digitalmars.com> wrote:

> This has turned into a monster. We've taken 2 or 3 wrong turns somewhere.
>
> Perhaps we should revert to a simple set of rules.
>
> 1. Empty parens are optional. If there is an ambiguity with the return value taking (), the () go on the return value.
>
> 2. the:
>     f = g
> rewrite to:
>     f(g)
> only happens if f is a function that only has overloads for () and (one argument). No variadics.
>
> 3. Parens are required for calling delegates or function pointers.
>
> 4. No more @property.

Disagree.  @property serves a very good purpose -- specifying intent.  If the intention of a function is to be used as a dynamic field, use @property, otherwise do not.

Whether or not parentheses should be required on non-@property functions, I've given up that struggle.  It's not too terrible, and the benefits are difficult to argue against.

But please, please, PLEASE do not let normal functions be called as setters.  If we get rid of @property, we are back to this.  Your simple requirements will leave too many functions open to abuse.  When you take away @property, you take away the expression power of an API designer.

I contend that the issue with @property was that it was half-implemented.  When a half-implemented feature is used for 4 years, it leads to confusion when it doesn't work as specified.

In other words, we asked you to build a fence.  You built one, but didn't finish it, left a gaping hole.  Then you complain about how the fence was useless.

I would be satisfied with Kenji's implementation.  As I understand it:

@property on a getter would mean implicit calling of the function.
@property on a setter would mean calling x = y as x(y).
@property functions could not be called like normal functions.
Parentheses are optional on normal no-arg functions when used as getters.
Normal single arg or variadic functions are NOT ALLOWED to be used as setters.

Do it.  I think 99% of the people here would be OK with this.

-Steve

On Mon, Jan 28, 2013 at 12:22:01AM -0500, Steven Schveighoffer wrote: [...]
> Disagree.  @property serves a very good purpose -- specifying intent.  If the intention of a function is to be used as a dynamic field, use @property, otherwise do not.
> 
> Whether or not parentheses should be required on non-@property functions, I've given up that struggle.  It's not too terrible, and the benefits are difficult to argue against.
> 
> But please, please, PLEASE do not let normal functions be called as setters.  If we get rid of @property, we are back to this.  Your simple requirements will leave too many functions open to abuse. When you take away @property, you take away the expression power of an API designer.
> 
> I contend that the issue with @property was that it was half-implemented.  When a half-implemented feature is used for 4 years, it leads to confusion when it doesn't work as specified.
> 
> In other words, we asked you to build a fence.  You built one, but didn't finish it, left a gaping hole.  Then you complain about how the fence was useless.
> 
> I would be satisfied with Kenji's implementation.  As I understand it:
> 
> @property on a getter would mean implicit calling of the function.
> @property on a setter would mean calling x = y as x(y).
> @property functions could not be called like normal functions.
> Parentheses are optional on normal no-arg functions when used as getters.
> Normal single arg or variadic functions are NOT ALLOWED to be used
> as setters.
> 
> Do it.  I think 99% of the people here would be OK with this.
[...]

+1.


T

-- 
May you live all the days of your life. -- Jonathan Swift

On Sunday, 27 January 2013 at 23:34:59 UTC, Timon Gehr wrote:
> In order to do that, it is necessary aware of the precise definitions, or at least specifications, of referenced declarations in any case. So by your definition, the current function call syntax is "unambiguous".

Sure, it is for compiler. And it for me if I check the definition of symbol. But without going to some other source file and looking up definition there is no way to guess if this:
-----
auto ret = something.anything;
-----
..actually does anything else but reassigning a field to a variable. In my personal experience time lost to check such stuff out is much more than time saved by fast and convenient parens-less coding. Thus the attitude.

On Sat, 26 Jan 2013 16:29:16 -0000, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 1/26/13 8:21 AM, Jacob Carlborg wrote:
>> On 2013-01-25 22:20, Andrei Alexandrescu wrote:
>>
>>> That's right with the amendment that we're looking for a solution, not
>>> pushing one. Even the title of the thread is a question.
>>>
>>> Clearly properties are good to have. In an ideal world we wouldn't need
>>> a keyword for them and we'd have some simple rules for determining
>>> property status (especially when it comes to writes). If syntactic help
>>> is necessary, so be it. We want to make the language better, not worse.
>>
>> It's always possible to avoid keywords in favor of syntax. Example:
>>
>> Declaring a getter:
>>
>> int foo {}
>>
>> Just as a regular function declaration but without the parentheses.
>>
>> Declaring a setter:
>>
>> void foo= (int value) {}
>>
>> Append an equal sign to the function name.
>
> This is interesting. I wonder how to make it work for UFCS functions (which _do_ have one argument).

Do the c# thing and use 'this'? i.e.

int foo(this Person p) {}
void foo= (this Person p, int value) {}

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Monday, 28 January 2013 at 08:14:45 UTC, Dicebot wrote:
> Sure, it is for compiler. And it for me if I check the definition of symbol.

However, as long as we have properties *at all* you'd have to check it. If we removed optional parens and put in C# style property syntax, it is still possible .anything is a function call.

On Monday, 28 January 2013 at 13:30:33 UTC, Adam D. Ruppe wrote:
> On Monday, 28 January 2013 at 08:14:45 UTC, Dicebot wrote:
>> Sure, it is for compiler. And it for me if I check the definition of symbol.
>
> However, as long as we have properties *at all* you'd have to check it. If we removed optional parens and put in C# style property syntax, it is still possible .anything is a function call.

No, I am repeating this again and again - when I see a property I need to think it is a variable. It is intended fooling of the reader and reason to have properties. Thus no checking in that case, I just assume it is a field or variable or anything like that.

And if I'll spend few days debugging the case that comes down to my colleague has designed a property that does not behave like a field - I'll go and politely ask to stop doing this. May be also will punch him. Problem solved.