From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Jonas Bernoulli Newsgroups: gmane.emacs.devel Subject: Re: Slot accessing issues in EIEIO Date: Thu, 07 May 2020 15:44:45 +0200 Message-ID: <87mu6jzwoi.fsf@bernoul.li> References: <87a72lhf3b.wl-all_but_last@163.com> <878si5gmt7.wl-all_but_last@163.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="67257"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Stefan Monnier , Zhu Zihao Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu May 07 15:51:26 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 1jWgvu-000HRP-7x for ged-emacs-devel@m.gmane-mx.org; Thu, 07 May 2020 15:51:26 +0200 Original-Received: from localhost ([::1]:39910 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jWgvt-0006kt-4V for ged-emacs-devel@m.gmane-mx.org; Thu, 07 May 2020 09:51:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33936) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jWgpa-0006ND-24 for emacs-devel@gnu.org; Thu, 07 May 2020 09:44:54 -0400 Original-Received: from mail.hostpark.net ([212.243.197.30]:51890) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jWgpY-0007sN-O1 for emacs-devel@gnu.org; Thu, 07 May 2020 09:44:53 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id 07F0B165F1; Thu, 7 May 2020 15:44:46 +0200 (CEST) X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net Original-Received: from mail.hostpark.net ([127.0.0.1]) by localhost (mail0.hostpark.net [127.0.0.1]) (amavisd-new, port 10124) with ESMTP id PYr52aRIDpFI; Thu, 7 May 2020 15:44:45 +0200 (CEST) Original-Received: from customer (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.hostpark.net (Postfix) with ESMTPSA id 770E5164B2; Thu, 7 May 2020 15:44:45 +0200 (CEST) In-Reply-To: Received-SPF: none client-ip=212.243.197.30; envelope-from=jonas@bernoul.li; helo=mail.hostpark.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/07 09:44:46 X-ACL-Warn: Detected OS = ??? X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001 autolearn=_AUTOLEARN X-Spam_action: no action 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:249173 Archived-At: >> OK, a closql-object (This is a class defined in closql) is a proxy >> object to a row in SQL database. So each time user tries to read a >> slot, closql must sync values between database and Emacs first. Not every time; only when the slot is still unbound. > OK, I'm starting to see vaguely what this is about, but it's still > rather fuzzy. I'll give it a try... Every object slot represents a table column. There is one additional column at the front of each row, which holds a representation of the object's class. Class allocated slots on the other hand are not stored in the database. Two types of object slots exist (or three depending on how you count): 1. Direct slots whose value is stored directly in the row. 2. Indirect slots whose value is a secondary key identifying a row in another table. For example an object that represents an Emacs package has a `name' slot, which is sufficiently represented by a direct slot. But the list of provided features is stored using an indirect slot. We might want to SELECT the package that provides a certain feature using SQL instead of creating a list of every package (which is expensive) and then finding the desired package using, for example `cl-find-if'. The elements in the other table, which is accessed indirectly, may be objects themselves or they may be simple lists. Once an indirect slot has been accessed its value is cached in the object, so future uses don't require database queries. > To better understand, I suggest that I'll throw some solutions so you > can shoot them down explaining why they're not applicable. > > Would it work to use the `slot-missing` generic function? I think the above addresses that. But I guess the questions becomes "Well, what about `slot-unbound' then?". For `eieio-oref' that *might* work but not for `eieio-oset'. The user may wish to change the value of any object slot; it doesn't matter whether it is direct or indirect and in the latter case whether the slot is still unbound or has already been resolved.