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 <mikael@djurfeldt.com>
wrote:

> Thanks!
>
> See responses to Tomas.
>
> On Fri, Nov 22, 2024 at 1:20 PM <janneke@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 <janneke@gnu.org>  | GNU LilyPond
>> https://LilyPond.org
>> Freelance IT https://www.JoyOfSource.com | Avatar®
>> https://AvatarAcademy.com
>>
>