From: Michael Albinus <michael.albinus@gmx.de>
To: Jan Moringen <jan.moringen@uni-bielefeld.de>
Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: Re: Inclusion of dbus-proxy
Date: Mon, 23 Aug 2010 17:44:06 +0200 [thread overview]
Message-ID: <nqtymlxrjt.fsf@alcatel-lucent.com> (raw)
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")
Jan Moringen <jan.moringen@uni-bielefeld.de> 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.
next prev parent reply other threads:[~2010-08-23 15:44 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-21 22:03 Inclusion of dbus-proxy Jan Moringen
2010-08-22 14:47 ` joakim
2010-08-22 16:20 ` Michael Albinus
2010-08-22 21:04 ` Jan Moringen
2010-08-23 13:23 ` Kevin Rodgers
2010-08-23 15:44 ` Michael Albinus [this message]
2010-08-24 2:03 ` Jan Moringen
2010-08-24 19:50 ` Michael Albinus
2010-08-24 21:32 ` Chong Yidong
2010-08-24 23:59 ` Tom Tromey
2010-08-26 10:09 ` Michael Albinus
2010-08-25 3:24 ` Jan Moringen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=nqtymlxrjt.fsf@alcatel-lucent.com \
--to=michael.albinus@gmx.de \
--cc=emacs-devel@gnu.org \
--cc=jan.moringen@uni-bielefeld.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.