(elisp) Generic Functions cl-defmethod documentation bug?

(elisp) Generic Functions cl-defmethod documentation bug?

[Stephen Leake]

In the elisp manual node Generic Functions, the documentation for
'cl-defmethod' includes:

     ‘STRUCT-TAG’
          The argument must be an instance of a class named STRUCT-TAG
          defined with ‘cl-defstruct’ (*note (cl)Structures::), or of
          one of its parent classes.

Shouldn't 'parent classes' be 'child classes'?

The method requires an object that has all the fields defined in the given
struct; that is true of child classes, not parents.

Unless I'm missing something.

-- 
-- Stephe

Re: (elisp) Generic Functions cl-defmethod documentation bug?

[Stefan Monnier]

>      ‘STRUCT-TAG’
>           The argument must be an instance of a class named STRUCT-TAG
>           defined with ‘cl-defstruct’ (*note (cl)Structures::), or of
>           one of its parent classes.
>
> Shouldn't 'parent classes' be 'child classes'?

That sounds right, indeed.  And instead of "tag" it should say "type"
since this is a type and not a tag.


        Stefan

Re: (elisp) Generic Functions cl-defmethod documentation bug?

[Stephen Leake]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>      ‘STRUCT-TAG’
>>           The argument must be an instance of a class named STRUCT-TAG
>>           defined with ‘cl-defstruct’ (*note (cl)Structures::), or of
>>           one of its parent classes.
>>
>> Shouldn't 'parent classes' be 'child classes'?
>
> That sounds right, indeed.  And instead of "tag" it should say "type"
> since this is a type and not a tag.

Ok, committed in b6add8c7

-- 
-- Stephe

Re: (elisp) Generic Functions cl-defmethod documentation bug?

[Eli Zaretskii]

> From: Stephen Leake <stephen_leake@stephe-leake.org>
> Date: Tue, 02 Jan 2018 07:41:19 -0600
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> >>      ‘STRUCT-TAG’
> >>           The argument must be an instance of a class named STRUCT-TAG
> >>           defined with ‘cl-defstruct’ (*note (cl)Structures::), or of
> >>           one of its parent classes.
> >>
> >> Shouldn't 'parent classes' be 'child classes'?
> >
> > That sounds right, indeed.  And instead of "tag" it should say "type"
> > since this is a type and not a tag.
> 
> Ok, committed in b6add8c7

Thanks, but why to master?  Documentation patches should be pushed to
the release branch.

Re: (elisp) Generic Functions cl-defmethod documentation bug?

[Stephen Leake]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stephen Leake <stephen_leake@stephe-leake.org>
>> Date: Tue, 02 Jan 2018 07:41:19 -0600
>> 
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> 
>> >>      ‘STRUCT-TAG’
>> >>           The argument must be an instance of a class named STRUCT-TAG
>> >>           defined with ‘cl-defstruct’ (*note (cl)Structures::), or of
>> >>           one of its parent classes.
>> >>
>> >> Shouldn't 'parent classes' be 'child classes'?
>> >
>> > That sounds right, indeed.  And instead of "tag" it should say "type"
>> > since this is a type and not a tag.
>> 
>> Ok, committed in b6add8c7
>
> Thanks, but why to master?  Documentation patches should be pushed to
> the release branch.

Sorry, I realized that after I committed.

I found instructions for backporting a commit in
admin/notes/git-workflow:

-------------
cd ~/emacs/emacs-26
git cherry-pick -xe b6add8c7...

and add "Backport:" to the commit string.  

git push
-------------

is that the correct process?

-- 
-- Stephe

Re: (elisp) Generic Functions cl-defmethod documentation bug?

[Eli Zaretskii]

> From: Stephen Leake <stephen_leake@stephe-leake.org>
> Date: Wed, 03 Jan 2018 16:57:29 -0600
> 
> I found instructions for backporting a commit in
> admin/notes/git-workflow:
> 
> -------------
> cd ~/emacs/emacs-26
> git cherry-pick -xe b6add8c7...
> 
> and add "Backport:" to the commit string.  
> 
> git push
> -------------
> 
> is that the correct process?

Yes, thanks.