Attributes (was: Abstraction)

[Fare Rideau]

This is a second part to my reply, about Attributes.

> You suggest in Attributes under hll requirements [...]
Well, that was in HLL Semantics, and I admit the section
was not quite clear. Sorry. Below is what I just replaced it with.

> Your reply about Attributes I think confirmed what I didn't think was
> likely.  Is it simpler to think of attributes as components or members
> describing other objects?
Yes, definitely.


-- #f

------>8------>8------>8------>8------>8------>8------>8------>8------>8------
<LI><B>Attributes</B>
<UL>
<LI>Among objects, some are attributes.
<LI>Attributes can be thought of as unary functions that always
	return the same result when applied to the same object,
	which associates a value to every object.
<LI>Note on the Implementation of Attributes:
<UL>
<LI>A typical implementation of an attribute is as a "member"
	of a structure that implements the objects
	(see in C/C++ members of a structure or object;
	in Scheme, car and cdr of a cons cell or elements of vectors; etc).
<LI>Another typical implementation of an attribute is as a some kind
	of structure external to objects: for instance
	an association list or hash-table, that contains a set of object
	to value association pairs, where only one pair can be retrieved with
	for a given object; or an array indexed by numbers otherwise
	associated to an object can also be used.
<LI>Finally, an attribute can be implemented as an arbitrary
	procedure that takes an object as a parameter,
	and computes and returns the value associated
	by the attribute to the object.
<LI>An interesting symmetry with respect to this notion,
	is that we could exchange the role of objects and of attributes,
	and consider that an object associates a value to every attribute.
	This symmetry can be taken advantage in the implementation
	of attributes by exchanging the role of objects and attributes
	in the above techniques.
<LI>Multiple attributes may share structures or code,
	or deduced one from the other; they may be implemented
	partially using object-based attribute-to-value tables,
	and partially using attribute-based object-to-value tables;
	the implementation of a given attribute may change over time,
	so as to efficiently adapt to its changing usage pattern;
	tables of a modified object/attribute may be swiftly or lazily deduced
	from tables of the original object/attribute, etc.
<LI>Of course, any possible combination of all these techniques that
	a tortuous mind can think of may be used during the efficient
	implementation of an attribute.
<LI>All this to say that the language supports the notion of attribute
	<em>independently from any possible implementation</em>,
	so that programmers can focus on the semantics of it
	during program specification, and still be able to use arbitrarily
	nifty tricks when doing the implementation, instead of
	having to give the computer a bad compromise between them
	during a unique programming phase.
<LI>Similarly, it should be understood that the HLL allows as much
	decoupling as possible between specification of abstract semantics
	and of concrete implementation. Never should the programmer be
	tied to a given implementation of an abstract object, or to a
	given abstract view of a concrete object.
</UL>
<LI>Note that attributes are just particular objects,
and thus share other features with objects.
In particular, attributes can have attributes,
and can be associated as values to objects by attributes.
</UL>
------>8------>8------>8------>8------>8------>8------>8------>8------>8------