Accessors (Summary and Suggested Appoach) 
Author Message
 Accessors (Summary and Suggested Appoach)

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

I have removed some irrelevant news groups, and added some language
groups in which they have special treatment of accessors.


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

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.


In terms of syatax, there are two different approaches.

One is the implicit, for example:

        obj1.a = obj2.b;

implies two function calls:


The other is the explicit approach, for example:


in which "a" and "b" are expressed as functions directly, though
some language may allow the absence of "()" for getters,
for example:


However, I don't think the syntax is very important. Either way,
they should not prevent us from achieving our goals.


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


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:


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.


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

Tue, 16 Nov 1999 03:00:00 GMT  
 [ 1 post ] 

 Relevant Pages 

1. Accessors (Summary and Suggested Appoach)

2. Accessors (Summary and Suggested Appoach)

3. Summaries of text (summary of info received)!

4. Summaries of text (summary of info received)!

5. Socket Accessor in VWNC 3.0?

6. Generate Accessors

7. Is the Generate Accessors text changeable?

8. Accessors code generator ...

9. Smalltalk accessors

10. Generate Accessors - Howto?

11. Lazy Accessor Questions

12. PARTS/LISTPANE and Btrieve accessor


Powered by phpBB® Forum Software