Re: Inclusion of dbus-proxy

[Michael Albinus]

Jan Moringen <address@hidden> 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.