(Author here) I needed to do a bit of "reflection" in a Rust crate but didn't want to implement a procedural macro, so I used Serde (which is a (de)serialization crate) instead.

This is also a deep dive into Serde internals - hope you'll like it!

Pardon me, but I prefer the original by 1 million miles.

  let res = raw_api::query("SELECT * FROM Win32_Fan");
  for obj in res {
    if obj.get_attr("ActiveCooling") == Value::Bool(true) {
        if let Value::String(name) = obj.get_attr("Name") {
            if let Value::UI8(speed) = obj.get_attr("DesiredSpeed") {
                println!("Fan `{name}` is running at {speed} RPM");
            }
        }
    }
  }

If actually concerned about the need to know UI8, then create a typedef DesiredSpeedT or similar. This is equivalent to the struct Fan.

Edit: I understand the post is probably more of a playful exercise than anything else, but I really think the original is far far better (smaller, simpler, etc.) and hope that is not lost on people.

This kind of sells the reason not to wrap things behind an object interface, doesn't it?

    for fan in c.query("SELECT * FROM Win32_Fan"):
        if fan.wmi_property("ActiveCooling").value is True:
            print(f"Fan `{fan.wmi_property('Name').value}` is running at {fan.wmi_property('DesiredSpeed').value} RPM")

vs "SELECT Name, DesiredSpeed from Win32_Fan where ActiveCooling"

Obviously, this doesn't matter when you have 5 fans, but in general, you want to push your restrictions as deeply into the query as possible from an optimization standpoint.

Interesting post. We wrote this “below” utility [1] that monitor system metrics similar to atop. We want the ability to collect all metrics into a single object, pass it around and visualize it elsewhere. Naturally we need some way to query into fields or even nested-struct fields. For example, to get the file cache usage of a particular process, we need to go through sample->processes->pid->memory->file cache. To do it ergonomically and also type-safely, we end up using proc macro to generate enums that represent field paths of the structs and then use them to query values of non-struct (leaf) fields. I always wonder if there are simpler ways or existing proc macro derives to safe us the efforts. Maybe I do need to look into serde internals for some inspirations.

[1] https://github.com/facebookincubator/below/blob/main/below/b...

In my opinion, the clean way to implement this is with methods instead of attributes for name, desired_speed, etc...

The title is vague in my opinion. What kind of API? What problem does it hope to solve? The article uses querying system data as examples, but after skimming it, I’m not sure why I would care. My comment is also a criticism of the article, since I couldn’t skim in quickly to figure out if I should spend more time on it.

I don't really understand what this offers above diesel.rs which AFAIK is a similar reflection interface except with much more flushed out ORM capabilities (much more complex filtering, joining etc) & support for an assortment of SQL dialects.

> let res: Vec<Fan> = query();

It might feel more natural, and less magical if this used a turbofish instead

    let res = query::<Fan>();

Very neat

That's wdat minijinja does internally. As an argument to Template::render() you can give it any struct that implements Deserialize. That's how you can get varying (sic) variables to a single function and even attributes on "objects" processed by tte template.