> On Thu, 21 Apr 2011 17:17:27 -0400, Jonathan M Davis <[email protected]> > > wrote: > >> On Thu, 21 Apr 2011 15:41:17 -0400, David Simcha <[email protected]> > >> > >> wrote: > >> > On Thu, Apr 21, 2011 at 3:39 PM, Jonathan M Davis > >> > >> [snip] > >> > >> >> I know that there are a number of people on the list - particularly > >> >> newer > >> >> posters - who fully expect @property to be strict and are surpised > >> > >> when > >> > >> >> it > >> >> isn't. And I see _zero_ problem with strong property enforcement as > >> >> long as > >> >> the compiler isn't buggy with regards to properties (which it > >> > >> currently > >> > >> >> is). > >> >> So, I'm 100% behind strict enforcement. > >> >> > >> >> - Jonathan M Davis > >> > >> What about the fact that no two people can agree what should and > >> shouldn't > >> be a property? Or, more practically, that third party library A won't > >> conform with organization B's coding policies? Or how about that an O(1) > >> property which gets re-factored into a big expensive O(N) operation > >> (i.e. > >> see bug 5813) Or ranges/containers that may all have different mixes of > >> function-like methods and field-like methods. Speaking of templates, > >> what > >> about how well/poorly opDispatch, etc compose with @property? Oh, and > >> then > >> there are entire articles against the @property solution to the > >> field/method syntax problem in computer science literature (look up the > >> Uniform access principle used in Ruby and Eiffel). > >> > >> Also, surprise isn't necessarily a bad thing. Methods-as-properties > >> surprised me I received when I first started using D and it put a > >> massive > >> smile of joy onto my face in the process. > > > > It's a property if it's marked with @property. If it's not marked with > > @property, it isn't. > > The concept of a property is entirely synthetic. It grew out of the desire > to utilize field access syntax with methods. It's also somewhat fluid > between languages, since in some it's exclusive, and in others it's not. > > > Programmers can argue until they're blue in the face > > about whether a function should be marked with @property and thus used > > as a > > property or not, but by strictly enforcing @property, it becomes > > completely > > consistent. > > But that's exactly the problem: without consensus _enforced_ consistency > means adapting yourself to one or more programming > styles/school-of-thought simultaneously.
It's enforced only insomuch as a function marked as @property then must use property syntax, and those not marked with @property can't use property syntax. If that's not the case, then what is the point of @property? What does it do? The _only_ case which I see where it gives you _anything_ is that @property could help distinguish where a callable value is returned by a getter, but if you're allowing property functions to be called without the property syntax, then that introduces an ambiguity which renders even that benefit of @property useless. Allowing for @property functions to be called with parens or non-@property functions to be called without parens leads to major inconsistencies in usage of functions, and generally makes @property pointless. Even if you make it so that @property functions can't be called with parens while allowing non- @property functions to be called without them, then that leads to inconsistent syntax for function calls and makes it harder to know whether something is actually a property function or not. I really don't understand what benefit there is in not strictly enforcing @property. Yes, the change will break code, but if you don't make it, then very nearly the only benefit of @property is to serve as documentation saying that that was the way that the programmer who wrote the function intended it to be called. > > Every @property functions is called as a property and no function > > which isn't @property is called as a property. > > But the fact that you're arguing this point shows that this isn't true. > The issue is that unlike fields, functions, objects, etc, no two people > really have the same concept of a 'property' in their heads. So when you > say 'property' and I say 'property', we can mean very different things. > This ambiguity is something fairly rare in programming languages; we > expect that 'noun_X' has a single specific meaning/concept and it doesn't. > So when someone talks about a 'property' they really mean as implemented > in C# (or Java or Python, etc). > > Sometimes I wonder if this is all a nomenclature issue; if > Methods-as-Properties was simply called Methods-as-Fields and it was > explained somewhere prominently as something unique to D with > examples/benefits X/Y/Z, would anyone have an issue with it? Yes. There will always be arguments over whether something is conceptually a property and should be marked with @property. But as far as the language is concerned, if @property defines whether the property syntax is used or not, then the programmer writing the function can dictate whether a function is a property function or not, and the calling of that function is then completely consistent. It also allows for the programmer to later make it so that an @property function is a variable instead. If @property isn't enforced, then you can't do that, and the interchangeability of public member variables and @property functions is supposed to be part of the point of properties in the first place. There is a difference between the concept of a property and whether a function is a property function or not. Programmers can (and sometimes do) argue until they're blue in the face about whether something is conceptually a property or not. Ideally, anything which is conceptually a property would either be a public member variable or a property function, but it's up to the programmer to determine whether they'll make a function a property function or not. Once it's a property function, then it should be treated as a property and use the property syntax. So, the correctness of whether a property function actually represents a conceptual property is irrelevant as far as calling the function goes. The programmer who wrote the function made a decision, and then that's the API. As long as that is strictly enforced by the compiler, it eliminates ambiguity on the manner. It could be a poor design decision to have made it a property function, but there's no ambiguity on the part of the compiler or in how the function should be used. > > And yes, there are definitely bugs with @property. They're going to need > > to be > > sorted out before @property is enforced, but the fact that bugs exist > > doesn't > > mean that we should never strictly enforce @property. > > I've been taking this into account and (hopefully) haven't been holding > quality of implementation against @property. If any of my arguments were > QoI issues, please let me know. The lack of chaining on some level at least is a quality of implementation issue (e.g. http://d.puremagic.com/issues/show_bug.cgi?id=2883 ). Whether chaining assignments calls both the getter and the setter or tries to use the return value of a setter (which it shouldn't have) is primarily a QoI issue. Most of what you've been discussing hasn't been, but some of it is at least partially a QoI issue. - Jonathan M Davis _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
