On Thursday, 24 January 2013 at 21:44:12 UTC, Adam Wilson wrote:
> From the compilers standpoint they are functions. It must be so. That's how they're implemented.

No, they are @property functions. That's important because it lets them be rewritten at the usage point, similarly to operator overloading and various other tricks in the language, which also doesn't care about function call syntax, despite being implemented as functions.


I was messing with the compiler a while ago to make my vision work. Got about 90% there, but it got too messy when doing setters. Only made 5 changes:

DsymbolExp::semantic

if the function this references was declared as a property, rewrite the symbol to be a call expression

Thus "bar", if bar was declared as @property, is rewritten into "(bar())" and the rest carries on normally. (So if the whole expression was "bar().foo", the rest of the compiler sees it as "(bar())().foo" and reacts accordingly.)


DotVarExp::semantic

ditto, but for members instead




And the others were trying to make it work for setters in BinExp, AssignExp, and a filthy hack in CallExp itself to find the setter given a getter.

The getter change, about 10 lines of code in dmd, was a success. The setters are where I tripped up and couldn't get it to work right, but this is probably because I'm not a dmd master, not because it is impossible.

On 1/24/13 4:56 PM, Adam Wilson wrote:
>> Simplicity is clearly good, but there's something to be said about
>> those warts in chained calls. The UFCS-enabled idioms clearly bring a
>> strong argument to the table, there's no ignoring it.
>>
>> Andrei
>
> Then @property needs to be fixed such that optional parens don't effect
> it one way or the other. Removing the concept of properties and making
> functions that look like properties through optional parens is a very
> poor (and lazy) solution. As Mr. Ruppe pointed out, properties are DATA,
> and functions do stuff. That statement alone is an excellent argument
> for clearly delineating which is which... Properties are not functions.

I'm not all that convinced, and it's easy to get wedged into a black vs white position that neglects many subtleties. Properties are DATA, well except when you need to pass fields by reference etc. at which point the syntactic glue comes unglued.

There's been a lot of strong positions years ago about functions vs. procedures, statements vs. expressions, or even (the glorious 60s!) in-language I/O primitives vs. I/O as library facilities. Successful languages managed to obviate such dichotomies.


Andrei

On Thursday, 24 January 2013 at 21:53:27 UTC, Adam Wilson wrote:
> Right, this conversation is about removing @property, which invalidates your argument by turning the data into a function, which is what we want to avoid.

Yeah, that's why I'm against the OP proposal.

> Also you might want to run your examples before posting them.

I did.... on my modified dmd where @property has a less stupid (but still buggy) implementation. It works correctly there!

On Thu, 24 Jan 2013 14:06:47 -0800, Adam D. Ruppe <destructionator@gmail.com> wrote:

> On Thursday, 24 January 2013 at 21:53:27 UTC, Adam Wilson wrote:
>> Right, this conversation is about removing @property, which invalidates your argument by turning the data into a function, which is what we want to avoid.
>
> Yeah, that's why I'm against the OP proposal.

Hehe, so am I! :-)

>> Also you might want to run your examples before posting them.
>
> I did.... on my modified dmd where @property has a less stupid (but still buggy) implementation. It works correctly there!

I see. I like it. :-)

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Thursday, 24 January 2013 at 22:04:02 UTC, Andrei Alexandrescu wrote:
> Properties are DATA, well except when you need to pass fields by reference etc. at which point the syntactic glue comes unglued.

An enum or a literal can't be passed by reference or otherwise have the address taken either, but we don't argue about if they're data or not, and don't change barely related parts of the language over them.

void foo(ref int a) {}

int b;
foo(b); // ok
foo(10); // nope

test.d(6): Error: function test.foo (ref int a) is not callable using argument types (int)
test.d(6): Error: constant 10 is not an lvalue


No big deal. Similarly:

enum c = 20;
foo(c);

test.d(12): Error: function test.foo (ref int a) is not callable using argument types (int)
test.d(12): Error: constant 20 is not an lvalue


Note: the error message betrays some truth about enum's implementation.... but who cares.


And finally:

@property int bar() { return 0; }
foo(bar);

test.d(9): Error: function test.foo (ref int a) is not callable using argument types (int)
test.d(9): Error: bar() is not an lvalue



Like the enum, we see a hint in the error message that the compiler is doing a little magic... but who cares.

On Thu, 24 Jan 2013 14:04:02 -0800, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 1/24/13 4:56 PM, Adam Wilson wrote:
>>> Simplicity is clearly good, but there's something to be said about
>>> those warts in chained calls. The UFCS-enabled idioms clearly bring a
>>> strong argument to the table, there's no ignoring it.
>>>
>>> Andrei
>>
>> Then @property needs to be fixed such that optional parens don't effect
>> it one way or the other. Removing the concept of properties and making
>> functions that look like properties through optional parens is a very
>> poor (and lazy) solution. As Mr. Ruppe pointed out, properties are DATA,
>> and functions do stuff. That statement alone is an excellent argument
>> for clearly delineating which is which... Properties are not functions.
>
> I'm not all that convinced, and it's easy to get wedged into a black vs white position that neglects many subtleties. Properties are DATA, well except when you need to pass fields by reference etc. at which point the syntactic glue comes unglued.

... wat? I fail to see what byref has to do with this. It shouldn't matter what the data is to the compiler as both are built on top of functions, the compiler just enforces different calling syntax for each. If this is a problem for properties then it is a problem for functions to...

Because from a compiler POV Data.Property.FieldOfReference; is no different than Data.Function().FieldOfReference;
But from a syntax standpoint the difference important because Data.Property(InRef, Count).FieldOfReference; is utterly nonsensical where Data.Function(InRef, Count).FieldOfReference; is perfectly legitimate.

> There's been a lot of strong positions years ago about functions vs. procedures, statements vs. expressions, or even (the glorious 60s!) in-language I/O primitives vs. I/O as library facilities. Successful languages managed to obviate such dichotomies.
>
>
> Andrei


-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On 01/24/2013 10:56 PM, Adam Wilson wrote:
> On Thu, 24 Jan 2013 13:54:09 -0800, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On 1/24/13 4:08 PM, Adam Wilson wrote:
>>> On Thu, 24 Jan 2013 12:58:41 -0800, Andrei Alexandrescu
>>> <SeeWebsiteForEmail@erdani.org> wrote:
>>>
>>>> On 1/24/13 3:45 PM, Nick Sabalausky wrote:
>>>>> On Thu, 24 Jan 2013 12:51:32 -0500
>>>>> Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org> wrote:
>>>>> No, you merely came up with *some* specific cherry-picked examples that
>>>>> sparked *some* debate (with most of the disagreing coming from
>>>>> you).
>>>>
>>>> I simply mentioned three reasons that came to mind.
>>>>
>>>> Andrei
>>>
>>> While I don't approve of Mr. Sabalausky's tone or attitude, the crux of
>>> his argument is logically sound. The problem with @property isn't
>>> @property, it's D's insistence on optional parens. If paren usage was
>>> clearly defined then this would be a non-issue. I would like to point
>>> out that I can't think of another systems/general purpose language that
>>> has an calling syntax specification as vague and convoluted as D's. C#'s
>>> is brutally simple. Java's is brutally simple. In C/C++ everything is a
>>> function or field, so, brutally simple.
>>>
>>> Make D's calling syntax simpler, end optional parens!
>>
>> Simplicity is clearly good, but there's something to be said about those warts in chained calls. The UFCS-enabled idioms clearly bring a strong argument to the table, there's no ignoring it.
>>
>> Andrei
>
> Then @property needs to be fixed such that optional parens don't effect it one way or the other. Removing the concept of properties and making functions that look like properties through optional parens is a very poor (and lazy) solution. As Mr. Ruppe pointed out, properties are DATA, and functions do stuff. That statement alone is an excellent argument for clearly delineating which is which... Properties are not functions.
>

At while you're at it, just get ride of:

int[] a.
a.length = 10;

That this grows the array stills creeps me out.

Robert

Apart from +=, ++, what breaks compatibility of fields and properties, is that you can't take the address of a property, but of a field (as already mentioned). To increase compatibility and in order to avoid breaking peoples' code, when a field is changed to a property, maybe, simply offer the possibility to declare fields to be a property too, with @property. And make it so that the access to such a field behaves exactly the same as to a property: No address taking, and as long as properties don't support ++, +=, ... maybe even forbid those.

Example:

@property int a;

would be completely equivalent to:

int a_;

@property int a() {
return a_;
}
@property int a(int new_a) {
 a_=new_a;
 return a_;
}

I think this would suffice to make the property concept really sound and working in practice.

If, this is considered a good thing, I could create yet another property DIP.

Another thing I am wondering, will this still be possible:

void myProperty(int a) @property {}

void function(int) dg=&myProperty;

Or in other words, will taking the address of a property method still be possible? I think it would be quite sensible and useful (for e.g. std.signals), taking the address of a transient return value does not make any sense anyway, so no ambiguity here. On the other hand it would break compatibility with fields again. So if we also want to make sure the way back (from property methods to field) works, disallowing taking the address might be the way to go for a finally proper implementation.

To the C# experts: How does C# solve those two issues?

Best regards,

Robert

On Thursday, January 24, 2013 23:15:38 Adam D. Ruppe wrote:
> On Thursday, 24 January 2013 at 22:04:02 UTC, Andrei Alexandrescu
> 
> wrote:
> > Properties are DATA, well except when you need to pass fields by reference etc. at which point the syntactic glue comes unglued.
> 
> An enum or a literal can't be passed by reference or otherwise have the address taken either, but we don't argue about if they're data or not, and don't change barely related parts of the language over them.
[snip]

However, I do think that would be able to mark variables such that they're treated as rvalues such that swapping a variable out with a property function dosen't break code (at least if http://d.puremagic.com/issues/show_bug.cgi?id=8006 gets implemented).

- Jonathan M Davis

On Thursday, 24 January 2013 at 22:28:04 UTC, Jonathan M Davis wrote:
> However, I do think that would be able to mark variables such that they're treated as rvalues such that swapping a
> variable out with a property function dosen't break code

agreed