Properties
Bill Baxter
wbaxter at gmail.com
Sat Jan 10 20:03:18 PST 2009
On Sun, Jan 11, 2009 at 12:52 PM, dsimcha <dsimcha at yahoo.com> 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
More information about the Digitalmars-d
mailing list