Jump to page: 1 2 3
Thread overview
Uniform Function Call syntax for properties
Oct 08, 2010
Stanislav Blinov
Oct 08, 2010
Denis Koroskin
Oct 08, 2010
Stanislav Blinov
Oct 09, 2010
Sean Kelly
Oct 09, 2010
Denis Koroskin
Oct 10, 2010
Robert Jacques
Oct 10, 2010
Denis Koroskin
Oct 10, 2010
Robert Jacques
Oct 10, 2010
Denis Koroskin
Oct 10, 2010
Robert Jacques
Oct 14, 2010
Robert Jacques
Oct 15, 2010
Robert Jacques
Oct 17, 2010
Robert Jacques
Oct 08, 2010
Nick Sabalausky
Oct 08, 2010
Jonathan M Davis
Oct 08, 2010
Nick Sabalausky
Oct 09, 2010
Denis Koroskin
October 08, 2010
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
 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
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
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
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
 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
"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
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
"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
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