[phobos] Time to get ready for the next release

[Jonathan M Davis]

> On Thu, 21 Apr 2011 17:17:27 -0400, Jonathan M Davis <jmdavisProg at gmx.com>
> 
> wrote:
> >> On Thu, 21 Apr 2011 15:41:17 -0400, David Simcha <dsimcha at gmail.com>
> >> 
> >> 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- at 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