www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - property as proposed in various DIPs, my attempted use and what I

reply "Rob T" <alanb ucora.com> writes:
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
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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. Also, a number of people around here like to point people to C#'s guide on 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
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 20/02/2013 20:32, Jonathan M Davis wrote:
 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?

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.
Feb 21 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
Here's a C# link providing a definition of property

http://msdn.microsoft.com/en-us/library/x9fsa0sw.aspx

The C# implementation appears to fit closer with the namespace 
concept that had been proposed as solution to the property 
question, it is clearly not the same thing as the  property 
concept.

In the C# case, it may be a bit clearer when to use the property 
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
prev sibling next sibling parent "Mike Parker" <aldacron gmail.com> writes:
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
prev sibling parent "Zach the Mystic" <reachBUTMINUSTHISzach gOOGLYmail.com> writes:
On Thursday, 21 February 2013 at 23:17:53 UTC, Stewart Gordon 
wrote:
 On 20/02/2013 20:32, Jonathan M Davis wrote:
 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?

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.

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.)
Feb 21 2013