Is @property implementable?

[Jacob Carlborg]

On 2011-03-03 17:25, Jonathan M Davis wrote:
> On Thursday 03 March 2011 01:31:38 Jacob Carlborg wrote:
>> On 2011-03-03 08:16, Jonathan M Davis wrote:
>>> On Wednesday 02 March 2011 23:12:43 %u wrote:
>>>>> Well, it wouldn't be universal then. For a function to be treated
>>>>
>>>> as a property, it would require an annotation, but universal
>>>> function call syntax isn't supposed to require an annotation any
>>>> more than calling a function on an array as if it were a member
>>>> function requires an annotation. It's supposed to work with any
>>>> function.
>>>>
>>>> So are you saying a hypothetical function like
>>>>
>>>>       char[] strcpy(char[] destination, const char[] source);
>>>>
>>>> should be callable like:
>>>>       myString.strcpy(myString2);
>>>>
>>>> ?
>>>>
>>>> Isn't that asking for disaster, since it does the exact opposite of
>>>> what the user expects (since the source and destination are
>>>> switched)?
>>>>
>>>> I think we need an annotation for this (even for arrays), since
>>>> otherwise it's too easy to go wrong.
>>>
>>> How are the destination and source switched? The arguments are in the
>>> exact same order, only now one of them is to the left of the function
>>> name. It's been like this with arrays for a long time. It's not going
>>> away, and it's not going to require an annotation. That would be a big
>>> change to the language, and the ability to call arrays like this is
>>> well-liked and often-used. And a number of people definitely want
>>> uniform function call syntax to be implemented so that it works for all
>>> types.
>>>
>>> I don't see what's easy to go wrong with this syntax. It's quite
>>> straightforward. It's been around for quite a while. And it's well-liked.
>>> It's not going to be changed. The only question is whether it's ever
>>> going to be implemented for types in general.
>>>
>>> - Jonathan M Davis
>>
>> What I think he means is, if you see a function call like this:
>>
>> myString.strcpy(myString2);
>>
>> You would expect "myString" to be the source and "myString2" the
>> destination.
>
> But that's not how the function is written. The left parameter is the
> destination. If myString.strcpy(myString2) is confusing, I would expect
> strcpy(myString, myString2) to be just as confusing. I don't see how using the
> member function call syntax like that makes it any more confusing. Not to
> mention, functions with a source and destination like that end up in both orders
> all the time, so I don't think that you can generally expect it in one order or
> the other anyway.
>
> - Jonathan M Davis

I think strcpy(myString, myString2) would be confusing as well but I 
think myString.strcpy(myString2) is a little more confusing than the 
other syntax.

-- 
/Jacob Carlborg