Re: Metaclass & McCLIM revisited

On 30 Jan 2026, at 10:08, Yuri Davidovsky (as work at disclosure dot ie) <[email protected]> wrote:
> 
> I did not understand a lot of the email, mainly due to the fact that I rarely use CLOS, let alone MOP and the goal and the purpose of the things discussed eluded me. So I would start from asking what is the purpose of this dynamic variable binding to an object slot. As I understand it, you create a custom object instance and sort of fuse a dynamic variable into it?

Exactly so: you want an object with a slot whose value can be dynamically bound.

> 
> So when you access a slot value, you are actually accessing the value of the dynamic variable that the slot points to? This is what I understood.

You are accessing the dynamic value of the slot: there may or may not be a dynamic variable behind it.

> 
> But I did not quite get the purpose of it. Is the purpose that you will get a different value in the slot depending on the package you are using the class in? If so, why can’t you simply access the dynamic variable directly, why do you need this additional level of indirection?

No.  You want to be able to say something like (I am making up syntax here):

(binding-slots ((s1 v1) ...) o
  (do-something o))

Then within the entire dynamic scope of BINDING-SLOTS the value of its S1 slot will be V1 (unless you modify it).  And this should behave the right way with regard to threads: the binding should only bind the slot's value within the thread, not within other threads.

It's a long time since I used CLIM, but that's useful in places where you want some attribute of an object to behave differently in some dynamic scope.

This is rather easy to implement in CL if you're willing to live with an abstraction.  You can't use shallow binding (because you want multithreaded code to work), so you use deep binding.  Here's one approach.

There are objects called 'fluids' which hold a global value.   There is a special variable, say *s* which is the stack of fluid bindings.  To bind a fluid f to v you simply bind *s* to (cons (cons f v) *s*).  To access f's value you first use ASSOC to look it up in *s* and then fall back to the global value.

If you want a slot (or anything else) 'to have a dynamic value' you simply initialise it with a fluid, and then you access its value by accessing the fluid's value (so the accessor function accesses the value of the fluid, not the slot, whose value is never changed).

The whole thing is so simple that although I have a library for it, I typically just write it again each time I need it.  It's also portable, and, unless you have very deep stacks of bindings, fast.  You never have very deep stacks of bindings.

But, but but.  When you do this you will immediately be attacked by a howling mob.  Because, you see, SLOT-VALUE doesn't 'work' for this (it just accesses the fluid, not it's value), and the howling mob need it to work, because none of their code uses abstractions like accessors: they call SLOT-VALUE directly from user code.

The fluids code, you see, is portable and quick, but it is not PURE in their eyes.  And purity is all.  Purity requires SLOT-VALUE to work 'properly', and so the whole implementation must involve the MOP.  It will thus be nonportable and slow, but this is a small cost to pay for purity.  Purity is all.

I know this because I too used to belong to the MOP cult.  I have some robes I could sell you if you want to join.  The bloodstains are hardly visible now.

--tim

Just in case: the last three paragraphs are mostly a joke.  Don't send the mob.  I have a moat full of alligators.

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
[email protected]
http://www.lispworks.com/support/lisp-hug.html