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 16:13:49 +0200 Message-ID: <87k11nzvc2.fsf@bernoul.li> References: <87a72lhf3b.wl-all_but_last@163.com> <878si5gmt7.wl-all_but_last@163.com> <877dxoh1m6.wl-all_but_last@163.com> <874kssgzrf.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="55433"; 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 16:16:45 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 1jWhKP-000ELv-5T for ged-emacs-devel@m.gmane-mx.org; Thu, 07 May 2020 16:16:45 +0200 Original-Received: from localhost ([::1]:41860 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jWhKN-0007gA-Vw for ged-emacs-devel@m.gmane-mx.org; Thu, 07 May 2020 10:16:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39942) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jWhHe-000720-Rp for emacs-devel@gnu.org; Thu, 07 May 2020 10:13:54 -0400 Original-Received: from mail.hostpark.net ([212.243.197.30]:54344) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jWhHd-0001Zy-JV for emacs-devel@gnu.org; Thu, 07 May 2020 10:13:54 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id 7A869167CD; Thu, 7 May 2020 16:13:50 +0200 (CEST) X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net Original-Received: from mail.hostpark.net ([127.0.0.1]) by localhost (mail1.hostpark.net [127.0.0.1]) (amavisd-new, port 10124) with ESMTP id TnVEiEs7mg4n; Thu, 7 May 2020 16:13:50 +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 ED6E9165C3; Thu, 7 May 2020 16:13:49 +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:249176 Archived-At: I had not seen this reply of yours before I wrote my reply to an earlier message a few minutes ago. >> In this defclass definition. slots prefixed with "closql-" was reserved for >> internal usage. and other slots present the columns in SQL database. > >> Obviously, accessing a slot in these definitions is valid. For example, >> accessing slot "foobar" in that object will trigger real slot-missing method >> because our definitions don't contain it. And accessing slots will trigger a >> sync operation between Emacs VM and SQL database. > > [ By "VM" I assume you mean just the Emacs process, right? ] > > Can you point me to where/how/when the "sync" operation is done > (e.g. how does Emacs know when the SQL database is modified? Is the > whole database mirrored during the sync or only a whole column or only > a specific element of a specific column or something else?). For read operations there might be no sync at all. When setting the value of a slot, then only that gets synced to the database. There is no guarantee that the database has not changed. This can be an issue and one should either avoid writes or be careful about it. In the case of the Emacsmirror's database, e.g. the of `epkg-package' objects, this isn't much of a problem because only I am supposed to write to that database. Users of `epkg' ("browse the Emacsmirror package database") and `borg' ("assimilate Emacs packages as Git submodules") are not supposed to modify the database (or the objects). I have started using `closql' for `forge' ("Access Git forges from Magit") as well, and here it is not without problems each user has their own database which they obviously have to write too. `closql' is definitely not a silver bullet. It works nicely for what I designed it for. It works well enough for me, its author, in another context, but I have no idea how well it would work for others for tasks I did not consider. >> When we put the sync logic in slot-missing. How to distinguish really >> missing slots and "simulated slots" is a problem. > > The way I'd imagine it is that you'd have 2 objects, one that's a sort > of cache of the DB which could have slots like those listed in the `(defclass > epkg-package` of epkg.el, and another on top (or in front of it) which > is the one that's exposed to the rest of the code and this one only has > closql-internal slots, so `slot-missing` is always triggered for > simulated slots (and it can either answer by looking up > the slot value in the cache object, or fetch the answer from the > database and maybe store the result in the cache object). That sounds too complicated for my use-cases at least, and I don't see what we gain by doing that except not having to advice `eieio-oref' and `eieio-oset', which by the way I don't think is all that horrible. Sure, instead of (defun eieio-oset--closql-oset (fn obj slot value) (if (closql-object--eieio-childp obj) (closql-oset obj slot value) (funcall fn obj slot value))) (advice-add 'eieio-oset :around #'eieio-oset--closql-oset) (defun closql-oset (obj slot value) ...) I would have liked to write (cl-defmethod eieio-oset ((obj closql-object) slot value) ...) which, by the way is what I suggest we make possible. I haven't gotten around to ask for the latter so far because as long as `closql' supports older Emacs releases it would have to keep doing something like the former for their benefit anyway.