digitalmars.D - property as proposed in various DIPs, my attempted use and what I
- Rob T (34/34) Feb 20 2013 Has anyone really tried to use @property assuming the optional
- Jonathan M Davis (21/25) Feb 20 2013 I don't understand this. You make it a property function if it's intende...
- Rob T (67/67) Feb 20 2013 Here's a C# link providing a definition of property
-
Stewart Gordon
(13/21)
Feb 21 2013
- Zach the Mystic (71/98) Feb 21 2013 I was the author of the idea of using structs as properties.
- Mike Parker (22/34) Feb 21 2013 For me, there's no guessing. Either something is a property, or
Has anyone really tried to use property assuming the optional assignment syntax will be depreciated? I have. The results I'm getting is a ton of property tags in my structs and classes, much more than I had expected. In one struct, almost all the functions are tagged property. I know I can wrap them in property: or property{} but the side effect of that is that I must be aware of where I'm locating all of the property functions vs the non-property functions. In the case where most of my functions get tagged, it's a pain to be forced to locate them inside the wrapper. In an effort to reduce the use of property, I have to guess if I'm really going to use a given function with the assignment syntax or not, but that's something I prefer not to be constantly thinking about, so the tendency is to defer the question and simply avoid using property completely. The reality is that I often don't know if I'll be using one syntax over the other until usage experience is gained and the usage context determines the answer. I may even want to use both forms depending on the use context. So I'm seriously considering deleting all of the property tags already added and to stop inserting new tags, because even if they somehow can add value, there's definitely far too much clutter involved causing the opposite of "value". I just don't want to have to think about something that has no clear answer until later down the road (if at all). My attempted use of property indicates that most people will simply not use it and instead use the regular function form - it's much easier that way. You may switch to property for the rare situations where an exposed struct/class variable is later changed into function form, but for me anyway using exposed variables in production code is an extreme rarity - I only do that with experimental throw away code. My two cents, thanks for listening. --rt
Feb 20 2013
On Wednesday, February 20, 2013 20:41:24 Rob T wrote:The reality is that I often don't know if I'll be using one syntax over the other until usage experience is gained and the usage context determines the answer. I may even want to use both forms depending on the use context.I don't understand this. You make it a property function if it's intended to be used as if it were a variable. If it's not, then you don't mark is a property. Done. Where's the confusion? The very nature of the function should make it clear whether it makes any sense for it to be treated as a variable or not. And I'd argue that you're using properties incorrectly if you're trying to use something both as if it were a variable and as a function. There are occasionally grey areas (like when something generally would make sense as a variable, but sometimes requires additional arguments that change it's behavior - e.g. std.datetime.Clock.currTime or std.path.baseName), but that usually just means that it should be made into a function and be done with it, and in my experience, such occurrences are relatively rare anyway. So, I have no clue what you're up to that you're experiencing much confusion on this matter. what constitutes a property (though I don't have the link readily available at the moment), which should make it clearer. But in general, all you should have to do is ask yourself whether it makes sense to treat the function as if it were a variable. If it does, then it makes sense for it to be a property. If it doesn't, then it doesn't make sense for it to be a property. - Jonathan M Davis
Feb 20 2013
http://msdn.microsoft.com/en-us/library/x9fsa0sw.aspx concept that had been proposed as solution to the property question, it is clearly not the same thing as the property concept. construct because in one shot you are defining both the variable instance and the way it is accessed, i.e., it may help somewhat with organizing your code, if there's scoping rules restricting access, that may help too. In the D case, you must always define the variable instance outside the property scope, and then create a getter and setter for it separately. This is the usual way of doing things, with the only exception that when tagged with property you can use the assignment syntax, so for the most part its only a question of what calling syntax is more convenient to use, assignment or regular function call syntax. I can see an advantage that would make the situation a whole lot clearer. If internal to a stuct or class, you are accessing the local member variable directly, but later decide to wrap it so that it cannot be accessed directly (unfortunately this is impossible in D because of the way scoping works), you could rename the variable and wrap it into a property, and all your internal code will continue to work (but this depends on what you were doing with it). Externally, I never make variables directly accessible (unfortunately in D this is not 100% possible due to scoping rules, eg private has no effect inside a module), so there's not much value to the property concept in my case because I'll only very rarely switch from a variable to a function wrapper. For me, I have to decide if the assignment syntax is more convenient or not, and that's all I have to go with when making a decision. It would be far more useful to have a namespace implementation, because then I could 100% hide access to a variable, and that would make using such a facility much more clear, ie., it becomes a question of accessibility vs a matter of purely syntactic taste. Without a clear purpose behind it, the property concept buys me virtually nothing but syntactic sugar, except in the rare case where I may want to wrap a variable into a function after using it directly for a while, but even that is weak because the wrapper is a very leaky one, i.e,, you cannot 100% enforce access to go through the getter and setter from inside the struct and the module where it is used, and it does nothing in terms of helping me to define the wrapper scope, ie. there's no organizational advantages of grouping things together under one wrapper, and my code looks the same no matter if I use property or not. In summary, it seems to me that where there is an advantage, it's very weak and very rare, so for the most part it's a feature that boils down to if I want to use the assignment syntax or not. I don't think that was the intention of property, but that's how I see it. For me, the optional approach is more flexible and does the exact same job as property proposal. I can easily wrap a variable without specifying property and get the same job done, and I can choose which syntax is more convenient at a later date and change it depending on the context. If you want a more clear case for properties, then limiting access through scoping should come into the equation, as well as giving the programmer a better means to structure and organize the code around wrappers. property does not help with any of this. My opinions are based on actual attempts to use property in production code and I found little use for it. Have you tried to use it under real world situations? --rt
Feb 20 2013
On 20/02/2013 20:32, Jonathan M Davis wrote:On Wednesday, February 20, 2013 20:41:24 Rob T wrote:<snip> I entirely agree. I don't have as much time to read the 'groups as I used to, so haven't managed to follow all the discussions about it. It's hard to say what are the main advantages of property over making every function with zero or one parameter usable as a property. But I've come to like it since it was introduced. And it's useful not only to programmers, but also to documentation generators. In any case, some of the suggestions seem worse than what we had before property.... Perhaps the only change I'd vote for is dropping the , which doesn't seem to mean anything. Stewart.The reality is that I often don't know if I'll be using one syntax over the other until usage experience is gained and the usage context determines the answer. I may even want to use both forms depending on the use context.I don't understand this. You make it a property function if it's intended to be used as if it were a variable. If it's not, then you don't mark is a property. Done. Where's the confusion?
Feb 21 2013
On Thursday, 21 February 2013 at 23:17:53 UTC, Stewart Gordon wrote:On 20/02/2013 20:32, Jonathan M Davis wrote:I was the author of the idea of using structs as properties. Description here: http://forum.dlang.org/thread/ririagrqecshjljcdubd forum.dlang.org I believe that while their advantage comes from their power and flexibility, their disadvantage is a slight syntactic overhead. With Phobos standard formatting, the following two randomly selected properties: property size_t length() nothrow pure const safe { return impl ? impl.nodes : 0; } property bool empty() nothrow pure const safe { return length == 0; } ... would become: length struct { size_t opGet() nothrow pure const safe { return impl ? impl.nodes : 0; } } empty struct { bool opGet() nothrow pure const safe { return length == 0; } } With my syntax, a one-line getter requires the line to be longer by seven characters: property size_t length() { return impl.length; } versus: length struct { size_t opGet() { return impl.length; } } Taking this into consideration, and if people have no more creative uses for properties than as getters and setters (i.e. they didn't need or want the full power of structs), I could well see: get size_t length() nothrow pure const safe { return impl ? impl.nodes : 0; } set size_t length(size_t) { return impl.length = size_t; } ...as better looking and more precise than: property size_t length() nothrow pure const safe { return impl ? impl.nodes : 0; } property size_t length(size_t) { return impl.length = size_t; } Of course, I don't want to abandon structs as properties. Of course I am biased, but my ideal solution would be for the get and set properties above to be syntax sugar for: length struct { size_t opGet() nothrow pure const safe { return impl ? impl.nodes : 0; } } length struct { size_t opSet(size_t) safe { return impl.length = size_t; } } Unfortunately, this would cause a duplicate declaration, and you'd be forced to do this: length struct { size_t opGet() nothrow pure const safe { return impl ? impl.nodes : 0; } size_t opSet(size_t) safe { return impl.length = size_t; } } ...when you had more than one overload. But the latter one is better organized and looks nicer, so I personally wouldn't mind converting this way. (note: 'opSet' is intended to be a natural and better looking alias to the eventually deprecated 'opAssign'. 'opOpSet' replaces 'opOpAssign', etc. This is my ideal world we're talking about here.)On Wednesday, February 20, 2013 20:41:24 Rob T wrote:<snip> I entirely agree. I don't have as much time to read the 'groups as I used to, so haven't managed to follow all the discussions about it. It's hard to say what are the main advantages of property over making every function with zero or one parameter usable as a property. But I've come to like it since it was introduced. And it's useful not only to programmers, but also to documentation generators. In any case, some of the suggestions seem worse than what we had before property.... Perhaps the only change I'd vote for is dropping the , which doesn't seem to mean anything. Stewart.The reality is that I often don't know if I'll be using one syntax over the other until usage experience is gained and the usage context determines the answer. I may even want to use both forms depending on the use context.I don't understand this. You make it a property function if it's intended to be used as if it were a variable. If it's not, then you don't mark is a property. Done. Where's the confusion?
Feb 21 2013
On Wednesday, 20 February 2013 at 19:41:25 UTC, Rob T wrote:In an effort to reduce the use of property, I have to guess if I'm really going to use a given function with the assignment syntax or not, but that's something I prefer not to be constantly thinking about, so the tendency is to defer the question and simply avoid using property completely.For me, there's no guessing. Either something is a property, or it isn't. Period. If I have a class or struct member that is read-only, I use a property to access it. If I need to do some bookkeeping when a member is read or written to, I use properties. If I'm using a sort of facade, where a class is making use of another class or structure internally and I want to expose some of the internals, then I use a property. Example: struct FooData {...} class Foo() { private FooData _data; private this(FooData data) { _data = data; } public static createFoo() { return new Foo(loadFooDataFromSomewhere()) int bar() property { return _data.bar; } } It's a very clear, straightforward concept for me. createFoo is obviously not a property, but anywhere I would want to use a getBar(), I will instead prefer to use a property.My attempted use of property indicates that most people will simply not use it and instead use the regular function form - it's much easier that way. You may switch to property for the rare situations where an exposed struct/class variable is later changed into function form, but for me anyway using exposed variables in production code is an extreme rarity - I only do that with experimental throw away code.This is what makes no sense to me. And I think a sample size of 1 is not enough to extrapolate how "most people" will or will not use property. I use it throughout my D code quite satisfactorily.
Feb 21 2013