From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Opaque objects and Emacs documentation Date: Tue, 21 Jul 2020 22:33:04 +0300 Message-ID: <83wo2wfytr.fsf@gnu.org> References: <20200712184908.13140.5739@vcs0.savannah.gnu.org> <20200712184909.BBC61209B1@vcs0.savannah.gnu.org> <7bf4d6ef-c0ec-43dc-ad5d-f6e81422ad90@yandex.ru> <83zh84m5ws.fsf@gnu.org> <3dd1c224-69b2-40af-5b2e-43a310253632@yandex.ru> <83tuybmtxs.fsf@gnu.org> <859f594b-1343-6d26-e1ac-7157c44eb56c@yandex.ru> <83a6zyk4tt.fsf@gnu.org> <6edffb7d-7708-534f-93ad-bf9180f5e0ed@yandex.ru> <835zamjsvk.fsf@gnu.org> <831rlajock.fsf@gnu.org> <1fcdc463-b3ab-2d32-31d7-904783ae0d81@yandex.ru> <83y2nii6sk.fsf@gnu.org> <69716ecb-8984-23e0-8b44-322ea3582384@yandex.ru> <837duxgcmw.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20093"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rms@gnu.org, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jul 21 21:33:56 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jxy1R-00054T-No for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Jul 2020 21:33:53 +0200 Original-Received: from localhost ([::1]:55038 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jxy1Q-00089p-Ol for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Jul 2020 15:33:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57532) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jxy0x-0007kB-HT for emacs-devel@gnu.org; Tue, 21 Jul 2020 15:33:23 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35059) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jxy0w-0008FF-Be; Tue, 21 Jul 2020 15:33:22 -0400 Original-Received: from [176.228.60.248] (port=1938 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jxy0i-0003Ck-BV; Tue, 21 Jul 2020 15:33:10 -0400 In-Reply-To: (message from Dmitry Gutov on Tue, 21 Jul 2020 21:56:11 +0300) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:253138 Archived-At: > Cc: rms@gnu.org, emacs-devel@gnu.org > From: Dmitry Gutov > Date: Tue, 21 Jul 2020 21:56:11 +0300 > > On 21.07.2020 17:34, Eli Zaretskii wrote: > > So the type returned by each hook could > > be documented in the doc string of that hook in terms suggested by > > Richard (or something similar). > > It could. It would not be a significant problem. > > > Similarly, the "transient" project instance returned by > > project-current itself, when a project doesn't yet exist, is also > > known, and its structure could be similarly documented without > > impediment to extensibility. > > If you say that, could you give an example of something that *would* be > an impediment to extensibility? What you said: describing what generics returns, or what project-current returns in general. > > Whether the structure is obvious from the implementation may or may > > not be true (and the author of the code is usually not the best judge > > of that), but doesn't solve the issue at hand, IMO. > > So have we moved on from trying to document the examples in the > docstrings of project-find-functions or project-current? If those are the rules of the game, yes. IOW, if it's not okay to describe the possible forms of the object in the doc string of project-find-functions, but okay to describe them in the individual doc strings of each hook that can be put there, then it could be an acceptable compromise, at least from my POV. > > A good > > documentation of an interface should allow a developer to write code > > that uses the interface without looking at the interface's > > implementation. > > Right. But there won't be any third-party callers of project-try-vc, > this function's only purpose is to be inside project-find-functions. I'm thinking about additional "authors" who'd like to add functionality to existing project backends. > So as things currently stand, the responsibility for it being correct > and accepting the right argument lies on its author, and not on any > third-party developers. Yes, but "its author" doesn't have to be a single person, and doesn't have to be the same person who wrote the initial implementations. > > If it is necessary to consult the implementation, > > that is an indication of some deficiency in the docs, and we should > > try to avoid that as much as possible. > > No disagreement there, as long as we're talking about public functions. Are we still under the rule that any function without 2 dashes in its name is public? If so, then I think we have only discussed public functions in this and related threads.