Newsgroups: comp.object,comp.software-eng,comp.lang.java.tech,comp.lang.dylan,comp.lang.eiffel,comp.lang.sather,comp.lang.beta Path: news.daimi.aau.dk!news-feed.inet.tele.dk!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!howland.erols.net!feeder.chicago.cic.net!chi-news.cic.net!ftpbox.mot.com!mothost.mot.com!schbbs!news From: David Shang Subject: Accessors (Summary and Suggested Appoach) Content-Type: text/plain; charset=us-ascii Reply-To: shang@corp.mot.com Organization: MOTOROLA Date: Fri, 30 May 1997 04:27:31 +0100 Message-ID: <338E4923.5DF1@corp.mot.com> X-Mailer: Mozilla 3.01Gold (WinNT; I) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: news@schbbs.mot.com (SCHBBS News Account) Nntp-Posting-Host: 129.188.128.34 Lines: 177 Xref: news.daimi.aau.dk comp.object:72244 comp.software-eng:63078 comp.lang.java.tech:12681 comp.lang.dylan:17758 comp.lang.eiffel:30498 comp.lang.sather:13309 comp.lang.beta:11118 This is a summary of the thread of Accessors (Re: Features missed most in Java) and my recent thinking with a suggested approach. Comments are welcome! I have removed some irrelevant news groups, and added some language groups in which they have special treatment of accessors. OBJECTIVES The objective of accessor design should achieve the following goals: 1. Providing a uniform way for clients to access object members or attributes, so that the later change of the access protocol will not cause to rewrite the client program; 2. Optionally stronger: providing a uniform way for clients to access object members or attributes, so that the later change of the access protocol will not cause to recompile the client program; 3. When required, allowing disablement of accessors and use direct access for performance reason; 4. Allowing accessors designed on reference protocols so that special accessing (e.g. access network resources or persistent object) can be made transparently. That is, whether an object resides remotely in network or persistantly in disk or locally in memory, the method of accessing their attributes is identical and transparent to users. I find that goal 2 and 3 are conflict. If we decide the first time to allow some attributes to be accessed directly for performance, we cannot make these attributes to be accessed via accessors later without recompilation. Therefore, gola 2 and 3 cannot be satisfied for the same attribute the same time. Goal 4 is unique and curently supported only by Transframe. ALTERNATIVE SYNTAX In terms of syatax, there are two different approaches. One is the implicit, for example: obj1.a = obj2.b; implies two function calls: obj1.a_setter(obj2.b_getter()); The other is the explicit approach, for example: obj1.a(obj2.b()); in which "a" and "b" are expressed as functions directly, though some language may allow the absence of "()" for getters, for example: obj1.a(obj2.b); However, I don't think the syntax is very important. Either way, they should not prevent us from achieving our goals. ALTERNATIVE SEMANTICS Let us focus on semantics. In languages like Dylan and Sather, assigment is treated as a syntax sugar. That is, p.x = 3; is a syntax sugar for p.x(3); This macro approach disallows the goal 4. It is impposible to give a semantics based on the type of reference, since it is individually specific only. The explicit approach has the same problem. C++ allows overloading the operator "=", so that "=" can be defined generally on class-base. However, the performer of the operator '=' is targted to the object, not the reference to the object. As result, overloading operator "=" can only achieving a copying/converting semantics, which has nothing to do any of the goals we listed above. As a matter of fact, copying/ converting semantics can be achieved by other means, e.g. copy constructors. Transframe's accessor operators are defined in referential class. For example: class smart is referential#(exact ObjectType: type of any) { function operator . (): ObjectType; function operator := (ObjectType); } The declaration: x: SomeObjectType; declares a smart name (a reference) "x". And, expression: x := some_object; is eqiuvalent to the member function call: x.:=(some_object); because ":=" is a member function of the smart name. Users can define different reference protocols. For example, a "url" reference. However, this approach does not address goals 1 and 2. Therefore, I am considering adding some features to Transframe to fully achieve our goals. OPEN ISSUES The first open issue is about the attribute themselves. There are tree options: 1. Each attribute will automatically be associated with a setter and a getter function, no matter whether they are required or not; 2. Each attribute will by default be associated with a setter and a getter function. However, some attributes can be fixed with some specific specifier, if desired, for direct access. 3. Each attribute will by default be accesed directly (externally when public, or internally when private). However, some attributes can be declared with specific specifier to indicate that they are associated with accessor functions. The approach 1 does not satisfy goal 3. Approach 2 and 3 has no big difference, depending on how you see this problem. Both will have some imapct on goal 2. They requires that programmers should have visions on their desicions on what attributes should not be fixed or likely to be changed in future. My intention is to chose either 2 or 3. The impact on goal 2 is actually trival. The second open issue is that should we use explict accessor call syntax or impose extra semantics on assigment expressions. To use explict accessor call will add difficulty for me to achieve goal 4. I need extra semantics for accesor calls in addition to the reqular function call semantics. To use assigment will add extra semantics for assigment operator. It cannot be explained in a regular member function call semantics either. The only thing left for me to do is to chose one that is easier. The second approach seems better in terms of both formalization and implementation. Any good ideas and suggestions? David Shang