From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.devel Subject: Re: Inclusion of dbus-proxy Date: Mon, 23 Aug 2010 17:44:06 +0200 Message-ID: References: <4045_1282428217_ZZh07312bUcyR.00_1282428214.23884.594.camel@steed.robot-madness> <87aaoesjor.fsf@gmx.de> <8986_1282511101_ZZh07366e9Yqy.00_1282511096.23884.675.camel@steed.robot-madness> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1282578266 11083 80.91.229.12 (23 Aug 2010 15:44:26 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 23 Aug 2010 15:44:26 +0000 (UTC) Cc: "emacs-devel@gnu.org" To: Jan Moringen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 23 17:44:23 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OnZC7-0001vQ-T8 for ged-emacs-devel@m.gmane.org; Mon, 23 Aug 2010 17:44:20 +0200 Original-Received: from localhost ([127.0.0.1]:53253 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnZC7-0002mo-82 for ged-emacs-devel@m.gmane.org; Mon, 23 Aug 2010 11:44:19 -0400 Original-Received: from [140.186.70.92] (port=33273 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnZC1-0002la-N3 for emacs-devel@gnu.org; Mon, 23 Aug 2010 11:44:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OnZBz-0005aY-UO for emacs-devel@gnu.org; Mon, 23 Aug 2010 11:44:13 -0400 Original-Received: from mailrelay2.alcatel.de ([194.113.59.96]:41886) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OnZBz-0005a8-Gz for emacs-devel@gnu.org; Mon, 23 Aug 2010 11:44:11 -0400 Original-Received: from destgsu0048.de.alcatel-lucent.com (destgsu0048.de.alcatel-lucent.com [149.204.242.4]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id o7NFi7Tb005471; Mon, 23 Aug 2010 17:44:07 +0200 Original-Received: from slbhn1.alcatel.de (slbhn1.de.alcatel-lucent.com [149.204.90.35]) by destgsu0048.de.alcatel-lucent.com (8.12.3/8.12.3) with ESMTP id o7NFi6RZ008354; Mon, 23 Aug 2010 17:44:06 +0200 (MEST) In-Reply-To: <8986_1282511101_ZZh07366e9Yqy.00_1282511096.23884.675.camel@steed.robot-madness> (Jan Moringen's message of "Sun, 22 Aug 2010 23:04:56 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-Alcanet-virus-scanned: o7NFi6RZ008354 at destgsu0048.de.alcatel-lucent.com X-Scanned-By: MIMEDefang 2.64 on 149.204.45.73 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:129091 Archived-At: Jan Moringen writes: > Hi Michael, Hi Jan, >> For people not familiar with eieio (like me) it would be helpful to >> explain what's happening here. > > When called for the first time on a particular D-Bus object, > `dbus-proxy-make-remote-proxy' looks up the set of interfaces > implemented by the object and dynamically creates EIEIO classes for the > D-Bus interfaces. After that, information about D-Bus properties and > signals are stored in the interface classes and EIEIO methods are > created for D-Bus interfaces methods. The generated methods contain > calls to `dbus-call-method' with some argument processing (based on > method signatures, the argument list is augmented with D-Bus type > designators). When the different proxy components are created, names are > transform from D-Bus-typical CamelCamel to something-more-lispy. > > In the example, the following slot value access and function calls just > use the facilities of the proxy object described above to transparently > access D-Bus properties and signals and call D-Bus methods. Note that > the function call syntax for EIEIO methods does not differ from ordinary > function calls. That's more or less how I did understand it. What I recommend is a description for the user, which does not use eieio terminology. It could be a barrier for people not familiar with eieio. >> > + dbus-introspection.el >> >> If such a module exists, dbus-introspection-* functions from dbus.el >> could be moved here. > > Currently this file contains some accessor functions for D-Bus > introspection data and some signature parsing code. I'm not sure how > this would fit together with dbus.el but I do think these should be > merged. In particular dbus-introspection.el does not depend on > dbus-proxy.el. Maybe there is a misunderstanding. If dbus-introspection.el would be a part of core Emacs, I recommend to move existing dbus-introspection-* functions *from* dbus.el *to* dbus-introspection.el. If dbus-introspection.el will be offered via ELPA, this is not useful. > It serves the purpose of letting a person reading the code know that he > or she is looking at the "definition" of the condition. I though, if I > just put properties on a symbol one might wonder whether the symbol also > serves some other purpose. Technically it is totally unnecessary, I > guess. Should the call to `intern' be removed then? I would say yes. >> Furthermore, since we are in dbus-introspection.el, the functions shall >> not be prefixed dbus-proxy-* > > OK. I wasn't sure, where these functions should be placed. Maybe they > could be in dbus.el and then be called dbus-parse-*? Maybe. Or they are kept in dbus-introspection.el, and are called dbus-introspection-*. > Kind regards, > Jan Best regards, Michael.