Games people play

[Georg Wrede]

Lars Ivar Igesund wrote:
> Do the search "sweeney site:digitalmars.com" at Google, and you'll find many
> posts from him in the oooooold D newsgroup, about 5 years ago.

This is the second. The man seems to know what he's talking about. A 
shame I forget what the rationale for eroding the difference between 
member and member function access in D?

> Fri, 17 Aug 2001 21:55:37 -0400 "Tim Sweeney" <tim xx epicgames.com>  writes:
 >> Thu, 16 Aug 2001 20:06:56 +0200 "Sheldon Simms" <sheldon xx
 >> semanticedge.com>
>> In D, get'ers and set'ers take advantage of the idea that an lvalue
>> is a set'er, and an rvalue is a get'er:
>>
>> class Abc
>> {
>> int myprop;
>> void property(int newproperty) { myprop = newproperty; } // set'er
>> int property() { return myprop; } // get'er
>> }
>>
>> which is used as:
>>
>> Abc a;
>> a.property = 3; // equivalent to a.property(3)
>> int x = a.property; // equivalent to int x = a.property()
> 
> Why??!? :-) In current reasonable languages "a.x" is a variable access and
> "a.f(x)" is a function call.
> 
> Why complicate this so that "a.x" could either be a function call or a
> variable access, depending on its (possibly very complicated) context?
> 
> Also, this seems to create ambiguity (or context-specific special-casing of
> sematics) with function pointers. Given a reference to a function p taking
> a parameter, p=a could either mean calling it with a parameter of a, or
> initializing it to a.
> 
> I know Bertrand Meyer advocated this approach in Eiffel, but this has been
> shown to be one of several areas (along with, i.e. covariant typing on
> function parameters) where Eiffel's type system is unsafe and problematic.
> 
>> Thus, in D you can treat a property like it was a simple field name.
>> A property can start out actually being a simple field name, but if
>> later if becomes necessary to make getting and setting it function
>> calls, no code needs to be modified other than the class definition.
> 
> That breaks with open-world modules. For example, given a module declaring
> a class like:
> 
> class c
> {
> int a;
> };
> 
> How can you subclass it later on in another module like:
> 
> class d: public c
> {
> int a() {...}
> };
> 
> The similar question comes up with binary-compatible evolution of modules
> (i.e. Java's list of rules, "You can do the following things to evolve a
> class without breaking existing precompiled modules that depend on it".
> That's an essential thing that's vital to writing real-world programs, such
> as applications supporting plug-ins. The only sound solution to this is
> that every variable access in a program has to translate to a virtual
> function call, which obviously isn't reasonable.
> 
> -Tim
>