@property - take it behind the woodshed and shoot it?

[Adam Wilson]

On Thu, 24 Jan 2013 14:15:45 -0800, Robert Schadek <realburner at gmx.de>  
wrote:

> On 01/24/2013 10:56 PM, Adam Wilson wrote:
>> On Thu, 24 Jan 2013 13:54:09 -0800, Andrei Alexandrescu  
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>
>>> On 1/24/13 4:08 PM, Adam Wilson wrote:
>>>> On Thu, 24 Jan 2013 12:58:41 -0800, Andrei Alexandrescu
>>>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>>
>>>>> On 1/24/13 3:45 PM, Nick Sabalausky wrote:
>>>>>> On Thu, 24 Jan 2013 12:51:32 -0500
>>>>>> Andrei Alexandrescu<SeeWebsiteForEmail at erdani.org> wrote:
>>>>>> No, you merely came up with *some* specific cherry-picked examples  
>>>>>> that
>>>>>> sparked *some* debate (with most of the disagreing coming from
>>>>>> you).
>>>>>
>>>>> I simply mentioned three reasons that came to mind.
>>>>>
>>>>> Andrei
>>>>
>>>> While I don't approve of Mr. Sabalausky's tone or attitude, the crux  
>>>> of
>>>> his argument is logically sound. The problem with @property isn't
>>>> @property, it's D's insistence on optional parens. If paren usage was
>>>> clearly defined then this would be a non-issue. I would like to point
>>>> out that I can't think of another systems/general purpose language  
>>>> that
>>>> has an calling syntax specification as vague and convoluted as D's.  
>>>> C#'s
>>>> is brutally simple. Java's is brutally simple. In C/C++ everything is  
>>>> a
>>>> function or field, so, brutally simple.
>>>>
>>>> Make D's calling syntax simpler, end optional parens!
>>>
>>> Simplicity is clearly good, but there's something to be said about  
>>> those warts in chained calls. The UFCS-enabled idioms clearly bring a  
>>> strong argument to the table, there's no ignoring it.
>>>
>>> Andrei
>>
>> Then @property needs to be fixed such that optional parens don't effect  
>> it one way or the other. Removing the concept of properties and making  
>> functions that look like properties through optional parens is a very  
>> poor (and lazy) solution. As Mr. Ruppe pointed out, properties are  
>> DATA, and functions do stuff. That statement alone is an excellent  
>> argument for clearly delineating which is which... Properties are not  
>> functions.
>>
>
> At while you're at it, just get ride of:
>
> int[] a.
> a.length = 10;
>
> That this grows the array stills creeps me out.
>
> Robert

Well, from a syntax standpoint it's legitimate, and D's dynamic arrays are  
something I prefer over C#'s less flexible solution. My main problem with  
using it is that D's GC is absurdly naive. When this seemingly benign  
action causes your program to freeze for non-trivial fractions of a second  
for the millionth time, it can be quite despair inducing...

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/