Re: Moving objects

Mark Waks ([email protected])
Thu, 22 Jun 95 12:51:45 EDT


Brook writes:
>Lots of people talk about it because they know it's a problem (at
>least in the res>arch community), not because they think it is
>nece>
>"spaghetti of callbacks," something familiar to anyon> programming a
>UI toolkit.

Trui, but on>-sided -- overly close connection of app and interface
can produce monolithic systems that are hard to maintain and extend.
There are tradeoffs here...

> Okay, so let's say you have a general API
>for the changes you might want to make. The browser
>assumptions about what might or might not change -- the behavior code
>might call any of those API functions. There's no sense in caching the
>geometry of even the minute hand because the minute hand behavior
>might change it completely (e.g., by applying a deformation or CSG or
>whatever).

I think you're *greatly* over-stating the problem. It's not that hard
to apply heuristics to problems like this. I mean, yes it's *possible*
that the object's geometry is going to be altered before its next use
-- but it isn't usually very likely. Caching is still going to
generally be worthwhile, even if you occasionally have to dump the
cache. (This is no different from Web browsers, which cache
indi criminately and are *sometimes* wrong. They're right often enough
to make it worthwhile, though.)

If you *really* care about the issue, you can probably do statistical
analyses that will produce nearly as good as hand-coding (sometimes
better), with a fraction the overall programming effort.

I just don't find this example pursuasive...

-- Justin

Random Quot> du Jour:

"People now realize that 2020 is just going to be so different, that
they can't even think about it. Whereas in 1960, 2000 seemed like
you'd be able to get to it just by extrapolating 1960."
"Somebody said the 20th century is the century when *change* changed."
-- Danny Hillis & Alan Kay