[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Inclusion of dbus-proxy
Re: Inclusion of dbus-proxy
Tue, 24 Aug 2010 04:03:43 +0200
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.
> > 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
I think, I addressed all suggestions which do not depend on changes in
Emacs itself. The code is available at
- 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