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: master 1e3b0f2: Improve doc strings of project.el Date: Sat, 18 Jul 2020 13:10:24 +0300 Message-ID: <835zali167.fsf@gnu.org> References: <5d59dd9b-0848-691a-615e-c16d2070b92d@yandex.ru> <837dv8oida.fsf@gnu.org> <834kqcoghk.fsf@gnu.org> <99bb8976-580a-ef8e-6b7d-130c3ca5cb8a@yandex.ru> <83y2nom3hy.fsf@gnu.org> <20200713075842.GA4332@tuxteam.de> <21b47cbb-d1aa-d875-2944-deebb7583961@yandex.ru> <20200717152702.GA18658@tuxteam.de> <922bca06-3425-6fa3-b184-89942c75e91d@yandex.ru> <20200718090546.GC30436@tuxteam.de> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23872"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, dgutov@yandex.ru To: tomas@tuxteam.de Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jul 18 12:11:18 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 1jwjoM-00069i-CJ for ged-emacs-devel@m.gmane-mx.org; Sat, 18 Jul 2020 12:11:18 +0200 Original-Received: from localhost ([::1]:52694 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jwjoL-0004Sf-EK for ged-emacs-devel@m.gmane-mx.org; Sat, 18 Jul 2020 06:11:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57274) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jwjnh-000401-RX for emacs-devel@gnu.org; Sat, 18 Jul 2020 06:10:37 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:48871) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jwjng-0005C7-Pw; Sat, 18 Jul 2020 06:10:36 -0400 Original-Received: from [176.228.60.248] (port=2456 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jwjnf-0004Zm-Q1; Sat, 18 Jul 2020 06:10:36 -0400 In-Reply-To: <20200718090546.GC30436@tuxteam.de> (tomas@tuxteam.de) 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:253069 Archived-At: > Date: Sat, 18 Jul 2020 11:05:46 +0200 > From: tomas@tuxteam.de > Cc: emacs-devel@gnu.org > > > I could be wrong in some details here, but a file descriptor seems > > like a prime example of an abstraction. > > Well, that's at the Mother of Abstraction, aka the user space/kernel > space barrier :-) IMO, there's nothing opaque about a file descriptor. It is just a number. The abstraction here isn't in the descriptor itself, it's in what it _represents_. The descriptor is actually a _handle_ for an object that itself is not exposed at all; you can only manipulate it via the handle. > Yes, this is some kind of OO. But it leaks a couple of things: > first, it's a "small number" (i.e. not some random 64 bit > address, but the pattern of counting up from zero and of building > bitmaps of FDs is considered --mostly-- viable), i.e. the mental > model around is that the kernel "has" a table somewhere indexed > by FD. This detail wasn't probably intended to leak in the first > place, but was just "the obvious thing to do" in a world in which > machines with a 32 bit address space were considered serious iron. That detail is not a general trait of a handle. Another popular example of a handle is a FILE pointer in C, where the details of the object it points to are generally not public. Here, the numerical value of the handle is no longer small. Yet another similar abstraction, much more close to our domain, is the Lisp_Object representation on the C level: with a couple of exceptions, each object is actually a handle of a C struct; once again, the value is not necessarily small, especially if the object tags use the MSBs. Sometimes, very rarely, these handles are even exposed to Lisp; one example is file-notify--add-watch-* functions. So I think the handle notion and the related design patterns are only tangentially relevant to the issue at hand. P.S. The interpretation of a file descriptor as an index into some small table doesn't hold in modern OSes anyway. It was true for MS-DOS, but modern OSes have moved away of that. P.P.S. And no, not everything in C is a number, unless one also holds that "everything in computing is a number".