Towards less magic strings.

[Patrick Williams]

On Thu, Sep 14, 2023 at 10:26:37AM -0400, Brad Bishop wrote:
> On Thu, 2023-09-14 at 01:36 -0500, Patrick Williams wrote:
> > When I look at these, the vast majority of them falls into 1 of 4
> > different reasons:
> >     - A well-known service name.
> >     - A well-known path (or path prefix).
> >     - An interface name.

As a concrete example of what I'd like to see improved is this verbiage
embedded in the YAML description:

    https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Sensor/Value.interface.yaml#L3

> In my mind these are not magic strings.  These are parts of an API.  We
> don't get annoyed by having to hardcode c++ function names when we call
> them - why do we get annoyed by having to hardcode DBus names?

They may be parts of the API, but we document the API in PDI, agreed?

The big difference between C++ function names is that the compiler tells
us when we messed those up (and your editor can do completion on them if
you've set it up).  With these strings, we're relying on humans and
runtime-detection to ensure we've got it correct.  Often we get it
wrong.  It has also been challenging to refactor dbus interfaces, again,
because we don't get compile-time assurance of correctness.

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20230915/9b4bf4ae/attachment.sig>