Function calls

[Pelle Månsson]

On 01/29/2010 02:21 AM, Nick Sabalausky wrote:
> "Andrei Alexandrescu"<SeeWebsiteForEmail at erdani.org>  wrote in message
> news:hjtbjh$pbg$1 at digitalmars.com...
>> Nick Sabalausky wrote:
>>> "Pelle M�nsson"<pelle.mansson at gmail.com>  wrote in message
>>> news:hjt46j$5qt$1 at digitalmars.com...
>>>> I don't understand what any of this would improve. Is the byLine example
>>>> less readable without the ()? Is it more bug prone?
>>>>
>>>> The only thing achieved as I can see is that every class designer makes
>>>> up his own rules about which functions are property and which are not.
>>>> If this is somehow enforced, it will become a guessing game about how to
>>>> call no-argument functions. For what?
>>>
>>> Class "Foo" has member "bar". Is "bar" a member variable or a member
>>> function? Can you set it? Does it require arguments? You don't know, do
>>> you? It's a guessing game.
>>>
>>> To the caller, *properties are not functions*! I don't understand why we
>>> keep having to go in circles on this. They are data. Data, data, data.
>>> Not functions. Data. "Oh, but no, they're *implemented* as functions!"
>>> Who gives a crap? That's *implementation*. They're data. Data, data,
>>> data. With the proposal, if I use a class, that class has data and
>>> functions. Not "member variables, functions called with parens, and
>>> functions called without parens." Just data and functions. That's it.
>>> Data and functions.
>>>
>>> So if this is enforced, and you have a function, how do you call it?
>>> *With parens*! Why? Because it's a fucking function and functions are
>>> fucking called with parens! For god's sake, C# has had this for years,
>>> and nobody ever wonders "Do I use parens?" in C#, because if you're going
>>> to use something, you already know damn well if it's a function or data.
>>> Because if you don't know what the hell it is, you can't f***** make
>>> sensible use of it anyway.
>>
>> Relax, we're all on the same boat. Unfortunately, your view that it's all
>> functions and data is simplistic - it works well only when we talk about
>> returning simple data types. I, too, wish it were that simple.
>>
>
> The only catches in the idea of the caller seeing it as all data and
> functions are issues that are equally true regardless of whether properites
> are done the C# way or the D1 way.
>
> So ok, strictly speaking, there's functions and then there's data that comes
> in two flavors. But that still does absolutely nothing to change my point
> that removing optional parens creates *no* guessing game that we don't
> already have because it's still functions (use parens) and data (regardless
> of what type of data, don't use parens).
>

I don't think this definition really works. byLine returns a range, so 
it's data? If it's changed to an opApply based loop, is it still data? 
Where is the line between a simple function returning data and just data?

I think @property can be used to change the assignment, but not how the 
"get"-part of the function is called.