www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP26: properties defined

reply Robert <jfanatiker gmx.at> writes:
Ok. Here finally it is:

http://wiki.dlang.org/DIP26


Best regards,

Robert
Feb 08 2013
next sibling parent "Rob T" <alanb ucora.com> writes:
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
Feb 08 2013
prev sibling next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
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!
Feb 08 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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)();
Feb 08 2013
parent FG <home fgda.pl> writes:
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. :)
Feb 08 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
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
Feb 08 2013
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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.
Feb 08 2013
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.ca> writes:
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/
Feb 08 2013
next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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
Feb 08 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-02-09 10:57, Tove wrote:

  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.

If it's not lowered to functions they won't be virtual, which might be wanted. -- /Jacob Carlborg
Feb 09 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-09 04:13, Michel Fortin wrote:

 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.

I completely agree, I really like it. Do we want to be able to use attributes like "final", and perhaps others, when declaring a property field: property final int a; The lowered functions would have the "final" attribute attached to them self. -- /Jacob Carlborg
Feb 09 2013
parent Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-02-09 15:22:28 +0000, Jacob Carlborg <doob me.com> said:

 I completely agree, I really like it. Do we want to be able to use 
 attributes like "final", and perhaps others, when declaring a property 
 field:
 
  property final int a;
 
 The lowered functions would have the "final" attribute attached to them self.

That'd make a lot of sense. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca/
Feb 09 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
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
Feb 08 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
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
Feb 08 2013
prev sibling next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
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:
=20
 Ok. Here finally it is:
=20
 http://wiki.dlang.org/DIP26

This is pretty much exactly how I think properties should work. There's=20 two possible benefits you may to have overlooked=E2=80=A6 =20 One benefit of the " property T foo;" syntax that does the boilerplate=20 code for you over using a plain variable: the getter and setter=20 generated are virtual in a class, so a derived class can override them.=20 Doesn't work with a plain variable. =20 Another possible benefit that we could have is the ability to use the=20 default getter but to provide your own setter implementation by just=20 declaring it: =20 property int a; property void a(int value) { __a =3D value; refresh(); } =20 Much cleaner than this: =20 private int _a; property int a() { return _a; } property void a(int value) { _a =3D value; refresh(); } =20 It's really great to not have to write boilerplate functions when=20 default behaviour is perfectly fine. I've been using Objective-C for a=20 while now and the recent changes where it automatically synthesize a=20 variable, a getter, and a setter when declaring a property (unless you=20 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'! --=20 Marco
Feb 08 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Feb 08 2013
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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
Feb 08 2013
parent reply FG <home fgda.pl> writes:
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.
Feb 08 2013
parent reply FG <home fgda.pl> writes:
On 2013-02-09 12:32, Robert wrote:
 Has anyone actually read the DIP?

 Simply don't call it property.

Fine for getters but this time it will break things for setters: property void front(T)(T[] arr, T elem) {...} and either all code with assignments would have to be changed or assignments remain allowed for functions -- neither is good.
Feb 09 2013
parent FG <home fgda.pl> writes:
On 2013-02-09 12:57, Robert wrote:
 As you can't actually encapsulate the array with free functions just do:

 ref T front(T)(T[] arr);

 There is no value in using an actual setter.

Ah, sorry, you're right. It's an lvalue, so no setter is needed.
Feb 09 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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;
Feb 08 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
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
Feb 09 2013
prev sibling next sibling parent "Michael" <pr m1xa.com> writes:
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.
Feb 09 2013
prev sibling next sibling parent "Tove" <tove fransson.se> writes:
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.
Feb 09 2013
prev sibling next sibling parent Robert <jfanatiker gmx.at> writes:
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.

Feb 09 2013
prev sibling next sibling parent Robert <jfanatiker gmx.at> writes:
As you can't actually encapsulate the array with free functions just do:

ref T front(T)(T[] arr);

There is no value in using an actual setter.

If you really want encapsulation, just do:

struct EncapsulatedArray(T) {
T front()  property;
void front(T value)  property;
private T[] arr_;
}

On Sat, 2013-02-09 at 12:43 +0100, FG wrote:
 On 2013-02-09 12:32, Robert wrote:
 Has anyone actually read the DIP?

 Simply don't call it property.

Fine for getters but this time it will break things for setters: property void front(T)(T[] arr, T elem) {...} and either all code with assignments would have to be changed or assignments remain allowed for functions -- neither is good.

Feb 09 2013
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-02-09 11:58:23 +0000, Jonathan M Davis <jmdavisProg gmx.com> said:

 You must be able to rely on front always being used without parens, and you
 must be able to rely on front() doing a call on the return value rather than
 simply calling front. Otherwise, you're going to have problems with code
 erroneously using parens to call front and breaking when used with anything
 that actually defines it as a property, and you'll break anything involving
 delegates or other callables. Returning ref is irrelevant, especially if we
 get full property rewrites (e.g. front += 7 and the like works with property
 functions without ref). What matters is that the syntax is consistent and that
 the semantics of using parens on front are consistent. Generic code needs to
 work with anything with the right API, and making front a function will cause
 problems with that.

I'll agree with you that it'd be better if properties were allowed with UFCS too. At the same time, this DIP removes much of the boilerplate of writing properties, so it's not only a "fix" for the current problems, it's also a much welcome improvement over what we have. It doesn't address the UFCS issue, but that doesn't prevent it from being fixed in other ways. For instance we could add a 'this' argument (not that I favour this particular syntax): property void front(int[] this, int value); One problem we currently have is that the way properties are defined with property is that there's no way to distinguish module-level properties from UFCS properties. Instead of fixing that, many people are trying to disallow one or the other. So instead of fixing the real problem, people have divided into two camps: one that likes module-level properties and one that likes UFCS ones. Both sides wanting to disallow the other's side pet feature. I find the situation somewhat ridiculous. Whatever side we choose, it'll break the language coherency while alienating many people. I believe both module-level properties and UFCS properties to be desirable. So is the idea put forward in DIP26 that reduces boilerplate code. The question is how do we put all that together. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca/
Feb 09 2013
next sibling parent Michel Fortin <michel.fortin michelf.ca> writes:
I wrote:

 I believe both module-level properties and UFCS properties to be 
 desirable. So is the idea put forward in DIP26 that reduces boilerplate 
 code. The question is how do we put all that together.

Andrei just made me realize that I overlooked this part of DIP26 which actually solve the most of the problem of UFCS (see the Upgrade Path section):
 Generic code won't break: It can use optional parentheses, but does not 
 have to. Calling a delegate returned by a function/property function is 
 always:
 front()();

So whether a getter is a property or not does not change anything at the call site, meaning that UFCS getters (or any getter with no associated setter for that matter) don't need to be properties. What remains is that you can't write UFCS *setters*. But UFCS setters are definitely less common, and if that's really important I guess it could be solved though separate means. So in short, this proposal is that property does only two things when applied to a function: it enables the setter syntax and it changes the overload rules. I like the conclusion:
 So this DIP is exactly the opposite approach of solving the property 
 problem: Don't make them look more like fields, make public fields more 
 look like functions.
 
 Don't try to make functions look like fields, this can not work. Just 
 do it the other way round: Don't ever make a field public, but use 
 properties, as every OOP book tells you anyway. And all problems are 
 solved, as far as I can see.

-- Michel Fortin michel.fortin michelf.ca http://michelf.ca/
Feb 09 2013
prev sibling parent Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-02-09 15:30:13 +0000, "deadalnix" <deadalnix gmail.com> said:

 On Saturday, 9 February 2013 at 12:44:35 UTC, Michel Fortin wrote:
 I believe both module-level properties and UFCS properties to be 
 desirable. So is the idea put forward in DIP26 that reduces boilerplate 
 code. The question is how do we put all that together.

Well design is a balance between conflicting goals. Allowing both cause an extra complication. So the win have to actually be carefully considered.

Only because of the constrains people seem to have wrapped themselves into. If you want to use property to designate a property (which doesn't distinguish setter and getter) then you run in the problem of not being able to distinguish UFCS getter from non-UFCS setter. So of course if you impose yourself the constrain of having something ambiguous you need some other rule to disambiguate.
  properties as UFCS are almost mandatory. They are used everywhere, 
 especially for arrays.

Setters or getters? UFCS "getters" are not a problem with this DIP. Quoting my other post:
 So whether a getter is a property or not does not change anything at 
 the call site, meaning that UFCS getters (or any getter with no 
 associated setter for that matter) don't need to be properties. What 
 remains is that you can't write UFCS *setters*. But UFCS setters are 
 definitely less common, and if that's really important I guess it could 
 be solved though separate means.
 
 So in short, this proposal is that  property does only two things when 
 applied to a function: it enables the setter syntax and it changes the 
 overload rules.

-- Michel Fortin michel.fortin michelf.ca http://michelf.ca/
Feb 09 2013
prev sibling next sibling parent Robert <jfanatiker gmx.at> writes:
I am going to consider these. Thanks!
On Fri, 2013-02-08 at 22:13 -0500, Michel Fortin wrote:
 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.

Feb 09 2013
prev sibling next sibling parent Robert <jfanatiker gmx.at> writes:
On Sat, 2013-02-09 at 08:28 +0100, deadalnix wrote:
 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 ?

You are still thinking of properties as fields. Which does not work reliable in any proposal and actually can not, that is the reason for encapsulation in the first place. My arguments against UFCS for properties make a lot of sense if you think about it and result in a very clean implementation, with little breakage and the added benefit of actually having something that deserves to be called property. The other proposals try to solve the issue of functions returning functions being inconsistent across real functions and some property like thing that tries (badly) to mimic a field, by making property just more non sensical, instead of tackling the root cause of the problem: We can not mimic fields and in fact there is absolutely no reason to do so, if you think about it, you don't really want that, otherwise all books about OOP would be wrong.
Feb 09 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 9 February 2013 at 12:44:35 UTC, Michel Fortin wrote:
 One problem we currently have is that the way properties are 
 defined with  property is that there's no way to distinguish 
 module-level properties from UFCS properties. Instead of fixing 
 that, many people are trying to disallow one or the other. So 
 instead of fixing the real problem, people have divided into 
 two camps: one that likes module-level properties and one that 
 likes UFCS ones. Both sides wanting to disallow the other's 
 side pet feature. I find the situation somewhat ridiculous. 
 Whatever side we choose, it'll break the language coherency 
 while alienating many people.

 I believe both module-level properties and UFCS properties to 
 be desirable. So is the idea put forward in DIP26 that reduces 
 boilerplate code. The question is how do we put all that 
 together.

Well design is a balance between conflicting goals. Allowing both cause an extra complication. So the win have to actually be carefully considered. properties as UFCS are almost mandatory. They are used everywhere, especially for arrays. I don't really know what is the state of thing in module level property, but I never used them or required them. Can you give use cases of desirables module level properties ?
Feb 09 2013
prev sibling next sibling parent Robert <jfanatiker gmx.at> writes:
I already thought about this too, good enough that D choose not to use
final for const variables like Java does.

On Sat, 2013-02-09 at 12:54 -0500, Michel Fortin wrote:
 On 2013-02-09 15:22:28 +0000, Jacob Carlborg <doob me.com> said:
 
 I completely agree, I really like it. Do we want to be able to use 
 attributes like "final", and perhaps others, when declaring a property 
 field:
 
  property final int a;
 
 The lowered functions would have the "final" attribute attached to them self.

That'd make a lot of sense.

Feb 09 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 08 Feb 2013 18:53:30 -0500, Robert <jfanatiker gmx.at> wrote:

 Ok. Here finally it is:

 http://wiki.dlang.org/DIP26

Wow. So you simply want to go back to D1-style properties. It would have been simpler to just specify that we define a property like this: // this is a property int foo() {...} -Steve
Feb 09 2013
prev sibling next sibling parent Robert <jfanatiker gmx.at> writes:
 // this is a property
 int foo() {...}

without parentheses. Which is quite a lame definition of property if you ask me. But yeah my proposal makes properties to be considered functions, just with some guarantees regarding encapsulation and the special syntax that prop=a; means: prop(a); Actually Michel Fortin summarizes the DIP quite to the point:
 So in short, this proposal is that  property does only two things

 applied to a function: it enables the setter syntax and it changes

 overload rules.
 

In addition it restricts the setter syntax (prop=a) to be interpreted in a non UFCS way, meaning there will be no setter methods with two parameters. (Not accounting for the implicit this parameter)
Feb 10 2013
prev sibling parent Robert <jfanatiker gmx.at> writes:
On Fri, 2013-02-08 at 22:00 -0800, Jonathan M Davis wrote:
 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.

That would be impossible for virtual functions in a class. What the compiler could do, is simply provide both. This has to be thought through, what is important is that it is very clear what the compiler produces. As properties are meant to be assigned (which implies a copy at some point), you usually try to keep them small anyway or making them a class so that you only have to assign a reference. So I think it is not a bad choice to have the compiler simply generate the most simple trivial form, taking the argument by value. If you really want something different in some special application, you may still provide the functions on your own. Having said that, I really don't mind having the compiler produce both, if people think this is a good idea.
Feb 10 2013