[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Inclusion of dbus-proxy
From: |
Jan Moringen |
Subject: |
Re: Inclusion of dbus-proxy |
Date: |
Tue, 24 Aug 2010 04:03:43 +0200 |
Hi Michael,
thanks for the extensive feedback.
> >> 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,
> > [...]
> > 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.
I committed the following updated explanation which makes fewer
references to EIEIO:
;; 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 Emacs Lisp code
;; that mimics the D-Bus interfaces. This code mainly consists of
;; functions which correspond to the D-Bus interface methods, but
;; information about D-Bus properties and signals is also stored.
;; When called, the generated functions augment their arguments with
;; D-Bus type information and call their corresponding D-Bus methods.
;; When these proxy components are created, names are transformed from
;; D-Bus-typical CamelCamel to something-more-lispy. The generated
;; functions and object slots can be used like ordinary Emacs Lisp
;; functions and object slots.
> >> > + 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.
Ah, OK. Well, this has to be done later in case dbus-proxy is included
in Emacs, I guess
> If dbus-introspection.el will be offered via ELPA, this is not useful.
Yes.
> > 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.
Done.
> >> 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-*.
Done.
I think, I addressed all suggestions which do not depend on changes in
Emacs itself. The code is available at
https://code.launchpad.net/~scymtym/+junk/dbus-proxy
Kind regards,
Jan
- Inclusion of dbus-proxy, Jan Moringen, 2010/08/21
- Re: Inclusion of dbus-proxy, joakim, 2010/08/22
- Re: Inclusion of dbus-proxy, Michael Albinus, 2010/08/22
- Re: Inclusion of dbus-proxy, Jan Moringen, 2010/08/22
- Re: Inclusion of dbus-proxy, Kevin Rodgers, 2010/08/23
- Re: Inclusion of dbus-proxy, Michael Albinus, 2010/08/23
- Re: Inclusion of dbus-proxy,
Jan Moringen <=
- Re: Inclusion of dbus-proxy, Michael Albinus, 2010/08/24
- Re: Inclusion of dbus-proxy, Chong Yidong, 2010/08/24
- Re: Inclusion of dbus-proxy, Tom Tromey, 2010/08/24
- Re: Inclusion of dbus-proxy, Michael Albinus, 2010/08/26
- Re: Inclusion of dbus-proxy, Jan Moringen, 2010/08/24