Hi Tomas, Thank you for your feedback. Answers below.
On Fri, Nov 22, 2024 at 12:46 PM Tomas Volf <~@wolfsden.cz> wrote: > I do find the symmetry between define-method/define-method* and > define/define* pleasing. > Yes, I guess we are free to form GOOPS in our own style regardless of CLOS. > For define and define*, one could argue that procedures produced by the > latter are slower to call (I did measure). Is that an issue here as > well? Well, the implementation in my patch essentially does the same amount of work as the old one, and when not using keywords a call is as efficient. Generic function dispatch should be unaffected, as with Marks macro. However, there will be the same kind of overhead as for define* in calls actually using keywords. I checked what the optimizer can do with the resulting method when using Marks elegant macro. Unfortunately, such a method would have overhead. However, I do think that a modified version of Marks macro together with a small change in peval could have a chance not to introduce such overhead. All, in all, it currently (and paradoxically) turns out to be simpler to provide the keyword functionality in define-method rather than also providing define-method* if one doesn't want to introduce overhead for the most common types of methods. Perhaps I could try to learn what is going on in peval and see if a macro similar to Marks would be the most elegant way to go forward. You did mention backwards compatibility, but how serious you expect the > issue would be? I personally did not use GOOPS yet, but I have a hard > time imagining a real-world code that would be broken by this change. > Do you expect there would actually be any? > I said "backwards compatibility perspective" and was too lazy to spell out what I meant, which is this: Assume that we *now* want to write backwards compatible code. Then, if we have *not* modified define-method we can be certain that as long as we use define-method, we will be backwards compatible. However, if we introduce keywords in define-method (rather than define-method*) this is no longer true. If this new functionality is confined to define-method*, then a future code can test for the presence of defined-method* in Guile and otherwise provide something similar to Marks (or Anders Vinjars from April 2003 :-)) macro. > > I personally would probably lean towards two separate procedures (mainly > due to the assumption of there being a performance impact). > Well, there is none now that we have Andys remarkable compiler. Now also Janneke has responded and he prefers to have everything in define-method. Myself, I'm split. I can see merits in both solutions. Least code bloat would probably be to just apply my patch. But I think we should think mostly about style (where I am still split). Best regards, Mikael > > Have a nice day, > Tomas Volf > > -- > There are only two hard things in Computer Science: > cache invalidation, naming things and off-by-one errors. >
