Hi Mikael,
> I just pushed this to Savannah.
Excellent!
Thanks for having worked on this.
David
pgpKtaWCv3Jdi.pgp
Description: OpenPGP digital signature
I just pushed this to Savannah.
On Mon, Nov 25, 2024 at 11:28 AM Mikael Djurfeldt
wrote:
> This is the third attempt at introducing keyword aware methods in GOOPS.
>
> What is new in v3 is that keyword arguments and default parameters to
> keyword arguments are handled correctly when using (next
Hi Mikael,
> Guile maintainers might want to consider if we should time this kind
> of change in the API with a particular release. For my part, I think
> we could just add it.
1+
imo as well, there is no need to wait for a particular release [*]
David
[*] especially since you said in another e
Ah... I forgot to complete parse-keyword-formals, which is currently only
rudimentary and doesn't compose the correct argument list for (next-method).
There will be a version 3...
On Sun, Nov 24, 2024 at 3:43 PM Mikael Djurfeldt
wrote:
> Guile maintainers might want to consider if we should tim
Guile maintainers might want to consider if we should time this kind of
change in the API with a particular release. For my part, I think we could
just add it.
On Sun, Nov 24, 2024 at 3:40 PM Mikael Djurfeldt
wrote:
> This is my second attempt at introducing keyword aware methods in GOOPS.
>
> I
(It's (define-method (f #:key foo) ...).)
This is a valid point. Certainly there should be unambiguous rules so that
we know which method should be selected. (I planned to examine this aspect
before applying my patch to Guile. I was just eager to share what I had
done in order to collect opinions
>Well, these particular examples aren't valid since GOOPS doesn't allow type
>specifiers for keyword arguments. (It's the same in CLOS.) Type dispatch is
>done *only* on the required arguments.
That’s a shame, it should support them IMO, it’s a major limitation if it
doesn’t.
A variant with un
Hi Maxime,
Well, these particular examples aren't valid since GOOPS doesn't allow type
specifiers for keyword arguments. (It's the same in CLOS.) Type dispatch is
done *only* on the required arguments.
Best regards,
Mikael
On Sat, Nov 23, 2024 at 4:31 PM Maxime Devos wrote:
> >Any opinions on
>Any opinions on what is best: Having a define-method* or having the
>functionality in define-method itself?
You can’t unify define-method with define-method* without making some arbitrary
choices in some special cases (the same applies to define-method* too actually,
and also to define-method
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-metho
Thanks!
See responses to Tomas.
On Fri, Nov 22, 2024 at 1:20 PM 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
> > cod
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.
>
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 its
Hello,
opinion from the peanut gallery below.
Mikael Djurfeldt writes:
> Any opinions on what is best: Having a define-method* or having the
> functionality in define-method itself?
I do find the symmetry between define-method/define-method* and
define/define* pleasing.
For define and define*
Hi Janneke,
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.)
Any opinions on what is best:
Mikael Djurfeldt writes:
Hi Mikael,
> Since there are no comments, I'm inclined to apply this patch. I will do
> that on Sunday if there are no comments before that.
Just FYI, have you seen the attached patch by Mark Weaver? I've been
carrying that for some time now, functionality like this is
(I will of course add proper documentation in the manual, etc.)
On Thu, Nov 21, 2024 at 9:33 PM Mikael Djurfeldt
wrote:
> Since there are no comments, I'm inclined to apply this patch. I will do
> that on Sunday if there are no comments before that.
>
> Maybe I should first give a motivating exa
Since there are no comments, I'm inclined to apply this patch. I will do
that on Sunday if there are no comments before that.
Maybe I should first give a motivating example: guile-mqtt consists of a
thin wrapper over NYACC-generated code. There, I use a coding pattern that
I tend to use in cases w
18 matches
Mail list logo
