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