diff options
| -rw-r--r-- | posts/2022-10-05-goops-issues.md | 42 |
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. |