DIP26: properties defined
Ok. Here finally it is: http://wiki.dlang.org/DIP26 Best regards, Robert
Re: DIP26: properties defined
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
Re: DIP26: properties defined
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!
Re: DIP26: properties defined
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
Re: DIP26: properties defined
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)();
Re: DIP26: properties defined
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.
Re: DIP26: properties defined
On 2013-02-08 23:53:30 +, Robert 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.for...@michelf.ca
http://michelf.ca/
Re: DIP26: properties defined
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
Re: DIP26: properties defined
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
Re: DIP26: properties defined
Am Fri, 8 Feb 2013 22:13:45 -0500
schrieb Michel Fortin :
> On 2013-02-08 23:53:30 +, Robert 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
Re: DIP26: properties defined
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
Re: DIP26: properties defined
On Saturday, February 09, 2013 00:53:30 Robert wrote: > Ok. Here finally it is: > > http://wiki.dlang.org/DIP26 I completely disagree with disallowing UFCS properties. Not only is it outright required for arrays, but it's currently possible to turn anything into a range (even types over which you have no control) simply by defining the functions (including property functions) for it externally. And you could do the same with most any API required by a template. If UFCS properties were disallowed, then that would become impossible for any API which included properties. That's unnecessarily restrictive. - Jonathan M Davis
Re: DIP26: properties defined
On Fri, Feb 08, 2013 at 10:04:11PM -0800, Jonathan M Davis wrote: > On Saturday, February 09, 2013 00:53:30 Robert wrote: > > Ok. Here finally it is: > > > > http://wiki.dlang.org/DIP26 > > I completely disagree with disallowing UFCS properties. Not only is it > outright required for arrays, but it's currently possible to turn > anything into a range (even types over which you have no control) > simply by defining the functions (including property functions) for it > externally. And you could do the same with most any API required by a > template. If UFCS properties were disallowed, then that would become > impossible for any API which included properties. That's unnecessarily > restrictive. [...] Yeah, I disagree with disallowing UFCS properties too. That just cripples it so much that a lot of existing @property use cases are invalidated. It feels like throwing out the baby with the bathwater, instead of solving the actual problem. T -- It is of the new things that men tire --- of fashions and proposals and improvements and change. It is the old things that startle and intoxicate. It is the old things that are young. -- G.K. Chesterton
Re: DIP26: properties defined
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. :)
Re: DIP26: properties defined
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
Re: DIP26: properties defined
09-Feb-2013 07:13, Michel Fortin пишет:
On 2013-02-08 23:53:30 +, Robert 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
Re: DIP26: properties defined
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;
Re: DIP26: properties defined
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.
Re: DIP26: properties defined
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
Re: DIP26: properties defined
I am claiming that if we restrict ourselves to the property concept explained in the DIP, then the range API would no longer depend on front being a property, it can also be a function returning ref, which is perfectly legal for UFCS. I am further claiming that properties via get/set methods don't actually make sense outside of the entity that define them, I am glad if you could give an actual example that would prove me wrong. And because properties are treated (apart from allowing = to call the set method) exactly like normal functions, you should note no difference. It feels to me, that most problems arise due to the fact that we try to make properties like fields (forbidding parentheses), which make them essentially incompatible to functions, resulting in making all sorts of things properties, which actually aren't, just so that no template breaks. Maybe I should make this more clear in the DIP. On Fri, 2013-02-08 at 22:04 -0800, Jonathan M Davis wrote: > I completely disagree with disallowing UFCS properties. Not only is > it > outright required for arrays, but it's currently possible to turn > anything > into a range (even types over which you have no control) simply by > defining the > functions (including property functions) for it externally. And you > could do > the same with most any API required by a template. If UFCS properties > were > disallowed, then that would become impossible for any API which > included > properties. That's unnecessarily restrictive.
Re: DIP26: properties defined
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.
Re: DIP26: properties defined
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.
Re: DIP26: properties defined
On Saturday, February 09, 2013 10:45:13 Robert wrote: > I am claiming that if we restrict ourselves to the property concept > explained in the DIP, then the range API would no longer depend on front > being a property, it can also be a function returning ref, which is > perfectly legal for UFCS. > > I am further claiming that properties via get/set methods don't actually > make sense outside of the entity that define them, I am glad if you > could give an actual example that would prove me wrong. > > And because properties are treated (apart from allowing = to call the > set method) exactly like normal functions, you should note no > difference. > > It feels to me, that most problems arise due to the fact that we try to > make properties like fields (forbidding parentheses), which make them > essentially incompatible to functions, resulting in making all sorts of > things properties, which actually aren't, just so that no template > breaks. > > Maybe I should make this more clear in the DIP. I just went over this with Kenji in his thread "Partial modification of DIP23 to allow module level property." You _must_ be able to rely on front being a property. With any API that templates use, the exact syntax of the functions or properties used must be defined. Otherwise, you're going to be screwed by things like a templated function using parens to access a property working in some cases and not in others (because some types defined it as a function whereas others defined it as a property). Even worse, it _completely_ breaks properties which return delegates. front() _must_ make the call on the return value of front and not just call front. If front can sometimes be a function or sometimes be a property, then the code will function drastically differently depending on whether one or two sets of parens were used. It's bad enough that parenless function calls are legal, but if you let a part of your API be either a property or a function, you're asking for it. Code _will_ break at some point because of that inconsistency. Generic just code can't afford it. And when we're talking about something in the standard library, it's that much more critical. - Jonathan M Davis
Re: DIP26: properties defined
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.
Re: DIP26: properties defined
On 2013-02-09 11:31, Jonathan M Davis wrote: I just went over this with Kenji in his thread "Partial modification of DIP23 to allow module level property." You _must_ be able to rely on front being a property. front getter MUST be a property... as in RFC2119's MUST?? So all those 75 std @property ref T foo() are also here to stay for good? Bah, banning ref fixed some things, but now it's back to square one again. Maybe it's time to drop the property subject and move on? :)
Re: DIP26: properties defined
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.
Re: DIP26: properties defined
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.
>
Re: DIP26: properties defined
On Saturday, February 09, 2013 12:31:14 FG wrote: > On 2013-02-09 11:31, Jonathan M Davis wrote: > > I just went over this with Kenji in his thread "Partial modification of > > DIP23 to allow module level property." You _must_ be able to rely on > > front being a property. > > front getter MUST be a property... as in RFC2119's MUST?? > So all those 75 std @property ref T foo() are also here to stay for good? > Bah, banning ref fixed some things, but now it's back to square one again. > Maybe it's time to drop the property subject and move on? :) 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. - Jonathan M Davis
Re: DIP26: properties defined
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.
Re: DIP26: properties defined
On 2013-02-09 11:58:23 +, Jonathan M Davis 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.for...@michelf.ca http://michelf.ca/
Re: DIP26: properties defined
The DIP actually solves this. On Sat, 2013-02-09 at 02:31 -0800, Jonathan M Davis wrote: > I just went over this with Kenji in his thread "Partial modification > of DIP23 > to allow module level property." You _must_ be able to rely on front > being a > property. > > With any API that templates use, the exact syntax of the functions or > properties used must be defined. Otherwise, you're going to be screwed > by > things like a templated function using parens to access a property > working in > some cases and not in others (because some types defined it as a > function > whereas others defined it as a property). Even worse, it _completely_ > breaks > properties which return delegates. front() _must_ make the call on the > return > value of front and not just call front. If front can sometimes be a > function > or sometimes be a property, then the code will function drastically > differently > depending on whether one or two sets of parens were used. > > It's bad enough that parenless function calls are legal, but if you > let a part > of your API be either a property or a function, you're asking for it. > Code > _will_ break at some point because of that inconsistency. Generic just > code > can't afford it. And when we're talking about something in the > standard > library, it's that much more critical. > > - Jonathan M Davis
Re: DIP26: properties defined
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 +, Robert 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.
>
Re: DIP26: properties defined
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.
Re: DIP26: properties defined
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.for...@michelf.ca http://michelf.ca/
Re: DIP26: properties defined
On 2/9/13 5:31 AM, Jonathan M Davis wrote: With any API that templates use, the exact syntax of the functions or properties used must be defined. Otherwise, you're going to be screwed by things like a templated function using parens to access a property working in some cases and not in others (because some types defined it as a function whereas others defined it as a property). Even worse, it _completely_ breaks properties which return delegates. front() _must_ make the call on the return value of front and not just call front. If front can sometimes be a function or sometimes be a property, then the code will function drastically differently depending on whether one or two sets of parens were used. It's bad enough that parenless function calls are legal, but if you let a part of your API be either a property or a function, you're asking for it. Code _will_ break at some point because of that inconsistency. Generic just code can't afford it. And when we're talking about something in the standard library, it's that much more critical. Evidence has it the other way around. We've defined plenty of fine std ranges and algorithms before @property adorned front everywhere (something I'm looking forward to get rid of). Andrei
Re: DIP26: properties defined
On 2/9/13 6:31 AM, FG wrote: On 2013-02-09 11:31, Jonathan M Davis wrote: I just went over this with Kenji in his thread "Partial modification of DIP23 to allow module level property." You _must_ be able to rely on front being a property. front getter MUST be a property... as in RFC2119's MUST?? So all those 75 std @property ref T foo() are also here to stay for good? I hope not. Andrei
Re: DIP26: properties defined
On Saturday, 9 February 2013 at 09:45:25 UTC, Robert wrote: I am claiming that if we restrict ourselves to the property concept explained in the DIP, then the range API would no longer depend on front being a property, it can also be a function returning ref, which is perfectly legal for UFCS. I am further claiming that properties via get/set methods don't actually make sense outside of the entity that define them, I am glad if you could give an actual example that would prove me wrong. And because properties are treated (apart from allowing = to call the set method) exactly like normal functions, you should note no difference. It feels to me, that most problems arise due to the fact that we try to make properties like fields (forbidding parentheses), which make them essentially incompatible to functions, resulting in making all sorts of things properties, which actually aren't, just so that no template breaks. That was painful to read. Can you please answer AFTER what you quote ? Also, you don't address most of the point Jonathan raises, and that should probably be a sign that you are not mastering the topic enough.
Re: DIP26: properties defined
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
Re: DIP26: properties defined
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
Re: DIP26: properties defined
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 ?
Re: DIP26: properties defined
On 2013-02-09 15:30:13 +, "deadalnix" 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.for...@michelf.ca http://michelf.ca/
Re: DIP26: properties defined
On 2013-02-09 15:22:28 +, Jacob Carlborg 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.for...@michelf.ca http://michelf.ca/
Re: DIP26: properties defined
On Saturday, February 09, 2013 09:48:23 Andrei Alexandrescu wrote: > On 2/9/13 5:31 AM, Jonathan M Davis wrote: > > With any API that templates use, the exact syntax of the functions or > > properties used must be defined. Otherwise, you're going to be screwed by > > things like a templated function using parens to access a property working > > in some cases and not in others (because some types defined it as a > > function whereas others defined it as a property). Even worse, it > > _completely_ breaks properties which return delegates. front() _must_ > > make the call on the return value of front and not just call front. If > > front can sometimes be a function or sometimes be a property, then the > > code will function drastically differently depending on whether one or > > two sets of parens were used. > > > > It's bad enough that parenless function calls are legal, but if you let a > > part of your API be either a property or a function, you're asking for > > it. Code _will_ break at some point because of that inconsistency. > > Generic just code can't afford it. And when we're talking about something > > in the standard library, it's that much more critical. > > Evidence has it the other way around. We've defined plenty of fine std > ranges and algorithms before @property adorned front everywhere > (something I'm looking forward to get rid of). The problem of consistenty comes up once @property is enforced. Right now, it's just useless markings on a function. It affects -property, but all - property does is complain about normal functions being called without parens. It doesn't properly enforce @property. If @property is enforced, then as long as it exists, APIs used by templates will need to be consistent about it or you're going to run into to problems. Getting rid of @property will mean allowing stupid stuff like range.popFrontN = 5; as well as making it impossible for () to be used to called a delegate or other callable returned by what should be a property as well as impossible for a variable to be used in the place of a parenless function call, as it could be called with parens. Without explicit properties, we have no control over what's used as a property. I'd very much hate to see @property just because it was never really implemented and so some folks (like you and Walter) came to the conclusion that we had somehow proved that it didn't work or wasn't a good idea. It would have to actually be implemented for us to have any actual data on how well it works in D. Getting rid of it because it's not working doesn't make sense, because it's never been implemented in the first place. - Jonathan M Davis
Re: DIP26: properties defined
On 2/9/13 2:21 PM, Jonathan M Davis wrote: Getting rid of @property will mean allowing stupid stuff like range.popFrontN = 5; No. This again conflates getters with the setter syntax. Andrei
Re: DIP26: properties defined
On Sat, 2013-02-09 at 16:17 +0100, deadalnix wrote: > Also, you don't address most of the point Jonathan > raises, and that should probably be a sign that you are not > mastering the topic enough. Funny enough, when I read your posts I get the feeling you did not even read the DIP. Enough insulting for now?
Re: DIP26: properties defined
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 +, Jacob Carlborg 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. >
Re: DIP26: properties defined
On Saturday, February 09, 2013 14:56:56 Andrei Alexandrescu wrote: > On 2/9/13 2:21 PM, Jonathan M Davis wrote: > > Getting rid of @property will mean allowing stupid stuff like > > > > range.popFrontN = 5; > > No. This again conflates getters with the setter syntax. How? If you don't have explicit properties, then _any_ function which has the appropriate set of parameters can be used as a property function, and there are many functions (both free functions and member functions) which have that set of parameters but clearly aren't meant to be properties. popFrontN is just one of them. The only reason that this isn't a problem in DIP23 is the fact that it makes it so that the only way that you get the setter syntax is to use @property. Sure, you could decide that @property only applied to setters and let getters only be done via parenless functon calls, but you'd still need explicit properties for setters to avoid problems like range.popFrontN = 5;. And if you get rid of explicit getters, then you're still losing when it comes to stuff like delegates and the ability to swap out variables with property functions like you're supposed to be able to do with properties. - Jonathan M Davis
Re: DIP26: properties defined
On Fri, 08 Feb 2013 18:53:30 -0500, Robert 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
Re: DIP26: properties defined
> // this is a property
> int foo() {...}
It is, if you consider properties to be functions that can be called
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
when
> applied to a function: it enables the setter syntax and it changes
the
> 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)
Re: DIP26: properties defined
> 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. Why? Think about it, this thinking comes from the fact that it was considered to be a good idea that front could be anything including a field or even an enum. The question is why would we want to allow this in the first place. It is never used in the standard library, it breaks encapsulation and every field or enum can easily be turned into a trivial function. Maybe you are still referring to an early version of the DIP where I put there a sentence, (with a bad feeling already) that properties must not be called with (). I fixed this very bad mistake very soon afterwards, maybe you want to have another look?
Re: DIP26: properties defined
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.
