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

[Robert burner Schadek]

On 01/24/2013 11:32 PM, Adam Wilson wrote:
> 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...
>
Yes, the syntax is legit. It's the semantic that "scares" me. IMHO it 
feels strange that assigning a variable resizes a array. Something like 
a.resize(10) would make me feel better.