ChatGPT is also split...: Given the circumstances, I would recommend extending define-method rather than introducing define-method*.
Here’s why: 1. *Consistency and Simplicity*: By extending define-method, you avoid creating a dual system where users have to choose between define-method and define-method*. This reduces cognitive overhead and makes the API cleaner. 2. *Backwards Compatibility*: As long as the extension maintains backwards compatibility—e.g., methods defined without optional, keyword, or rest arguments continue to work as before—there’s minimal risk of breaking existing code. 3. *Ease of Use*: Users generally prefer fewer forms to remember. Adding more features to the existing define-method aligns with the principle of least surprise for anyone using GOOPS. 4. *Future-Proofing*: Creating a parallel form like define-method* could set a precedent for duplicating functionality every time a significant feature is added, leading to API bloat over time. The counterargument might be that adding optional, keyword, and rest arguments complicates define-method’s semantics. However, if these features integrate naturally and don’t break current assumptions, the benefits of a unified approach outweigh the risks. My confidence in this recommendation is 85%, as the best decision ultimately depends on the specifics of your user base and how GOOPS is typically used. If there's significant risk of confusion or breaking changes in the extension, introducing define-method* might then become a better option. 4o You said: But Guile already has define* and lambda* forms... ChatGPT said: The existence of define* and lambda* in Guile suggests a precedent for introducing parallel forms to extend functionality. This could justify introducing define-method* for consistency with Guile's conventions. Here's a revised analysis based on this: 1. *Consistency with Guile*: Introducing define-method* aligns GOOPS with Guile's existing patterns, making it feel more integrated into the Guile ecosystem. Users familiar with Guile would likely expect an extended form with a * suffix for enhanced functionality. 2. *Avoiding Overloading Semantics*: Extending define-method could make its behavior more complex and potentially harder to understand for users who only need the basic functionality. Having a separate define-method* clearly distinguishes the advanced features, keeping both forms conceptually simpler. 3. *Backward Compatibility and Clarity*: A new form eliminates any chance of subtle incompatibilities or ambiguities arising from extending define-method. For example, users writing macros or tooling around define-method won't need to account for new syntax or semantics. 4. *Gradual Adoption*: With define-method*, users can adopt the new functionality incrementally. This reduces friction for existing users who may not need or want the added complexity of optional, keyword, and rest arguments. Given Guile's * convention, introducing define-method* appears to be the better option. It respects established practices, avoids over-complicating existing forms, and provides a clear upgrade path. My confidence in this recommendation is 90%, given that the Guile precedent is a strong argument for following suit. 4o On Fri, Nov 22, 2024 at 1:29 PM Mikael Djurfeldt <mik...@djurfeldt.com> wrote: > Thanks! > > See responses to Tomas. > > On Fri, Nov 22, 2024 at 1:20 PM <jann...@gnu.org> wrote: > >> Mikael Djurfeldt writes: >> >> Hello, >> >> > That was elegant. :-) >> >> :) >> >> > Nope---haven't seen it. (Or, at least I do not remember it.) >> > >> > Maybe I should have a look at what the optimizer can do about Mark's >> > code. (As you might have seen, my code is a modification of the method >> > syntax implementation itself.) >> >> Yes, I didn't quite get if this brings something else too, except for >> the obvious >> >> > Any opinions on what is best: Having a define-method* or having the >> > functionality in define-method itself? >> >> ...which I think in your version, not having to use define-method* >> feels more elegant/GOOPSy to me, as it's all overloads/generics, >> but I have no strong opionion on this. Thanks for working on this! >> >> Greetings, >> Janneke >> >> -- >> Janneke Nieuwenhuizen <jann...@gnu.org> | GNU LilyPond >> https://LilyPond.org >> Freelance IT https://www.JoyOfSource.com | Avatar® >> https://AvatarAcademy.com >> >
