From: Dmitry Gutov <dgutov@yandex.ru>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: master 0339325: ; * lisp/progmodes/project.el (project-current): Doc fix.
Date: Fri, 17 Jul 2020 01:40:59 +0300 [thread overview]
Message-ID: <859f594b-1343-6d26-e1ac-7157c44eb56c@yandex.ru> (raw)
In-Reply-To: <83tuybmtxs.fsf@gnu.org>
I'll try to keep this short.
On 13.07.2020 16:21, Eli Zaretskii wrote:
> Btw, your implementation style makes it unusually hard to write good
> doc strings. I'm not quite sure why, but one possible reason is that
> IMO you bring the generics too high, too close to the application
> level, where doc strings should be more and more user-oriented.
The recent packages where you see this problem (and I agree that it's
not ideal) are those which offer the possibility to customize complex
behaviors. To an unprecedented degree, if we compare to older Emacs
features.
Before xref and project.el, I think the closest one was minibuffer.el
with its "completion tables" which can are often represented by
anonymous functions. Which is another type of an opaque value.
Both xref and project.el could have used functions this way as well (a
version doing that was initially proposed for xref). But any impression
that such values would be easier to understand is illusory.
> When
> this is coupled with your reluctance, to say the least, to disclose
> details of what you consider to be opaque objects, it becomes hard to
> say anything useful about many functions, because describing what
> functions do usually involves talking about their inputs and outputs,
> and how the former are processed into the latter.
We're using cl-generic as an implementation technique. It's a more
general implementation of dynamic dispatch, more commonly known to a lot
of programmers from OOP.
> The "for example"
> method that I tried to use was about the only technique I could think
> of to overcome those difficulties, and you reject even that.
If we use the OOP analogy, you are trying to describe "object instances"
in full detail, beyond the public interface, together with their
"private fields", so to speak. It's a definite anti-pattern in OO community.
> Whether one agrees with your coding style or not, the difficulties it
> presents to documenting our code are real, and I suggest that you
> consider this disadvantage seriously, because it basically flies in
> the face of long-standing traditions of Emacs self-documenting
> features.
We could discuss alternative implementation approaches, but I think you
will find none will fit the basic requirements of these packages.
Or at least that the possible options will require the client to treat
the values as "opaque" exactly the same way.
next prev parent reply other threads:[~2020-07-16 22:40 UTC|newest]
Thread overview: 103+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200712184908.13140.5739@vcs0.savannah.gnu.org>
[not found] ` <20200712184909.BBC61209B1@vcs0.savannah.gnu.org>
2020-07-12 20:07 ` master 0339325: ; * lisp/progmodes/project.el (project-current): Doc fix Dmitry Gutov
2020-07-13 3:48 ` Eli Zaretskii
2020-07-13 11:09 ` Dmitry Gutov
2020-07-13 13:21 ` Eli Zaretskii
2020-07-13 14:14 ` Dmitry Gutov
2020-07-16 22:40 ` Dmitry Gutov [this message]
2020-07-17 6:56 ` Opaque objects and Emacs documentation Eli Zaretskii
2020-07-17 8:13 ` tomas
2020-07-17 10:40 ` Dmitry Gutov
2020-07-17 15:38 ` tomas
2020-07-17 10:37 ` Basil L. Contovounesios
2020-07-17 10:46 ` Dmitry Gutov
2020-07-17 10:53 ` Basil L. Contovounesios
2020-07-17 10:53 ` Dmitry Gutov
2020-07-17 11:14 ` Eli Zaretskii
2020-07-17 12:02 ` Noam Postavsky
2020-07-17 12:52 ` Eli Zaretskii
2020-07-17 13:09 ` Dmitry Gutov
2020-07-17 13:56 ` Eli Zaretskii
2020-07-17 14:35 ` Dmitry Gutov
2020-07-17 14:59 ` Eli Zaretskii
2020-07-17 15:03 ` Dmitry Gutov
2020-07-18 1:54 ` Richard Stallman
2020-07-18 19:17 ` Dmitry Gutov
2020-07-19 2:27 ` Richard Stallman
2020-07-19 14:48 ` Eli Zaretskii
2020-07-21 19:00 ` Dmitry Gutov
2020-07-21 19:36 ` Eli Zaretskii
2020-07-21 20:56 ` Dmitry Gutov
2020-07-21 21:06 ` Tomas Hlavaty
2020-07-21 20:49 ` Tomas Hlavaty
2020-07-21 20:59 ` Dmitry Gutov
2020-07-21 21:20 ` Tomas Hlavaty
2020-07-21 21:25 ` Dmitry Gutov
2020-07-21 19:08 ` Dmitry Gutov
2020-07-21 19:38 ` Eli Zaretskii
2020-07-21 21:02 ` Dmitry Gutov
2020-07-21 20:29 ` John Yates
2020-07-22 0:45 ` Dmitry Gutov
2020-07-22 14:08 ` Eli Zaretskii
2020-07-19 22:02 ` Dmitry Gutov
2020-07-20 2:44 ` Richard Stallman
2020-07-21 1:09 ` Dmitry Gutov
2020-07-21 8:57 ` tomas
2020-07-21 10:14 ` Dmitry Gutov
2020-07-21 10:29 ` tomas
2020-07-21 14:34 ` Eli Zaretskii
2020-07-21 18:56 ` Dmitry Gutov
2020-07-21 19:33 ` Eli Zaretskii
2020-07-21 21:31 ` Dmitry Gutov
2020-07-22 14:28 ` Eli Zaretskii
2020-07-22 15:44 ` Dmitry Gutov
2020-07-22 16:30 ` Eli Zaretskii
2020-07-22 16:37 ` Dmitry Gutov
2020-07-21 19:36 ` Alan Mackenzie
2020-07-21 21:17 ` Dmitry Gutov
2020-07-21 22:12 ` Edebug (was: Opaque objects and Emacs documentation) Stefan Monnier
2020-07-22 14:31 ` Opaque objects and Emacs documentation Eli Zaretskii
2020-07-22 15:33 ` Dmitry Gutov
2020-07-22 16:22 ` Eli Zaretskii
2020-07-22 16:26 ` Dmitry Gutov
2020-07-23 4:04 ` Richard Stallman
2020-07-23 13:42 ` Dmitry Gutov
2020-07-22 11:43 ` João Távora
2020-07-17 13:08 ` Dmitry Gutov
2020-07-17 13:42 ` Dmitry Gutov
2020-07-17 14:22 ` Eli Zaretskii
2020-07-17 14:56 ` Dmitry Gutov
2020-07-17 16:56 ` John Yates
2020-07-17 17:13 ` Drew Adams
2020-07-17 19:04 ` Eli Zaretskii
2020-07-17 19:26 ` Dmitry Gutov
2020-07-17 19:25 ` Dmitry Gutov
2020-07-17 11:53 ` Gregory Heytings via Emacs development discussions.
2020-07-17 13:13 ` Dmitry Gutov
2020-07-17 14:26 ` Gregory Heytings via Emacs development discussions.
2020-07-17 16:58 ` Drew Adams
2020-07-17 19:22 ` Dmitry Gutov
2020-07-17 22:30 ` Gregory Heytings via Emacs development discussions.
2020-07-18 0:00 ` Yuan Fu
2020-07-18 1:01 ` Drew Adams
2020-07-18 1:55 ` Richard Stallman
2020-07-17 16:48 ` Stefan Monnier
2020-07-23 23:24 ` Andy Moreton
2020-07-23 23:40 ` Andy Moreton
2020-07-24 5:32 ` Eli Zaretskii
2020-07-24 11:23 ` Andy Moreton
2020-07-24 11:43 ` Eli Zaretskii
2020-07-24 0:43 ` Dmitry Gutov
2020-07-24 1:22 ` Andy Moreton
2020-07-24 5:47 ` Eli Zaretskii
2020-07-25 16:33 ` Andy Moreton
2020-07-25 16:51 ` Eli Zaretskii
2020-07-25 20:18 ` Andy Moreton
2020-07-26 2:27 ` Eli Zaretskii
2020-07-26 9:16 ` Andy Moreton
2020-07-26 14:02 ` Eli Zaretskii
2020-07-24 20:49 ` Dmitry Gutov
2020-07-25 16:38 ` Andy Moreton
2020-07-24 5:45 ` Eli Zaretskii
2020-07-24 14:56 ` Dmitry Gutov
2020-07-24 17:21 ` Drew Adams
2020-07-24 17:42 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=859f594b-1343-6d26-e1ac-7157c44eb56c@yandex.ru \
--to=dgutov@yandex.ru \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).