Ok. Here finally it is:

http://wiki.dlang.org/DIP26


Best regards,

Robert

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

The definition is the obvious first step, so thanks for taking the time to define one.

What we really need is a process in place for managing the language specification, otherwise we'll be spinning wheels forever. The concept of DIPs are not enough, for example there's no revision control over the specification, and no ability to determine what version of the specification a given compiler version adheres to. There's also not much going on for planning and prioritizing what needs to be done.

A process for developing all aspects of the D language should be a top priority.

--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

This seems a pretty straightforward approach. The less surprises and special cases the better.

In short, good idea!

On Saturday, 9 February 2013 at 00:27:04 UTC, John Colvin wrote:
> On Friday, 8 February 2013 at 23:53:40 UTC, Robert wrote:
>
> In short, good idea!

+1

On 02/09/2013 01:27 AM, John Colvin wrote:
> 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
>
> This seems a pretty straightforward approach.
> The less surprises and special cases the better.
>...

"Taking the address of a property

As this is illegal for properties..."

@property ref int foo();
int* y = &(&foo)();

On 02/09/2013 12:53 AM, Robert wrote:
> Ok. Here finally it is:
>
> http://wiki.dlang.org/DIP26
>
>
> Best regards,
>
> Robert
>

"For optional parentheses, I would like to adopt the scheme already explained in DIP23."

It is not actually explained.

"DIP23 and DIP24 both don't seem to have a clear concept what properties actually are, resulting in rules that destroy their original purpose (For example forbidding module level properties)."

That is a very strong claim to make and a very weak example.

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(); }

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.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca/

On Saturday, 9 February 2013 at 01:48:25 UTC, Timon Gehr wrote:
> On 02/09/2013 12:53 AM, Robert wrote:
>> Ok. Here finally it is:
>>
>> http://wiki.dlang.org/DIP26
>>
>>
>> Best regards,
>>
>> Robert
>>
>
> "For optional parentheses, I would like to adopt the scheme already explained in DIP23."
>
> It is not actually explained.
>
> "DIP23 and DIP24 both don't seem to have a clear concept what properties actually are, resulting in rules that destroy their original purpose (For example forbidding module level properties)."
>
> That is a very strong claim to make and a very weak example.

It's very clear that there is no definition of what a property is in either DIP23 or DIP24. The details are made up based on someones definition, but I cannot be certain what that definition that is, probably multiple definitions depending on who you ask.

DIP23 firmly states that there are no module level properties that emulate global variables, and proposes a strange implementation that does not resemble what one would normally consider to be a property. If we had a clear definition of "property" in DIP23, I'd love to see how it would account for the two inconsistent behaviors. I think that a sensible definition would prevent such an inconsistent proposal from appearing in the first place.

--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

"Properties as defined in this DIP are a way of encapsulation of fields of an entity (class, struct, module) in a way that the class/struct/module can actually control the access and thus encapsulates it, such that the field in reality might not even exist or be in a different format than presented, ... "

This part of the definition seems to be sensible: A property implementation that meets the encapsulation test has to prevent direct access to the underlying property variables so that access can be controlled.

Unfortunately the current proposed implementation fails to meet the encapsulation test for structs and classes and also for globals inside modules because no matter if a field is marked private inside a class or struct, it is directly accessible from outside the class or struct within the same module, thus breaking encapsulation, therefore control is not assured, i.e., the property methods are easily circumvented from within the module.

If we make an exception to the encapsulation definition and allow encapsulation to be circumvented only within the module level but not from outside the module, then module level properties can meet the encapsulation test since private globals are not accessible from outside, but that works only if module level properties are allowed, but I understand that the currently proposed implementation is in a conflict with UCFS, so another exception to the definition is needed to disallow module level properties only because the implementation is inadequate which seems absurd to have to do.

In summary, the definition of property encapsulation is good, but to meet the definition, the @property implementation is not adequate, and D will require the ability to mark variables as private at the module level (this is something I don't understand why we don't have).

--rt

Am Fri, 8 Feb 2013 22:13:45 -0500
schrieb Michel Fortin <michel.fortin@michelf.ca>:

> 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(); }
> 
> 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.

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'!

-- 
Marco