View mode: basic / threaded / horizontal-split · Log in · Help
February 27, 2013
DIP28, on properties, availabel for destruction as well
Here come the sister of DIP27 : DIP28 http://wiki.dlang.org/DIP28 
.

It address specifically properties. A 3rd one is coming on 
delegate. As for DIP27, the goal is to go aggressively for 
simplicity.
February 27, 2013
Re: DIP28, on properties, availabel for destruction as well
On Wednesday, 27 February 2013 at 15:46:38 UTC, deadalnix wrote:
> Here come the sister of DIP27 : DIP28 
> http://wiki.dlang.org/DIP28 .
>
> It address specifically properties. A 3rd one is coming on 
> delegate. As for DIP27, the goal is to go aggressively for 
> simplicity.

I like both this one and DIP27. But I do think it is way too late 
for D2.

Lars
February 27, 2013
Re: DIP28, on properties, availabel for destruction as well
On Wednesday, February 27, 2013 16:46:37 deadalnix wrote:
> Here come the sister of DIP27 : DIP28 http://wiki.dlang.org/DIP28
> .
> 
> It address specifically properties. A 3rd one is coming on
> delegate. As for DIP27, the goal is to go aggressively for
> simplicity.

And what does this provide over DIP23 aside from the fact that now it's 
impossible to get the address of a property function (which of course is
a problem)?

- Jonathan M Davis
February 27, 2013
Re: DIP28, on properties, availabel for destruction as well
On 2013-02-27 16:46, deadalnix wrote:
> Here come the sister of DIP27 : DIP28 http://wiki.dlang.org/DIP28 .
>
> It address specifically properties. A 3rd one is coming on delegate. As
> for DIP27, the goal is to go aggressively for simplicity.

What happens if you do:

auto a = b.setter = 3;

I see two alternatives:

A. It's rewritten to this:

auto __tmp = 3;
b.setter = 3;
auto a = __tmp;

B. It's rewritten to this:

b.setter = 3;
auto a = b.getter;

I prefer B.

What happens if you do:

struct Point
{
    int x;
    int y;
}

class Widget
{
    @property Point getter();
    @property Point setter(Point);
}

auto w = new Widget;
w.getter.x = 3;

I would prefer if that gets rewritten to:

Point __tmp = w.getter;
__tmp.x = 3;
w.getter = __tmp;

-- 
/Jacob Carlborg
February 28, 2013
Re: DIP28, on properties, availabel for destruction as well
On Wednesday, 27 February 2013 at 17:56:10 UTC, Jonathan M Davis 
wrote:
> On Wednesday, February 27, 2013 16:46:37 deadalnix wrote:
>> Here come the sister of DIP27 : DIP28 
>> http://wiki.dlang.org/DIP28
>> .
>> 
>> It address specifically properties. A 3rd one is coming on
>> delegate. As for DIP27, the goal is to go aggressively for
>> simplicity.
>
> And what does this provide over DIP23 aside from the fact that 
> now it's
> impossible to get the address of a property function (which of 
> course is
> a problem)?
>

It doesn't have special cases.

As of taking the address of a property, we should simply allow 
the compiler to optimize away lambda when they are of the form :
a => fun(a);

when it make sens to do so. This is easy to recognize for the 
compiler.

Additionally, I don't think this is really a problem as it is 
asking to break the abstraction, plain and simple. If you need a 
function pointer, then it is likely that you shouldn't be using a 
property in the first place.

Every signle field access involve some operation, sometime even a 
complex one (TLS on OSX for instance). And you can't get a 
function pointer on that, and this haven't been a problem for 
anyone so far. The compiler propose some routines to interact 
with data, and properties allow the user to propose its own.
February 28, 2013
Re: DIP28, on properties, availabel for destruction as well
On Wednesday, 27 February 2013 at 20:09:51 UTC, Jacob Carlborg 
wrote:
> On 2013-02-27 16:46, deadalnix wrote:
>> Here come the sister of DIP27 : DIP28 
>> http://wiki.dlang.org/DIP28 .
>>
>> It address specifically properties. A 3rd one is coming on 
>> delegate. As
>> for DIP27, the goal is to go aggressively for simplicity.
>
> What happens if you do:
>
> auto a = b.setter = 3;
>
> I see two alternatives:
>
> A. It's rewritten to this:
>
> auto __tmp = 3;
> b.setter = 3;
> auto a = __tmp;
>
> B. It's rewritten to this:
>
> b.setter = 3;
> auto a = b.getter;
>
> I prefer B.
>

The proposal is to rewrite that to auto a = b.setter(3);

Its value is whatever the setter returns.

> What happens if you do:
>
> struct Point
> {
>     int x;
>     int y;
> }
>
> class Widget
> {
>     @property Point getter();
>     @property Point setter(Point);
> }
>
> auto w = new Widget;
> w.getter.x = 3;
>

Error, w.getter is not an lvalue.

> I would prefer if that gets rewritten to:
>
> Point __tmp = w.getter;
> __tmp.x = 3;
> w.getter = __tmp;

That would be an error as well, for the same reason.
February 28, 2013
Re: DIP28, on properties, availabel for destruction as well
On Thursday, 28 February 2013 at 02:56:40 UTC, deadalnix wrote:
> Additionally, I don't think this is really a problem as it is 
> asking to break the abstraction, plain and simple. If you need 
> a function pointer, then it is likely that you shouldn't be 
> using a property in the first place.

+1. Properties (from what I've seen) are suppose to be 
effectively indistinguishable between a field. If you're taking 
the address of a property hoping to get the function address, 
this is a clear violation of that.

For instance, if I wrote some code like this:

...
auto myFun = &b.front;
...

And I expected to get a function pointer from that, it would be a 
clear violation of what ".front" means (or, is intended to 
mean...) and it would break on many ranges because many of them 
are implemented s.t. front is actually a field.
February 28, 2013
Re: DIP28, on properties, availabel for destruction as well
On 2013-02-28 04:00, deadalnix wrote:

> The proposal is to rewrite that to auto a = b.setter(3);
>
> Its value is whatever the setter returns.

Then setters always must return a value. I think it would be better to 
have the compiler rewrite the expression to return what the getter returns.

> Error, w.getter is not an lvalue.

Then you cannot freely change a field to a property.

> That would be an error as well, for the same reason.

That should have of course looked like:

w.setter = __tmp;

If this rewrite is not done then again, you cannot freely change a field 
to a property.

-- 
/Jacob Carlborg
February 28, 2013
Re: DIP28, on properties, availabel for destruction as well
On Thursday, 28 February 2013 at 08:02:05 UTC, Jacob Carlborg 
wrote:
> On 2013-02-28 04:00, deadalnix wrote:
>
>> The proposal is to rewrite that to auto a = b.setter(3);
>>
>> Its value is whatever the setter returns.
>
> Then setters always must return a value. I think it would be 
> better to have the compiler rewrite the expression to return 
> what the getter returns.
>

Must is not appropriate here, as it isn't an obligation at all. I 
don't really see what is the concern here.

If the function is simple, then it will be inlined and unused 
returned values can be optimized away. If the function is 
complex, the cost of returning something when not needed will be 
negligible anyway.

What is your concern here ?

>> Error, w.getter is not an lvalue.
>
> Then you cannot freely change a field to a property.
>

You can return an lvalue. But you example was returning an 
rvalue; so it is an error in this case.
February 28, 2013
Re: DIP28, on properties, availabel for destruction as well
On 2013-02-28 09:21, deadalnix wrote:

> Must is not appropriate here, as it isn't an obligation at all. I don't
> really see what is the concern here.
>
> If the function is simple, then it will be inlined and unused returned
> values can be optimized away. If the function is complex, the cost of
> returning something when not needed will be negligible anyway.
>
> What is your concern here ?

My concern here is setters that doesn't return a value. They won't work 
with chained assignments. Another thing that will break when changing a 
filed to a property.

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