From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.help Subject: EIEIO: A question about interfaces Date: Thu, 14 Jan 2021 16:21:21 +0100 Message-ID: <877dofee8e.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27371"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) To: Emacs mailing list Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jan 14 16:26:50 2021 Return-path: Envelope-to: geh-help-gnu-emacs@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 1l04WP-0006zL-SR for geh-help-gnu-emacs@m.gmane-mx.org; Thu, 14 Jan 2021 16:26:49 +0100 Original-Received: from localhost ([::1]:53524 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l04WO-00063Q-UZ for geh-help-gnu-emacs@m.gmane-mx.org; Thu, 14 Jan 2021 10:26:48 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50492) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l04RG-0001OX-JQ for help-gnu-emacs@gnu.org; Thu, 14 Jan 2021 10:21:30 -0500 Original-Received: from mout.web.de ([212.227.17.12]:37779) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l04RA-0000TE-U8 for help-gnu-emacs@gnu.org; Thu, 14 Jan 2021 10:21:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1610637683; bh=wb43lPtlsFlhisGHbjOlY8EqU0Yv5nN8oyU6A6z35mM=; h=X-UI-Sender-Class:From:To:Subject:Date; b=sXt6YPgAE//WSVgx8hYDE/vY8LKhrUUT1oHaOCrWAumET4QmSMGZyUYlHW0OSYuKl ZVoTVDHVVQZE9YJYjLmmrTwylFKpT8YtbZrzTod5mMsefNCp6Xn17maAAz2BnuFN+1 wRt4/hNiUCz/O9aj3RXA6GQ5joFPt/C//eF15p0I= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Original-Received: from drachen.dragon ([88.67.99.46]) by smtp.web.de (mrweb102 [213.165.67.124]) with ESMTPSA (Nemesis) id 0LtWsC-1m0nzi3Pdc-010x47; Thu, 14 Jan 2021 16:21:22 +0100 X-Provags-ID: V03:K1:l5y7st74+N49Rdj64fgDCzVCMicz40UH6uzywAVRoNSvs1RRbMd A5Mr3IW3nBtpWJ0HZ+JZoskv8753tCNFd+6L0IWkj8//ZXiVkR/Yg1R0jckiVmNMZaIX9/a qvxIrl3KwpKFxM93cCCF3m20T1QITynZZ0MJGZSsGLoudBYPBxYJ+avxcPoNC0hH6/JNLmW wQ3J1TtJ5x39ErKGN9kyQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:odH017WruQo=:BQjoXKWV8HVhUE8jjWdANc zzAfyEJrQH2c6TbJlFVjS22McxSdxc3M77VPOFDxNpoTedUmDaBRMkTORt6rZyZMw9HWoepPw 0kjY2U1GPb84dDTEdFnVwlycpawZU+uv0ZfAbZFR4+1DnqQDaJox90FLFIft6ZnVFFKXHUByn ji6Itr2k1rkFH3F/DCEU4MXryR2tnr8NobxzwDmCY5TFLu9zC26gG6GEClITA+lVE1TcFkMT6 +6ubFRHylPaQ1YpsNhNl8kf9/xzAhfrK9s8oKlVOgL72DKcbrEA/oAsL23Eu6oidAKp8l9Bv/ q6UOQwuOBoStfpuwqQKx8dF4ux7WAmfpCPXUuuC+d/ePWQrOwCp8w0fE6NEijhXG90vs2o3rp VT2zKe9ufy7nfCBNVv4xO0lnq0KG3btRXVVoCsmrY4l6kMtgSSk/q0dctj7pVpofe7bzARRnj gfbhwJ2ngRYgG+f7wyNq6Wf5K57snZSbJq0TmimBCOTGe4wBtrEl4zHZdmplJmKv7CiDJ5ypc NkLKMGDDVpN98VWAzda6tDfbCORGK6yTg21kvMqXD9yaX4xwU681aVOpgT+b0PMwjsMVoapJ8 Hea4ERYdJx+BdNm8wEUmD2Qt3BtkV31O3CvDfwaJsV2FHfcsWpWCIntK5u9qqByooYDZZ8k4z HcM7AgpIaLybZnxNRmgpy4jCa9keV467alq602hXiCJGA8x/JpBIMaOrXOyM+bc/oED6bxTMI JDbsZ+Fet+b4JAweco+WGqImdJhszkiLThmalDdM9TAZiCoVVVw5LC/uWf6SgG2lybFSzbjj Received-SPF: pass client-ip=212.227.17.12; envelope-from=michael_heerdegen@web.de; helo=mout.web.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:127240 Archived-At: Hello, (One thing in advance: I'm still not really that familiar with using EIEIO stuff in real code.) My question: Say (general case) I have a given hierarchy of (EIEIO) classes, and a set of methods implementing diverse generics for objects of some of these classes. Now I want to allow that some objects of some of these classes have/ support an additional feature. Some of the methods might need be slightly tuned for objects having this feature, e.g. by defining according :around methods. My question: how would I code that concretely? When I define an interface class, would I need to define a parallel version of the given hierarchy of classes inheriting from the interface? Can I avoid that? Because, a thing "typically" only belongs to one class. If I don't want to mess around with `cl-generic-define-generalizer', the existing specializers don't seem to allow to test whether a given object fulfills a given arbitrary predicate (AFAIU &context allows to specify arbitrary tests but seems there is no way to refer to the tested object from within this test). Too vague? Here is some code I played with: #+begin_src emacs-lisp (defclass my-1 () ((contents :initarg :contents))) (cl-defgeneric my-test (obj)) (cl-defmethod my-test ((obj my-1)) (format "Contents: %S" (oref obj contents))) ;; (defclass my-foo-interface () ((additional :initarg :additional))) (defclass my-1-foo (my-foo-interface my-1) ()) (cl-defmethod my-test ((obj my-foo-interface)) (concat (format "Additional: %S\n" (oref obj additional)) (cl-call-next-method))) ;; Test: (my-test (my-1-foo :contents 'x :additional 17)) #+end_src That "works" so far, but with that strategy I would have to define one extra class per given class from the hierarchy to be even able to create objects of the according kind. To avoid that I could replace the interface class with a wrapper class that has a field that can contain any instance of any class of the given hierarchy. But then the methods implementing generics for the class hierarchy would not recognize this new kind of objects. I would need to implement each of these methods for the wrapper class individually. Trivial but creating redundancy and maintenance burden. And: other existing code explicitly testing for the type of object could fail to recognize the altered classes as well, code I might not be able to extent as easily as by adding (wrapper) method implementations. Any hints of how to do this more intelligently? TIA, Michael.