On Saturday, February 09, 2013 06:38:00 Marco Leise wrote:
> There is only little think that itches me. In this example a is an int. Would the setter always take a copy of a large struct? I see no way to make it 'auto ref'!

It would be simple enough to make it so that the compiler used auto ref in the lowered version and just make the variable itself int, though the DIP obviously doesn't say that.

- Jonathan M Davis

On 2013-02-09 02:36, Timon Gehr wrote:
> "Taking the address of a property
>
> As this is illegal for properties..."
>
> @property ref int foo();
> int* y = &(&foo)();

Yes, but this DIP makes it invalid to define a @property ref T foo().
To use ref it would have to be a normal function: ref T foo().
So finally this example no longer ruins the property construct. :)

09-Feb-2013 03:53, Robert пишет:
> Ok. Here finally it is:
>
> http://wiki.dlang.org/DIP26
>
>

>NoUFCS for properties

> Properties protect the access to a field of an entity (class/struct/module),
> so they actually have to be defined within the entity they belong to, just as a field would.

Rubbish.

std.array:

@property auto front(T)(T[] arr)
{
	return arr[0];
}

-- 
Dmitry Olshansky

09-Feb-2013 07:13, Michel Fortin пишет:
> On 2013-02-08 23:53:30 +0000, Robert <jfanatiker@gmx.at> said:
>
>> Ok. Here finally it is:
>>
>> http://wiki.dlang.org/DIP26
>
> This is pretty much exactly how I think properties should work. There's
> two possible benefits you may to have overlooked…
>
> One benefit of the "@property T foo;" syntax that does the boilerplate
> code for you over using a plain variable: the getter and setter
> generated are virtual in a class, so a derived class can override them.
> Doesn't work with a plain variable.
>
> Another possible benefit that we could have is the ability to use the
> default getter but to provide your own setter implementation by just
> declaring it:
>
>      @property int a;
>      @property void a(int value) { __a = value; refresh(); }
>

Yes, I too had thoughts along the same lines.

Though just writing some setters by hand and then adding:

mixin TrivialProperties!(_a, _b, _c);

should be doable. But it would be still an ugly boilerplate.

> Much cleaner than this:
>
>      private int _a;
>      @property int a() { return _a; }
>      @property void a(int value) { _a = value; refresh(); }
>
> It's really great to not have to write boilerplate functions when
> default behaviour is perfectly fine. I've been using Objective-C for a
> while now and the recent changes where it automatically synthesize a
> variable, a getter, and a setter when declaring a property (unless you
> provide your own) are truly delightful.
>


-- 
Dmitry Olshansky

On Friday, 8 February 2013 at 23:53:40 UTC, Robert wrote:
> Ok. Here finally it is:
>
> http://wiki.dlang.org/DIP26
>
>
> Best regards,
>
> Robert

Taking the address of a property  <= no. It I take the address of an int, I get an int* or an error because it is invalid. Not a delegate !
No UFCS for properties <= no.
Behaviour like functions <= WTF should properties behave differently if the return a function ?

This DIP is probably the worse as of now. The only thing that make sense is @property T foo;

On 2013-02-09 08:19, Dmitry Olshansky wrote:
>> NoUFCS for properties
>
>> Properties protect the access to a field of an entity (class/struct/module),
>> so they actually have to be defined within the entity they belong to, just as
>> a field would.
>
> Rubbish.
>
> std.array:
>
> @property auto front(T)(T[] arr)
> {
>      return arr[0];
> }
>

Yeah, banning UFCS for properties is too farfetched.

On Saturday, 9 February 2013 at 07:45:05 UTC, FG wrote:
> On 2013-02-09 08:19, Dmitry Olshansky wrote:
>>> NoUFCS for properties
>>
>>> Properties protect the access to a field of an entity (class/struct/module),
>>> so they actually have to be defined within the entity they belong to, just as
>>> a field would.
>>
>> Rubbish.
>>
>> std.array:
>>
>> @property auto front(T)(T[] arr)
>> {
>>     return arr[0];
>> }
>>
>
> Yeah, banning UFCS for properties is too farfetched.

This attempt to define a standard definition shows that the idea of a property means different things depending on the person you ask and what they are trying to accomplish.

The current @property implementation is no good for the encapsulation definition, however it is great for what the compiler currently implements, which are regular functions with (soon to be) enforced getter and setter syntax.

If we also want encapsulating properties that emulate variables as much as possible, that's a different type of property from the type that does not encapsulate and try to fully emulate a variable. @property simply cannot do both. What's missing is the ability to wrap true private internals into a property namespace. This idea was presented a few times already, as it appears to be a reasonable solution.

I really don't see why we cannot implement the non-encapsulated @property implementation, which is essentially what we already have except with enforced getter/setter syntax and weak variable emulation (its just a regular function), and later after the dust settles we implement a real property with true powers of encapsulation and more precise variable emulation, although not to replace @property because it does a good job for what it is design to do.

--rt

On Friday, 8 February 2013 at 23:53:40 UTC, Robert wrote:
> Ok. Here finally it is:
>
> http://wiki.dlang.org/DIP26
>
>
> Best regards,
>
> Robert

Why I should write fun()() when property returns a delegate?

Additional () should not be necessary.
Also combo properties like int get_set_IntValue(int) I think should be avoided.

On Saturday, 9 February 2013 at 03:13:47 UTC, Michel Fortin wrote:
> It's really great to not have to write boilerplate functions when default behaviour is perfectly fine. I've been using Objective-C for a while now and the recent changes where it automatically synthesize a variable, a getter, and a setter when declaring a property (unless you provide your own) are truly delightful.

@property int a;

I would prefer if @property simply disallows '&' then it doesn't have to be lowered into anything and can stay a field... if you later decide to add a "real" getter/setter, it still would be source compatible and you wouldn't have to refactor the source.

Has anyone actually read the DIP?

Simply don't call it property.
On Sat, 2013-02-09 at 08:45 +0100, FG wrote:
> On 2013-02-09 08:19, Dmitry Olshansky wrote:
> >> NoUFCS for properties
> >
> >> Properties protect the access to a field of an entity (class/struct/module), so they actually have to be defined within the entity they belong to, just as a field would.
> >
> > Rubbish.
> >
> > std.array:
> >
> > @property auto front(T)(T[] arr)
> > {
> >      return arr[0];
> > }
> >
> 
> Yeah, banning UFCS for properties is too farfetched.