[phobos] Time to get ready for the next release

[Robert Jacques]

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.

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

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