[Bese-devel] trees, threads, and places oh my!

[Marco Baringer]

one thing i forgot to mention:

the current component place stuff has _nothing_ to do with html
generation, the rendering protocol has not changed. let me explain:

previously when you call'd a component we simply created an instance
of the proper object, dumped it in the current frame's component slot
and rendered it. Now call'ing is a two component operation[1], we have an
explicitly named "caller" and "callee", as before the calle knows (via
the calling-component slot) who the caller is, the only difference is
that now the callee does not get put into the current frame's
component solt but it gets put in the caller's place. when the callee
answers the caller is put back in the place. however, we continue to
call render-on on the frame's component, so this swapiing around of
component could actually have no visible effect on the generated pages
(not that i can think of a reason for actually doing this). does this
make any sense?

for example, see the new example-app component. it sets it's place to
a lost of itself, this way when example-app is the caller the calle
gets put in example-app, not in the current frame's component slot
(which is where example-app happens to live). whether this is a cool
usefull technique or just really really confusing is debatable.

the second thing to notice is that places are not limited to a single
position in memory, a place is simply an object which specifies 3
things: 1) how to get the current value of the place, 2) how to set
the current value of the place and 3) how to copy the value in the
place. so if you were so inclined you could have a place which
corresponded to a hash table, a slot in a class and the car of a list,
or you cloud have a place which simply did did nothing (again, i can
think of no use for these "blackhole" places, but it's easier to allow
them then to disallow them).

[1] - it was this way before as well, except the calling component was
always the current frame's component slot.

p.s. - one of the coolest things about lisp is that i con first define
a very generic, very correct, api for something and then later, after
having used it for a bit, code up the common idioms in macros. someone
should write some advocacy about how lisp (common lisp in particular)
makes it possible (and easy) to have generic apis and idiomatic uses
of the apis live peacfully together.

-- 
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
     -Leonard Cohen