While we're lynching features, how bout' them omittable parens?

[Rainer Deyke]

Nick Sabalausky wrote:
> D leaves the function/property distinction up to the caller, which is 
> rediculous because in most cases only one or the other actually makes sense. 

I totally agree with this.

> C# places the responsilibily for that function-syntax/property-syntax choice 
> on the callee instead, where it belongs.

C#'s properties are a bit syntax-heavy for my taste.  I'd be happy with
this:

class C {
  void set_x(int);
  int get_x();
  int f();
  int y;
}

C c;
int i = c.get_x(); // Obviously allowed.
i = c.x; // Short for 'c.get_x()'.
c.x = i; // Short for 'c.set_x(i)'.
i = c.get_y(); // Even this is allowed.
c.set_y(i); // And this.
//i = c.x(); // But not this.
//i = c.f; // And not this.


This would still leave choice of syntax on the caller side, but it would
remove the ambiguity between method calls and properties.  'c.get_x()'
is clearly trying to read a property and 'c.set_x(i)' is clearly trying
to set a property, even if they use method call syntax.

Unfortunately, this doesn't mesh well with the camelCase capitalization
style.  I'm not fond of camelCase in the first place, but camelCase
seems to be so entrenched in the D culture that there is no hope of ever
removing it.


-- 
Rainer Deyke - rainerd at eldwood.com