From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Antipov Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109327: Generalize INTERNAL_FIELD between buffers, keyboards and frames. Date: Sun, 05 Aug 2012 18:59:10 +0400 Message-ID: <501E8A3E.1090708@yandex.ru> References: <50191B54.2070705@yandex.ru> <5019FE2D.2060005@yandex.ru> <501B8C48.3000704@yandex.ru> <501C1F4D.5010007@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1344178622 9621 80.91.229.3 (5 Aug 2012 14:57:02 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 5 Aug 2012 14:57:02 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 05 16:57:03 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Sy2GM-000690-CU for ged-emacs-devel@m.gmane.org; Sun, 05 Aug 2012 16:57:02 +0200 Original-Received: from localhost ([::1]:59761 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sy2GL-0002D1-O9 for ged-emacs-devel@m.gmane.org; Sun, 05 Aug 2012 10:57:01 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:56249) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sy2GI-0002Cd-Ph for emacs-devel@gnu.org; Sun, 05 Aug 2012 10:56:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sy2GG-0006vV-CZ for emacs-devel@gnu.org; Sun, 05 Aug 2012 10:56:58 -0400 Original-Received: from forward4h.mail.yandex.net ([84.201.186.22]:52056) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sy2GG-0006vG-0C for emacs-devel@gnu.org; Sun, 05 Aug 2012 10:56:56 -0400 Original-Received: from smtp1h.mail.yandex.net (smtp1h.mail.yandex.net [84.201.187.144]) by forward4h.mail.yandex.net (Yandex) with ESMTP id 39ECF1B213E8; Sun, 5 Aug 2012 18:56:53 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1344178613; bh=Zavsfny9PNgM83FmDD1ZqwfRs8FwLJCijDcx+e23ScM=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=b4RCwXMGfQHzBqZFYP30Vfx5QDNwhXk0MI2mPwIX+2mqHFQnxm+e0WausSgk1fY/w 90DYRmTJEglhwH1dZwEBrgLKXq8SbbUxjND2JoTBESU8AkwRondkStGy/5HZvU1yir SsWggvye0XdgdFd/4RhSRWy3JloJIHuRKzl2V4qA= Original-Received: from smtp1h.mail.yandex.net (localhost [127.0.0.1]) by smtp1h.mail.yandex.net (Yandex) with ESMTP id D7A6A13402CE; Sun, 5 Aug 2012 18:56:52 +0400 (MSK) Original-Received: from unknown (unknown [37.139.84.55]) by smtp1h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id uqw0Dknf-uqw022Fh; Sun, 5 Aug 2012 18:56:52 +0400 X-Yandex-Rcpt-Suid: eggert@cs.ucla.edu X-Yandex-Rcpt-Suid: monnier@IRO.UMontreal.CA X-Yandex-Rcpt-Suid: emacs-devel@gnu.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1344178612; bh=Zavsfny9PNgM83FmDD1ZqwfRs8FwLJCijDcx+e23ScM=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Poz9hSuGsvC+A2fH/ycg8z9y84FweSQj+0IWR7fa1392GYov4pGiajRR0++SuU59h sn+fuSXyRq4oSloSWZZFxvFieeklkaV/4GCHyKPOyX3gETWCarc4buxrlKNYoALliv AZbOmKgzAxjv8SWcOh5a6sEYl4jHGhTnweCvohiw= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120713 Thunderbird/14.0 In-Reply-To: <501C1F4D.5010007@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 84.201.186.22 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:152195 Archived-At: On 08/03/2012 10:58 PM, Paul Eggert wrote: >> why (F|W)VARs are so bad but (B|K)VARs are OK? > > The short answer is they're all bad. :-) > > FVAR is bad partly because it has the syntax of a C function, > but not the semantics; it cannot be implemented as a function. Why this is a problem ever? OK, maybe AREF and ASET are better; but the only way to implement FVARs as functions is to have array of Lisp_Objects in struct frame and meaningful indexes for the particular slots, i.e. enum frame_slots { NAME, ICON_NAME, TITLE ... }; I don't like this, and most probably others will not like it too. > How about if we compromise by switching to functional notation? > That should be easier to read. That is, instead of this: > > return XFRAME (frame)->buffer_list; > > or this: > > return FVAR (XFRAME (frame), buffer_list); > > we write this: > > return frame_buffer_list (XFRAME (frame)); > > Also, instead instead of this: > > f->buffer_list = Fcons (buf, Qnil); > > or this: > > FVAR (f, buffer_list) = Fcons (buf, Qnil); > > we write this: > > set_frame_buffer_list (f, Fcons (buf, Qnil)); IMHO this is just a poor copy of C++ class :-(: if you have a huge class with 50 private members, you're enforced to have 50 get_xxx and 50 set_xxx member functions. Most of them are inline and fast, but, (IMHO again) they do not improve readability and makes sense only if you have a huge class hierarchies where the fine-granted member access control is very important for some another reason. Dmitry