3 ms·

Common Lisp’s object system (CLOS) allows you to specify on a method by method basis whether or not the most-specific method has priority or the least-specific

Common Lisp’s object system (CLOS) allows you to specify on a method by method basis whether or not the most-specific method has priority or the least-specific one does. Generally people just use the default behavior—least specific first—but this post makes the alternative sound interesting.

deleted 9y ago
[deleted]
ScottBurson 9y ago
It also has daemon methods, which solve the problem of making sure the superclass gets to do something before, or after, the subclass method runs, without the subclass method having to request this explicitly.
- mst 9y ago
  Attempting to google variants on the them of "CLOS daemon methods" isn't bringing up anything recognisable as what you're describing - happen to know how to find a link? (I love it when my attempt to RTFM is defeated by my being too stupid to find the FM in the first place ;)
  - TeMPOraL 9y ago
    The FM for Common Lisp is called Hyperspec, or CLHS. Just append "CLHS" to your search query. The parent is probably talking about method combinations - in particular, the method combination used by default, which supports :before, :after and :around methods. It's the first time I see the term "daemon method".
    - ScottBurson 9y ago
      I guess the term isn't as common as I thought, but it appears to have been used explicitly in the Flavor system, which was the object system used on the MIT Lisp Machines and which predated CLOS. That must be where I picked it up.
      - lispm 9y ago
        A daemon / demon was a procedure which runs when a slot is accessed / added / deleted / .... My bet is that this name was used in frame languages in the end 70s where there were if-needed, if-added, ... demons for a frame slot. Flavors probably got it from there - though I'm not sure. But the concept/term of a demon goes back to the end 60s to Hewitt's planner language and probably even earlier. Later with generic functions in CLOS, I'd guess the term wasn't used, since something like an :after method is no longer conceptually a specific demon procedure attached to a slot via a facet, but a method in a method combination.
  - ScottBurson 9y ago
    Right, sorry, "daemon methods" is the collective term but may not actually appear in the documentation. There are three types, "before", "after", and "around"; there's a brief description at the bottom of this page: http://www.aiai.ed.ac.uk/~jeff/clos-guide.html http://www.aiai.ed.ac.uk/~jeff/clos-guide.html
  - grzm 9y ago
    Likely someone will provide a better reference, but here’s one I found you may find useful: https://franz.com/support/documentation/8.1/doc/flavors.htm#6.0%20Mixing%20flavors https://franz.com/support/documentation/8.1/doc/flavors.htm#...
  - carussell 9y ago
    From Yegge's "The Pinocchio Problem": > Great systems also have advice. There's no universally accepted name for this feature. Sometimes it's called hooks, or filters, or aspect-oriented programming. As far as I know, Lisp had it first, and it's called advice in Lisp. Advice is a mini-framework that provides before, around, and after hooks by which you can programmatically modify the behavior of some action or function call in the system. Not all advice systems are created equal. The more scope that is given to an advice system — that is, the more reach it has in the system it's advising — the more powerful the parent system will be. https://en.wikipedia.org/wiki/Advice_(programming) https://en.wikipedia.org/wiki/Advice_(programming)
fiddlerwoaroof 9y ago
I just noticed that I mistyped: I should have said that the default behavior was most specific first
kazinator 9y ago
It doesn't sound like such a great alternative to me. The derived class should have maximum flexibility. If I have to struggle with some OOP system where the chain of control is backwards and my derivation gets the control last, I'm just gonna throw my hands up and write my own thing from scratch and not use the inflexible stuff. This end-result is counterproductive, resulting in more work and code duplication. Or else I will wrap their objects with mine such that mine have new, unrelated methods that do not automatically yield control to those underlying object. My methods will call theirs at any point in the processing that I wish. Basically, I will get the last word no matter what, so either work with me by giving me a normal OOP system, or I will build detours around you anyway.

deleted 9y ago

[deleted]

ScottBurson 9y ago

It also has daemon methods, which solve the problem of making sure the superclass gets to do something before, or after, the subclass method runs, without the subclass method having to request this explicitly.

mst 9y ago
Attempting to google variants on the them of "CLOS daemon methods" isn't bringing up anything recognisable as what you're describing - happen to know how to find a link? (I love it when my attempt to RTFM is defeated by my being too stupid to find the FM in the first place ;)
- TeMPOraL 9y ago
  The FM for Common Lisp is called Hyperspec, or CLHS. Just append "CLHS" to your search query. The parent is probably talking about method combinations - in particular, the method combination used by default, which supports :before, :after and :around methods. It's the first time I see the term "daemon method".
  - ScottBurson 9y ago
    I guess the term isn't as common as I thought, but it appears to have been used explicitly in the Flavor system, which was the object system used on the MIT Lisp Machines and which predated CLOS. That must be where I picked it up.
    - lispm 9y ago
      A daemon / demon was a procedure which runs when a slot is accessed / added / deleted / .... My bet is that this name was used in frame languages in the end 70s where there were if-needed, if-added, ... demons for a frame slot. Flavors probably got it from there - though I'm not sure. But the concept/term of a demon goes back to the end 60s to Hewitt's planner language and probably even earlier. Later with generic functions in CLOS, I'd guess the term wasn't used, since something like an :after method is no longer conceptually a specific demon procedure attached to a slot via a facet, but a method in a method combination.
- ScottBurson 9y ago
  Right, sorry, "daemon methods" is the collective term but may not actually appear in the documentation. There are three types, "before", "after", and "around"; there's a brief description at the bottom of this page: http://www.aiai.ed.ac.uk/~jeff/clos-guide.html http://www.aiai.ed.ac.uk/~jeff/clos-guide.html
- grzm 9y ago
  Likely someone will provide a better reference, but here’s one I found you may find useful: https://franz.com/support/documentation/8.1/doc/flavors.htm#6.0%20Mixing%20flavors https://franz.com/support/documentation/8.1/doc/flavors.htm#...
- carussell 9y ago
  From Yegge's "The Pinocchio Problem": > Great systems also have advice. There's no universally accepted name for this feature. Sometimes it's called hooks, or filters, or aspect-oriented programming. As far as I know, Lisp had it first, and it's called advice in Lisp. Advice is a mini-framework that provides before, around, and after hooks by which you can programmatically modify the behavior of some action or function call in the system. Not all advice systems are created equal. The more scope that is given to an advice system — that is, the more reach it has in the system it's advising — the more powerful the parent system will be. https://en.wikipedia.org/wiki/Advice_(programming) https://en.wikipedia.org/wiki/Advice_(programming)

fiddlerwoaroof 9y ago

I just noticed that I mistyped: I should have said that the default behavior was most specific first

kazinator 9y ago

It doesn't sound like such a great alternative to me. The derived class should have maximum flexibility. If I have to struggle with some OOP system where the chain of control is backwards and my derivation gets the control last, I'm just gonna throw my hands up and write my own thing from scratch and not use the inflexible stuff. This end-result is counterproductive, resulting in more work and code duplication. Or else I will wrap their objects with mine such that mine have new, unrelated methods that do not automatically yield control to those underlying object. My methods will call theirs at any point in the processing that I wish. Basically, I will get the last word no matter what, so either work with me by giving me a normal OOP system, or I will build detours around you anyway.