Clipboards + Meaning

[Matt]

On Thu, 11 Dec 1997, David E. Manifold wrote:

> 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.

   The following is an example of what I mean:

	I have an image that's used as a parameter by a filter.  Instead
of giving it static data, I somehow establish that the source object
(maybe another filter - say one that's dependent on a time-value it's
given) is capable of providing data that the filter knows how to interpret
as an image.  Then, the time that's passed to the source changes, and it
needs to re-evaluate itself... or maybe IT's source changed.  It should
spawn a chain of re-evaluation that triggers all its dependents to
re-evaluate themselves.

	Maybe you don't want that, though, which I see as being solved by
feeding the source into a static container, which is used as the source
for the filter.

	I suppose I'm sort of pre-disposed to think about objects *doing*
things, though.  What interests me are extensible, distributed systems
that are able to tune themselves for efficiency.  I'm also interested in
elegant, abstract interfaces that promote a simplified model for relating
objects and controlling data-flow in basically any way that makes sense.


> >   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.

   Hmmm...  It's been a while since I've read the TUNES documentation.  I
ought to re-aquaint myself with it, before commenting on this.


> >   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)

  Actually, I mean organization as in 1D array, 2D array, etc.  IMO, one
ought to be able to feed a widget that outputs a 2D array of units that
can convert themselves into scalar values of a finite range into an image
filter.  The image filter only requires that its input are units that can
be converted into linear values of a finite range, and are arranged in a
2D array.  I agree that the number of bits, etc. is merely a detail, and
one that should be handled or exposed to the lll and the compiler.


> > > 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 ). 


  That sounds a little vague.  What I was specifically saying is
illustrated by this example:

  I have an object called a unit.  I have a function or something that
accepts units as inputs.  From unit is derived: integer, real, etc.  Now,
what I'm talking about doing, is deriving something from the unit object,
that can dynamically change whether it's derived from integer or real or
whatever else is derived from unit, and I can pass it to the function,
which will use unit object's interface to access it.

  At this point, though, I forget how I intended to relate that to what
you were talking about.


	Matt