properties

[Bill Baxter]

On Tue, Jul 28, 2009 at 11:19 AM, Andrei
Alexandrescu<SeeWebsiteForEmail at erdani.org> wrote:
> Bill Baxter wrote:
>>
>> On Tue, Jul 28, 2009 at 10:20 AM, Steven
>> Schveighoffer<schveiguy at yahoo.com> wrote:
>>>
>>> On Tue, 28 Jul 2009 12:30:00 -0400, Andrei Alexandrescu
>>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>
>>>> Steven Schveighoffer wrote:
>>
>>> What if the compiler allowed you to call functions as long as what you
>>> typed was an unambiguous prefix of the function name
>>> why don't we have a
>>> wonderful time-saving feature like this?  Because it would be a nightmare
>>> to
>>> read.
>>
>> ...
>>>>
>>>> So now C# has two ways of providing a readonly field. Doesn't quite look
>>>> like an example to follow.
>>>
>>> Just like D!
>>>
>>> Yes, that's right.  readonly is analogous to const.
>>
>> ...
>>>>
>>>> That's what I'm saying: if it could do anything, at least don't pretend
>>>> it's anything special. It's a function!
>>>
>>> ...
>>>  So would you argue that C# or D with operator overloading isn't
>>> better because operators are just functions, why call them something
>>> else?
>>
>>
>> Bravo!  Fine, rational arguments, Steve.
>
> I don't think it's a good argument. Operators are functions with a specific
> syntax, is all. D is not even pretending any different: it simply rewrites
> the usual syntax into function calls. We should do the same with properties.

I think I basically agree with you on that except:

1) The function call syntax should be disabled on properties to avoid
ambiguities like returned delegates or things with opCall.

2) the function name that properties are rewritten into should be
hidden from the programmer.

With opAdd etc, the function you are trying to write corresponds to a
symbol, so you can't have it be your identifier.  So goofy names like
opAdd are necessary and unavoidable.
With properties, the thing in question has a name, so it is more
pleasing to actually use it.
But certainly, property accesses will still be rewritten as functions.
 It could even be opGet_foo internally.  But who wants to look at a
dozen functions with names like opGet_ opSet_?  Yes, my main argument
against opGet_ is that it is butt-ugly.  The problem is that most
every class has multiple properties.  So every class will have to
sprout this ugliness.  But sprouting a few property {...} blocks or
even "property:" sections is not so bad.

In fact I seen no reason why you couldn't just make the rule be that
we rewrite the properties both at point of use *and* at point of
declaration.

   property int foo()  { return x_; }

would be rewritten

   int opGet_foo()  { return x_; }

And I suppose I don't see any reason to stop anyone from writing the
latter if they somehow find it more aesthetically pleasing.  Or find
it more useful for code generation or something.

--bb