summaryrefslogtreecommitdiff
path: root/posts
diff options
context:
space:
mode:
authorDavid Thompson <dthompson2@worcester.edu>2022-10-05 15:49:01 -0400
committerDavid Thompson <dthompson2@worcester.edu>2022-10-05 15:49:01 -0400
commitaa69a1248f2dec947c8f4c067d26fb13043b5fa9 (patch)
tree36c0fa0bd27e09e8aac616a813410ca80e906ba8 /posts
parent8803fe841fa182c751b44fb0a12e4c8308d15b8f (diff)
Add more details to latest post.
Diffstat (limited to 'posts')
-rw-r--r--posts/2022-10-05-goops-issues.md42
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.