Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Param values stream #844

Merged
merged 2 commits into from Sep 1, 2016

Conversation

Projects
None yet
3 participants
@jlstevens
Copy link
Contributor

jlstevens commented Sep 1, 2016

This PR introduced the ParamValues stream which allows a stream interface to be used to manipulate the parameters of an object that is not the stream itself.

@philippjfr

This comment has been minimized.

Copy link
Contributor

philippjfr commented Sep 1, 2016

Looks good!

@philippjfr philippjfr merged commit c0dc5b7 into master Sep 1, 2016

4 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
coverage/coveralls First build on param_values_stream at 69.329%
Details
s3-reference-data-cache Test data is cached.
Details

@philippjfr philippjfr removed the in progress label Sep 1, 2016

@philippjfr philippjfr deleted the param_values_stream branch Sep 2, 2016

The update method enables the stream to update the parameters of the
specified object.
"""

This comment has been minimized.

@jbednar

jbednar Sep 2, 2016

Contributor

Can the docstring be improved? The PR makes it sound like the stream is updating the parameters, primarily, but what I thought was that it went the other way around, and here it seems to do both. Are these two very different usages? Seems like something to explain.

This comment has been minimized.

@jlstevens

jlstevens Sep 2, 2016

Author Contributor

Sure it can be improved but I don't think anything surprising is going on. Reading values from parameters is how streams specify their value and the update method is how they update those values. In other words this is exactly the behavior you would expect given how streams work in general (i.e the requirements specified by their API).

The only difference here that these parameters live on some other class/object instead of on the stream itself.

This comment has been minimized.

@philippjfr

philippjfr Sep 2, 2016

Contributor

Well, in the case of paramnb the widgets set the parameter values directly and the update method won't really do anything, so there's two ways the parameters can be set. HoloViews doesn't care which one is actually used though.

This comment has been minimized.

@jlstevens

jlstevens Sep 2, 2016

Author Contributor

Right. Though if you aren't using update to actually update parameters, you can use Stream.trigger([callback]) instead. For paramnb it would be more awkward than update as you would need to wrap that in a lambda or something.

This comment has been minimized.

@jbednar

jbednar Sep 2, 2016

Contributor

I'm still confused; seems like Philipp is saying that for paramnb update doesn't do anything, and Jean-Luc is saying that if not using update you'd have to do something else? I guess Philipp is saying that update doesn't do anything but triggering, with paramnb?

What seems like would help is if the docstring outlined at least two different expected usages for this object, one where the object updates the parameter values itself, which is what triggers changes elsewhere, and presumably one where it needs to consume changes to the parameters made elsewhere. Anyway, there's definitely something I'm confused about, but I may be confused about precisely what that is, so this may not be the real thing that needs explaining.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.