View mode: basic / threaded / horizontal-split · Log in · Help
October 08, 2010
Uniform Function Call syntax for properties
Someone was asking about UFC syntax for properties on d.learn, and I  
realized, we have a huge ambiguity here.

Given a function:

@property int foo(int x)

Is this a global setter or a getter on an int?

i.e.

int y = foo = 3;

or

int y = (3).foo;

???

I know arrays have an issue with property setters, see a bug report I  
filed a while back:

http://d.puremagic.com/issues/show_bug.cgi?id=3857

But that seems like a totally unambiguous case (a global property function  
with two parameters is obviously a setter on the first parameter in UFC).

The getter seems much more problematic.  Does anyone have a solution  
besides adding more syntax?  Should we disallow global properties to avoid  
ambiguity?

-Steve
October 08, 2010
Re: Uniform Function Call syntax for properties
08.10.2010 16:55, Steven Schveighoffer пишет:
> Someone was asking about UFC syntax for properties on d.learn, and I 
> realized, we have a huge ambiguity here.
>
> Given a function:
>
> @property int foo(int x)
>
> Is this a global setter or a getter on an int?
>
> i.e.
>
> int y = foo = 3;
>
> or
>
> int y = (3).foo;
>
> ???
>
> I know arrays have an issue with property setters, see a bug report I 
> filed a while back:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=3857
>
> But that seems like a totally unambiguous case (a global property 
> function with two parameters is obviously a setter on the first 
> parameter in UFC).
>
> The getter seems much more problematic.  Does anyone have a solution 
> besides adding more syntax?  Should we disallow global properties to 
> avoid ambiguity?
>
What if we make @properties have first parameter as ref/ref const if 
it's meant to be part of UFC? This way we can keep module-scope 
properties and easily make UFC properties for existing types:

@property int foo(int x) { /*...*/ } // module-scope setter
@property int foo() { /*...*/ } // module-scope getter
@property int foo(ref int x, int v) { /*...*/ } // UFC 'setter' for int
@property int foo(ref int x) { /*...*/ } // or int foo(ref const int x) 
- UFS 'getter' for int

There's a caveat, though, as having ref/ref const would disallow doing 
thigs like 3.foo() (which makes perfect sense for 'setters', but not for 
getters.
October 08, 2010
Re: Uniform Function Call syntax for properties
On Fri, 08 Oct 2010 17:26:41 +0400, Stanislav Blinov <blinov@loniir.ru>  
wrote:

>   08.10.2010 16:55, Steven Schveighoffer пишет:
>> Someone was asking about UFC syntax for properties on d.learn, and I  
>> realized, we have a huge ambiguity here.
>>
>> Given a function:
>>
>> @property int foo(int x)
>>
>> Is this a global setter or a getter on an int?
>>
>> i.e.
>>
>> int y = foo = 3;
>>
>> or
>>
>> int y = (3).foo;
>>
>> ???
>>
>> I know arrays have an issue with property setters, see a bug report I  
>> filed a while back:
>>
>> http://d.puremagic.com/issues/show_bug.cgi?id=3857
>>
>> But that seems like a totally unambiguous case (a global property  
>> function with two parameters is obviously a setter on the first  
>> parameter in UFC).
>>
>> The getter seems much more problematic.  Does anyone have a solution  
>> besides adding more syntax?  Should we disallow global properties to  
>> avoid ambiguity?
>>
> What if we make @properties have first parameter as ref/ref const if  
> it's meant to be part of UFC? This way we can keep module-scope  
> properties and easily make UFC properties for existing types:
>
> @property int foo(int x) { /*...*/ } // module-scope setter
> @property int foo() { /*...*/ } // module-scope getter
> @property int foo(ref int x, int v) { /*...*/ } // UFC 'setter' for int
> @property int foo(ref int x) { /*...*/ } // or int foo(ref const int x)  
> - UFS 'getter' for int
>
> There's a caveat, though, as having ref/ref const would disallow doing  
> thigs like 3.foo() (which makes perfect sense for 'setters', but not for  
> getters.

C# uses 'this' keyword for that purpose:

@property int set(this int x, int y)
{
    x = y;
}


@property int get(this const(int) x)
{
    return x;
}

int a = 1;
a.set(42); // a is 42 now
3.set(42); // fails to compile, 3 is of type const(int)
October 08, 2010
Re: Uniform Function Call syntax for properties
On Fri, 08 Oct 2010 09:30:59 -0400, Denis Koroskin <2korden@gmail.com>  
wrote:
>
> C# uses 'this' keyword for that purpose:
>
> @property int set(this int x, int y)
> {
>      x = y;
> }
>
>
> @property int get(this const(int) x)
> {
>      return x;
> }
>
> int a = 1;
> a.set(42); // a is 42 now
> 3.set(42); // fails to compile, 3 is of type const(int)

Using this is a good idea, but I don't think we should automatically ref  
the value.  Also this is already a symbol name, can't we just use it?   
What I think might be a good idea is to *name* the target this, and then  
just allow the normal adornments to describe the type.  i.e.:

@property int set(ref int this, int y) {}

will work only for lvalues, whereas

@property int set(int this, int y) {}

works for rvalues also.  The

What do you think?

-Steve
October 08, 2010
Re: Uniform Function Call syntax for properties
On 10/8/10 7:55 CDT, Steven Schveighoffer wrote:
> Someone was asking about UFC syntax for properties on d.learn, and I
> realized, we have a huge ambiguity here.
>
> Given a function:
>
> @property int foo(int x)
>
> Is this a global setter or a getter on an int?

Good question.

Andrei
October 08, 2010
Re: Uniform Function Call syntax for properties
08.10.2010 17:46, Steven Schveighoffer пишет:
> On Fri, 08 Oct 2010 09:30:59 -0400, Denis Koroskin <2korden@gmail.com> 
> wrote:
>>
>> C# uses 'this' keyword for that purpose:
>>
>> @property int set(this int x, int y)
>> {
>>      x = y;
>> }
>>
>>
>> @property int get(this const(int) x)
>> {
>>      return x;
>> }
>>
>> int a = 1;
>> a.set(42); // a is 42 now
>> 3.set(42); // fails to compile, 3 is of type const(int)
>
> Using this is a good idea, but I don't think we should automatically 
> ref the value.  Also this is already a symbol name, can't we just use 
> it?  What I think might be a good idea is to *name* the target this, 
> and then just allow the normal adornments to describe the type.  i.e.:
>
> @property int set(ref int this, int y) {}
>
> will work only for lvalues, whereas
>
> @property int set(int this, int y) {}
>
> works for rvalues also.  The
>
> What do you think?
>
Looks tasty, and besides that's exactly how class/struct methods 
actually look.
October 08, 2010
Re: Uniform Function Call syntax for properties
"Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message 
news:op.vj9cunrweav7ka@localhost.localdomain...
> Someone was asking about UFC syntax for properties on d.learn, and I 
> realized, we have a huge ambiguity here.
>
> Given a function:
>
> @property int foo(int x)
>
> Is this a global setter or a getter on an int?
>
> i.e.
>
> int y = foo = 3;
>
> or
>
> int y = (3).foo;
>
> ???
>
> I know arrays have an issue with property setters, see a bug report I 
> filed a while back:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=3857
>
> But that seems like a totally unambiguous case (a global property function 
> with two parameters is obviously a setter on the first parameter in UFC).
>
> The getter seems much more problematic.  Does anyone have a solution 
> besides adding more syntax?  Should we disallow global properties to avoid 
> ambiguity?
>

Ugh, it seems D still doesn't quite understand the concept of a property. 
Here:

@property int foo()  // Obviously getter
@property void foo(int x)  // Obviously setter

No other form makes any sence as a property. Frankly, I'm very surprised, 
and dissapointed, that anything else is even allowed. The only *possible* 
exception being:

@property int foo(int x) // Combined getter/setter, if we decide that's 
needed

It doesn't make any sense for a property getter to have a parameter (unless 
it's one parameter and it's used to set a new value). And it doesn't make 
any sence for a setter to have anthing other than exactly one parameter. 
Just disallow it. What could possibly be the point anyway? If it's got 
parameters it's a function call, not a variable.

Additionally, with that understanding in place, this:

@property void foo(int x)  {...}
(3).foo();

Is probably the one place where UFC syntax should never be allowed, because 
it's obviously a setter, and since when does this ever make any sence:

int x;
(3).x; // Set x to 3?? WTF??
October 08, 2010
Re: Uniform Function Call syntax for properties
On Friday, October 08, 2010 13:56:14 Nick Sabalausky wrote:
> "Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message
> news:op.vj9cunrweav7ka@localhost.localdomain...
> 
> > Someone was asking about UFC syntax for properties on d.learn, and I
> > realized, we have a huge ambiguity here.
> > 
> > Given a function:
> > 
> > @property int foo(int x)
> > 
> > Is this a global setter or a getter on an int?
> > 
> > i.e.
> > 
> > int y = foo = 3;
> > 
> > or
> > 
> > int y = (3).foo;
> > 
> > ???
> > 
> > I know arrays have an issue with property setters, see a bug report I
> > filed a while back:
> > 
> > http://d.puremagic.com/issues/show_bug.cgi?id=3857
> > 
> > But that seems like a totally unambiguous case (a global property
> > function with two parameters is obviously a setter on the first
> > parameter in UFC).
> > 
> > The getter seems much more problematic.  Does anyone have a solution
> > besides adding more syntax?  Should we disallow global properties to
> > avoid ambiguity?
> 
> Ugh, it seems D still doesn't quite understand the concept of a property.
> Here:
> 
> @property int foo()  // Obviously getter
> @property void foo(int x)  // Obviously setter
> 
> No other form makes any sence as a property. Frankly, I'm very surprised,
> and dissapointed, that anything else is even allowed. The only *possible*
> exception being:
> 
> @property int foo(int x) // Combined getter/setter, if we decide that's
> needed
> 
> It doesn't make any sense for a property getter to have a parameter (unless
> it's one parameter and it's used to set a new value). And it doesn't make
> any sence for a setter to have anthing other than exactly one parameter.
> Just disallow it. What could possibly be the point anyway? If it's got
> parameters it's a function call, not a variable.

I agree 100%.

> 
> Additionally, with that understanding in place, this:
> 
> @property void foo(int x)  {...}
> (3).foo();
> 
> Is probably the one place where UFC syntax should never be allowed, because
> it's obviously a setter, and since when does this ever make any sence:
> 
> int x;
> (3).x; // Set x to 3?? WTF??

If literals are considered const or immutable, then this takes care of itself, 
since then the type system would then disallow it.

- Jonathan M Davis
October 08, 2010
Re: Uniform Function Call syntax for properties
"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message 
news:mailman.483.1286572389.858.digitalmars-d@puremagic.com...
> On Friday, October 08, 2010 13:56:14 Nick Sabalausky wrote:
>>
>> Additionally, with that understanding in place, this:
>>
>> @property void foo(int x)  {...}
>> (3).foo();
>>
>> Is probably the one place where UFC syntax should never be allowed, 
>> because
>> it's obviously a setter, and since when does this ever make any sence:
>>
>> int x;
>> (3).x; // Set x to 3?? WTF??
>
> If literals are considered const or immutable, then this takes care of 
> itself,
> since then the type system would then disallow it.
>

Maybe hunger is blinding me ATM, but don't see how. Unless it would also 
prevent this:

void bar(int a) {...}
bar(3); // Cannot implicitly cast away immutable

But that would obviously be a bad thing. And even at that, there's still 
this that would need to be prevented:

@property void foo(int x)  {...}
int x = cast(int)3;
x.foo; // Set foo to 3 with stupid syntax
October 09, 2010
Re: Uniform Function Call syntax for properties
On Fri, 08 Oct 2010 16:56:14 -0400, Nick Sabalausky <a@a.a> wrote:

>
> Ugh, it seems D still doesn't quite understand the concept of a property.
> Here:
>
> @property int foo()  // Obviously getter
> @property void foo(int x)  // Obviously setter
>
> No other form makes any sence as a property. Frankly, I'm very surprised,
> and dissapointed, that anything else is even allowed. The only *possible*
> exception being:
>
> @property int foo(int x) // Combined getter/setter, if we decide that's
> needed
>
> It doesn't make any sense for a property getter to have a parameter  
> (unless
> it's one parameter and it's used to set a new value). And it doesn't make
> any sence for a setter to have anthing other than exactly one parameter.
> Just disallow it. What could possibly be the point anyway? If it's got
> parameters it's a function call, not a variable.

Property setters can have two parameters, one is the item used to set it,  
and one is the rvalue to use when setting.  In objects, the first  
parameter is the hidden this parameter.  With UFC, the parameter is  
explicit.  Unless you feel builtin arrays should never have properties?

The only exception are global properties which are not set on anything.   
And this is the problem.

I think the syntax discussed in the other part of this thread is probably  
a good way to disambiguate the issues.

-Steve
« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home