Re: Inclusion of dbus-proxy

[Jan Moringen <jan.moringen@uni-bielefeld.de>]

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