[phobos] Time to get ready for the next release

[Robert Jacques]

On Thu, 21 Apr 2011 19:26:16 -0400, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

>> 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.

First, you've correctly identified the point of @property. And second, I  
believe everyone wants calling @property functions using parenthesizes to  
be disabled. Honestly, so far @property is only a keyword in D, which is  
somewhat confusing to D newbies.

> 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.

Why is this a benefit? Since your concept of a 'property' differs from  
mine, @property can only muddy the waters (unless we're both writing code  
using the same standards document). Being able to switch between call  
styles, allows me to self document my own (or my company's) guide-lines  
into the code. Besides, why should I care if something is a 'property'  
function or a regular function? or even a field, for that matter? There's  
field syntax and there's method syntax, but why should the library care  
how I choose to access their code? They don't have to read/review it. I  
(and my team/managers, etc) do.

> 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.

First, strictly enforcing @property, has to provide a tangible benefit in  
order to justify breaking code. (Well, beyond @property calls using ()s)
Second, both David and I have been pointing out use cases and examples of  
code and API designs which fundamentally can not be expressed under a  
strict @property enforcement.

>> > 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,


Actually, you can do that without @property in languages which implement  
the uniform access principal:  
http://en.wikipedia.org/wiki/Uniform_access_principle.
And practically, you often can't revert from a 'property' to a method, due  
to inheritance, etc.

> and the interchangeability of public member variables and
> @property functions is supposed to be part of the point of properties in  
> the
> first place.

And it's also a major point of Methods-as-Fields, and of the Uniform  
Access Principal.

> 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.

True, but remember the only ambiguity that exists with the current system  
is with field of a type which is callable with no arguments being upgraded  
to a 'property'. And then its mainly an issue of having to fix all the  
compilation errors, though silent program changes are possible.

>> > 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.

Well, I've been assuming that chaining of getters would work. It's method  
chaining of setters which I've been highlighting and that's not a QoI  
issue; @property simply can't handle them.