Add more details to latest post.

1 files changed, 42 insertions, 0 deletions

diff --git a/posts/2022-10-05-goops-issues.md b/posts/2022-10-05-goops-issues.md
index c9925b3..2685279 100644
--- a/posts/2022-10-05-goops-issues.md
+++ b/posts/2022-10-05-goops-issues.md
@@ -170,6 +170,27 @@ without introducing backwards incompatible changes.
 support these qualifiers and the method dispatching system could be
 changed to accomodate them.
 
+## No controller over method combination algorithm
+
+This is related to the qualifier issue.  Those before/after/around
+qualifiers are part of the standard CLOS method combination algorithm.
+There are other ways to combine methods in CLOS and generics can be
+configured to use a non-standard one:
+
+```lisp
+(defgeneric multi-greet (p)
+  (:method-combination progn))
+```
+
+The `multi-greet` generic would call *all* of the primary methods
+associated with it, not just the most specific one.  I haven't seen a
+way to control how methods are applied in GOOPS.  Adding this feature
+would be complicated by the fact that generics do not have a fixed
+arity, but I think it would still be possible to implement.  Maybe for
+the GOOPS version of the `progn` combination, GOOPS would call all of
+the primary methods that match the number of arguments passed to the
+generic and ignore the others.
+
 ## Method arguments can only be specialized by class
 
 CLOS supports specializing method arguments on more than just classes.
@@ -286,3 +307,24 @@ documentation strings for methods, too?  The documentation for a
 generic could then be the union of its own documentation and any of
 its methods that have documentation.  There's probably a reason why
 CLOS doesn't do this and it would be best to understand that first.
+
+## No control over method combination
+
+`defgeneric` in CLOS allows for customizing how methods are combined
+via the `:method-combination` option.  GOOPS provides no such control,
+at least the documentation doesn't point out anything.  There is a
+generic `add-method!` procedure but it's not clear to me if that could
+be hacked to change how methods are combined.  Even if it could, it's
+a lot less pleasant than CLOS.
+
+## Generics cannot be merged outside of a module
+
+If I'm writing a Guile script, not a library module, I use
+`use-modules` to import the modules I need to get the job done.
+However, if two or more modules export a generic with the same name,
+there's no way to tell `use-modules` that I'd like them to be merged
+into a single generic.  Merging generics is an option when using the
+`define-module` form, but it doesn't feel right to use it when you're
+not actually writing a reusable module and it feels weird to have to
+change the syntax of how I'm importing modules just because generics
+are present.