Make update_component() signature more intuitive about vincent HOT 3 CLOSED

I agree that when using the update_component method, your syntax feels more intuitive. There are a couple of tricky things though. The first is that update_component is the building block for __iadd__,__add__,__isub__, and __sub__, which is supposed to be the user-facing API for Vincent, where the examples above read

 >>>my_vega += ('w', 'axes', 0, 'scale')
 >>>my_vega -= ('width', 'marks', 0, 'properties', 'enter')

In my brain that reads add w to (axes, 0, scale) and remove width from (marks, 0, properties, enter), which feels straightforward and I think works pretty well in practice.

The second is that update_component is doing a recursive dive into the tree via passed arguments, and by leaving the args to the end we don't have to introduce more control flow to catch an "add" or "remove" as it traverses the vega spec.

I'm very hesitant to make a major API change like this, but I'm open for discussion if any of the other Vega contributors and users have thoughts.

from vincent.

Hi @wrobstory, thanks for your comments. As a Vincent newbie, i appreciate the explanation.

To my mind, the following calls are more intuitive

 >>>my_vega += ('axes', 0, 'scale', 'w')
 >>>my_vega -= ('marks', 0, 'properties', 'enter', 'width')

because they list from left to right the path through the Vega spec tree to the desired change.

But, like i said, i'm a Vincent newbie and so defer to you and other long-time Vincent users on this point. Maybe through using Vincent more, i'll adapt and eventually find the current syntax natural.

from vincent.

Heh- Vincent is new enough that there are no long time Vincent users yet! Your input is appreciated, because we're still early enough in it's life that we can think about syntax changes like this. If you're motivated, you could fork the project and create an implementation of the syntax you are suggesting. The Vincent source code is a quick read, and pretty friendly to tinkering.

Also, go take a look at Issue #31 - we're probably going to be moving towards a more friendly ORM-style implementation of chart creation, and leave things like update_component for power users in the future.

from vincent.