On Sun, Jan 11, 2009 at 12:52 PM, dsimcha <[email protected]> wrote: > I'm starting to think that this properties thing is becoming a hopelessly > complicated solution to a very simple problem. The issue that brought this > to a > head in the first place was foo = foo + 1 vs. foo += 1. Given that solving > this > case properly seems like a rather difficult problem, the solution of just > defining > foo += 1 to mean foo = foo + 1 (which is what was originally proposed before > issues about properties of user-defined types were brought up) is starting to > look > appealing. Yes, this might be inefficient on user defined types w/ operator > overloading, but so is the equivalent in other languages: > > SomeObject temp = myClass.getFoo(); > myClass.setFoo(temp + 1); > > I figure the vast majority of cases are going to be primitive types anyhow > (mostly > ints), and if someone defines operator overloads such that foo += 1 produces > totally different observable behavior than foo = foo + 1, that's just too > ridiculously bad a design to even take seriously. What do you think? Is it > worth > ignoring a few hard cases in exchange for solving most cases simply and > elegantly > and without adding any new constructs?
Well, foo+=1 is not the only issue. It may have been the one that brought it to a head this time, but the issue has come up in the past with the focus on fixing the ambiguities around allowing functions to be called without (). Mainly I think that ambiguity relates to properties that return callable things. If foo is such a property then it's not clear how to call the thing returned by foo. I think the only way to make such things make sense and be consistent is to disallow the implicit function call stuff. --bb
