Clipboards + Meaning

[David E. Manifold]

On Wed, 10 Dec 1997, Matt wrote:

>   As an object changes in ways that affect those that have references to
> it, are messages somehow sent to those objects, so they know to
> re-evaluate themselves?

This behavior is completely customizable for each context.  The
user/programmer has the ability to change when objects evaluate.  So this
re-evaluation could happen immediately, or be delayed (until conditions
you specify), or be disabled.

>   Something like this would allow someone to write static image processing
> code that becomes animatable when the input changes, or you could also use
> it for batch rendering.

Yes, and the optimizer could decide on an optimization level, depending
on the response time required.  So if you previously only had one image at
a time, and then later changed the specification to display images in
rapid succession, the code could be optimized with the new information for
speed at being run in a loop.

>   Hase anything been done about units?  I've been thinking about this for
> a while.  It seems like you care about three things, with respect to data:
> 	1) organization of units
> 	2) type of units (meaning range, scale (log, linear, exponential,
> etc.)
> 	3) meaning of the units
> 
> 
>   When all these are defined, either a suitable interface to a data
> reference can be constructed, or the proposed interface can be accepted or
> rejected.

Everything in this system is an object.  Whatever your "units"  are, they
are objects too.  The (semantic) meaning of the object is the available
functions that operate on it.  The 'type' you describe is the object's
internal specification, for what data it will contain.

Organization is an ambiguous term.  For grouping objects together, you use
another object that says what objects are in the group.  If "organization" 
means low-level byte order, it is unnecessary to know this since you only
interface the object through its semantics.  When the functions that
access an object are translated to low-level, the low-level form uses the
same byte order that the low-level form of the object is in.  But this
correspondance is maintained by the dynamic compiler, so you don't have to
worry about it.  (You can specify the low-level form to remain static if
you want, for example to interface with a low-level format like ones that
exist today)
 
> > The path may also change at the very end, where byte order is defined.
> 
> 	By the way, were you just talking about (I forget the formal name
> of it), but objects can dynamically determine who they're derived from?
> That seems like a reasonable way to implement the behavior you were
> talking about.
> 

Thomas Farrelly was talking about what he called a 'dynamic format.'  I
requoted his text below.  I said that the path may change at the very end,
meaning all the abstraction levels are dynamic. 

>From s720@ii.uib.no Thu Dec 11 10:41:19 1997
>
>'picture' is an example of a simple dynamic format. The reason it is
>dynamic, is that you consult the data for the path to further data,
>thus the paths through such structures may change dynamically. But
>there is no magic to this changability or adaptability. It is all
>accounted for on the lower abstraction levels ( or in your case, the
>meta-objects form here to n ). 

David E. Manifold
tril@bespin.ml.org