Towards less magic strings.

[Brad Bishop]

On Fri, Sep 15, 2023 at 04:21:06AM -0500, Patrick Williams wrote:
>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?

Agree for the most part.  Some interfaces aren't documented there, for 
one reason or another.

>
>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.

Yeah makes sense.  The build time assurances are usually nice (although 
I have been in situations where I did not want every component to fail 
to build just because of a D-Bus interface change).

>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.