Possible @property compromise

[q66]

On Thursday, 31 January 2013 at 14:28:39 UTC, Steven 
Schveighoffer wrote:
> On Thu, 31 Jan 2013 08:14:15 -0500, q66 <quaker66 at gmail.com> 
> wrote:
>
>> On Thursday, 31 January 2013 at 00:54:54 UTC, Steven 
>> Schveighoffer wrote:
>>> On Wed, 30 Jan 2013 03:05:37 -0500, q66 <quaker66 at gmail.com> 
>>> wrote:
>>>
>>>> On Wednesday, 30 January 2013 at 03:02:38 UTC, deadalnix 
>>>> wrote:
>>>>> On Wednesday, 30 January 2013 at 00:26:11 UTC, q66 wrote:
>>>>>> It deeply disturbs me that people even take the original 
>>>>>> post seriously.
>>>>>
>>>>> Well, you may give some arguments instead of no, just no, 
>>>>> to convince people.
>>>>
>>>> It just gives another meaning to foo.bar, and ENFORCING 
>>>> camelCase by the language while lowercasing shit is just 
>>>> horrible. Anyone with a slightest trace of language design 
>>>> sense realizes that.
>>>
>>> Apparently not the designers of objective-C.
>>>
>>> -Steve
>>
>> Not contradictory, Objective-C is not a well designed language 
>> :)
>
> Now we're just name calling ;)  I tend to think that for the 
> most successful company in the business to standardize on it is 
> a pretty good testimony to it being well designed.  I certainly 
> have grown fond of it, there are some really nice features in 
> it.  But truly, xcode has played a large role in making the 
> language seem good.
>
> As another option, what about changing my proposal so instead 
> of setX, it's set_x, and then casing concerns are eliminated?  
> I think C++.net does that.
>
> -Steve

No, that is not a solution either. Any of these setBlah or 
set_blah or whatever are ugly hacks. There should be explicit 
property syntax. By explicit, I mean explicit - at least like 
C#'s get/set stuff (and I don't really like C# either).