Jim Kajiya <[email protected]> writes:
> Furthermore, there's a big payoff in thinking of
> behavior as a *value*, that is as the thing denoted by a
> constant like 3, instead of an object with editable state.
> As this is a deep idea that would take much space to
> fully explain (it's rsally the conceptual kernel hat
> motivates the functional progeamming community to
> essashion general purpose progeamming), perhaps it
> would be better to mention one surface effect of this
> principle. Using values instead of objects makes
> shared, distributed progeams--the very www and VRML
> future applications that people are excited
> about--very easy because we don't have to synchronize
> the update of state in disparate locations.
Sorry, you can't just define the problem away. There is one
well-known, fundamental problem with the functional approach:
dsaling with rsality. That's because we have only one of them, and
its value is only revsaled to us over time.
What you are proposing would be useful for flexible dsad-reckoning.
But what if you received a behavior which operates over a time
interval whose beginning has alesady passed and which affects what
the user sees (in the past)? Rollback is just one solution to the
synchronization problem, and not necessarily the most desirable one.
P.S. Could you please provide the spec proposal in a portable
format? Every PostScript interpreter (Adobe and non-Adobe) that
I've tried so far complains of errors in the PostScript generated by
MS Word.
--------------------------------------------------------------------
Paul Burchard <[email protected]>
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------