> So what is the thing we want to compose if it's not the state? It's the reactions that objects have when events flow across the system. What tends to define variation in evented applications isn't the state of objects themselves, but how they react to certain messages. Given that, we want to be able to compose these reactions to create new versions of the same object. ... Behaviors are a way of creating bite-sized, reusable reactions to messages.
Then a comparison with the conventional approach:
> The way events are traditionally done in most modern platforms, you end up with hidden collections of listeners that contain nameless functions. This hides a vital bit of information - how do you know what's going to happen at runtime and how would you change that? ... By comparison, behaviors carry more information and are bound at call time. We can freely modify their reactions at runtime just by replacing the map in the LT data structure. And if we ever want to know what an object is going to do, we just take a look at that object's set of bound behaviors.
Finally, he talks about tagging, which might seem unrelated, but then I also adopted a similar in my own reactive object system [1] for simlar reasons: I needed a way to externally abstract over objects to get them to behave in similar ways (and ya, I did dynamic mixins too, this is a fun field).
[1] http://research.microsoft.com/apps/pubs/default.aspx?id=1793...
In Lisp you won't use 'nameless' functions. Typically one uses symbols, which are late bound to functions. Thus the symbol table is the map we can modify. In a meta-object-based object system like CLOS, generic functions are mapped to symbols and they have 'maps' of methods which will be combined at runtime.
The Xerox PARC researchers who defined CLOS worked a lot on the problems (mixins, active values, open implementations, meta-objects in software, ...).
http://www.dreamsongs.com/Files/Incommensurability.pdf
I think Gabriel misidentifies this as a delta between science and engineering, but I think its more about the diff between communities. That we use different terminology, different sources, we have completely different underlying cultures. And you have to admit, the CLOS community is pretty unique, anyone looking from the outside is bound to have a very different frame of reference.
I've gone through as much CLOS work as I could, mixins inspired by an ice cream shop, active values (which are really just properties with custom get/set methods today) can serve as a nucleus for reactive programming but are not very sophisticated in managing change propagation (I think FRP signals are better, but you can clearly see the relationships). There is a lot there, but its not the end all of everything, their is some honest innovation going on here.
It is always interesting to see different object systems being used. I just hope we will get a honest review of it in a few months after it has been used to develop a large application like Light Table.
Tags? Classes.
Just data? In Lisp the code, the functions, the symbols, etc. already are data.
Sure one can build another dynamic object system and use fancy names for it. It is really difficult to count the number of times this had been done in the past.
A typical Lisp-based system which does that was Object Lisp:
Used by LMI for their user interface and by Coral for Macintosh Common Lisp (until Object Lisp was replaced by CLOS).The idea that a) one can add and remove behaviors (methods) and b) add and remove tags (classes / mixins / ...) at runtime is found in almost every Lisp-based object system. Operations for that are available in every system.
Lisp-based object systems are not that much a language, but more a collection of objects and classes which interact in a defined way. Called a 'system'. That's also we have the Common Lisp Object SYSTEM, and not the Common Lisp Object Language. CLOS is described in terms of objects and their interactions (classes and generic functions are objects themselves) - not so much as a grammar of language constructs.