RFC: TUNES Specification Pre-Pre-Draft

[Brian T Rice]

On Fri, 21 Mar 2003, Jecel Assumpcao Jr wrote:

> On Friday 14 March 2003 05:03, Brian T Rice wrote:
> I found this definition a little strange:
>
>    Meta-Object: the term for an object which deals with the essential
> characteristics of another.

This was an entry I wrestled with and do expect to change, though I'm not
sure how significant the change should be. Here's the CLiki entry:

>> The term for an object whose sole focus of attention is another object.
>> It describes some feature or aspect of it.

>> There is a specialized use of this term, which may be characterized as
>> describing "universal" meta-objects, wherein the entire set of objects
>> that describe the original object in its existence as such are
>> collected or represented by a single object encompassing all those
>> aspects.

This is supposed to cover objects that describe other objects. Notice that
it's a /term/ and not a real definition; there's not a formal definitive
description in the contexts that have used it, whether in the CLOS system
or less so when Fare used it to describe Tunes.

In the Smalltalk world, this makes Classes meta-objects of their
instances, but also it covers things that Smalltalk doesn't cover, such as
Slot objects or even a Relation object if that's how your slots are best
expressed.

Of course you can claim that this definition of meta-object is relative;
what's interesting is that as we all know, a manifest Class meta-object is
not needed, but it is a means of expressing something about the base
object.

The bottom line, though, is that the "meta-object" term should not be tied
up in the implementation.

> To me, an object's base-level semantics are its essential
> characteristics. If you change those, you get a very different object.
> Its meta-level semantics are just implementation details: changing a
> transitory object into a persistent one, for example, doesn't change
> its essence.

Sure, but meta-objects are there just (or maybe "at least"?) to reflect
what is going on at the base level. How this is implemented is separately
specifiable, especially whether one set of meta-object types or another is
more directly represented in the memory layout.

Basically, if you are concerned about the definition of a "mirror"-like
meta-object compared to this, a mirror in Tunes would be one of many
possible mirrors, and none of them would inherently have more access to
the implementation than any other.

> One tip about Lyx ...

Thanks. Actually, I know to do this normally, but it just didn't occur to
me when working on this. I replaced the files with some that use
compatible fonts.

-- 
Brian T. Rice
LOGOS Research and Development
mailto:water@tunes.org
http://tunes.org/~water/