8 ms·

What happens when multiple packages want to modify the same code?

by mastax 5y ago

derefr 5y ago
I have only the slightest passing knowledge of ELisp, but I believe it offers Aspect-Oriented Programming (AOP) facilities; most basically, chained decorators (i.e. replacing a function with your proxy for that function, where your definition of the function gets bound dynamically to the current definition of the function at eval-time; so the call your function makes to the “inner” function, could just be to another proxy wrapper function someone else already inserted.)
- db48x 5y ago
  That is the most complicated description of it I have ever seen, but it is accurate. In total there are ten ways to combine new advice with the existing set of methods, but the most commonly used are :before, :after, and :around. All the :before functions are called first, then the outermost :around function (which may or may not call the next :around function), then finally the :after functions. Also it is common to define explicit hooks, which are just lists of functions that you will call at documented points. This is functionally identical to advice, except that it is also a good signal that the author intended you to do so. The terminology is interesting too. Advice is deliberately modeled after the generic method combinators in Common Lisp. One of the authors of the Common Lisp spec, Gregor Kiczales, went on to define the term “Aspect–Oriented programming” and later developed AspectJ. Although the phrase appears nowhere in the documentation for Emacs Lisp, it is definitely appropriate!
  - derefr 5y ago
    I'd love to hear a more-concise description of what I just flailed around trying to describe; I'm always in the market for pithy explanations :)
    - db48x 5y ago
      Hmm. I don’t think concision is really the right way to go; below a certain length a description just becomes less precise and useful rather than better. I think that my own description should have had another paragraph or two, looking back at it. Or maybe we could both be more concise by just telling people to go read The Art of the Metaobject Protocol.
NoGravitas 5y ago
Usually packages don't modify code in core Emacs or in other packages. Often, they use package-supplied "hooks" to add behavior to other packages. Failing that, there's the possibility of 'advising' functions to add/change behavior at certain points without actually monkeypatching. I've never seen a distributed package actually monkeypatch anything, though it is something you could do in your personal config.
- natrys 5y ago
  Yeah and even in personal config one could use el-patch[1], to make monkeypatching future proof. [1] https://github.com/raxod502/el-patch https://github.com/raxod502/el-patch
tikhonj 5y ago
You know, I haven't thought much about this. I use a lot of third-party packages and have a lot of my own custom code, but things almost never interfere. In the few cases that crop up (for example, awkward interactions between org-mode's completion and the completion plugin system I use), it was so easy to add some code to my .emacs file to fix that problem that I had no real problems with it.

What happens when multiple packages want to modify the same code?

by mastax 5y ago

What happens when multiple packages want to modify the same code?

I have only the slightest passing knowledge of ELisp, but I believe it offers Aspect-Oriented Programming (AOP) facilities; most basically, chained decorators (i.e. replacing a function with your proxy for that function, where your definition of the function gets bound dynamically to the current definition of the function at eval-time; so the call your function makes to the “inner” function, could just be to another proxy wrapper function someone else already inserted.)

db48x 5y ago
That is the most complicated description of it I have ever seen, but it is accurate. In total there are ten ways to combine new advice with the existing set of methods, but the most commonly used are :before, :after, and :around. All the :before functions are called first, then the outermost :around function (which may or may not call the next :around function), then finally the :after functions. Also it is common to define explicit hooks, which are just lists of functions that you will call at documented points. This is functionally identical to advice, except that it is also a good signal that the author intended you to do so. The terminology is interesting too. Advice is deliberately modeled after the generic method combinators in Common Lisp. One of the authors of the Common Lisp spec, Gregor Kiczales, went on to define the term “Aspect–Oriented programming” and later developed AspectJ. Although the phrase appears nowhere in the documentation for Emacs Lisp, it is definitely appropriate!
- derefr 5y ago
  I'd love to hear a more-concise description of what I just flailed around trying to describe; I'm always in the market for pithy explanations :)
  - db48x 5y ago
    Hmm. I don’t think concision is really the right way to go; below a certain length a description just becomes less precise and useful rather than better. I think that my own description should have had another paragraph or two, looking back at it. Or maybe we could both be more concise by just telling people to go read The Art of the Metaobject Protocol.

NoGravitas 5y ago

Usually packages don't modify code in core Emacs or in other packages. Often, they use package-supplied "hooks" to add behavior to other packages. Failing that, there's the possibility of 'advising' functions to add/change behavior at certain points without actually monkeypatching. I've never seen a distributed package actually monkeypatch anything, though it is something you could do in your personal config.

natrys 5y ago
Yeah and even in personal config one could use el-patch[1], to make monkeypatching future proof. [1] https://github.com/raxod502/el-patch https://github.com/raxod502/el-patch

tikhonj 5y ago

You know, I haven't thought much about this. I use a lot of third-party packages and have a lot of my own custom code, but things almost never interfere. In the few cases that crop up (for example, awkward interactions between org-mode's completion and the completion plugin system I use), it was so easy to add some code to my .emacs file to fix that problem that I had no real problems with it.