Ok. Thanks for the explanation. Cheers, Daniel.
On 9 April 2016 at 02:30, Tom Breloff <t...@breloff.com> wrote: > I understand that to you this seems intuitive, but to me it is completely >> counter-intuitive. The function that I'm calling is not changing any of its >> inputs. Telling me that behind the scenes it calls "plots!" is describing >> an implementation detail that can change and should have no bearing on the >> exposed API. >> > > It's not behind the scenes or an implementation detail. The "proper, > exposed" API looks like: > > plt = plot(rand(10)) > plot!(plt, xlim = (0,20)) > > Here plt is a julia object. It's constructed during the first call, and > changed in the second call. This is the only form that should be used for > "serious" work, as you shouldn't depend on global state in general. For > your original example, you were on the right track: > > plt = plot(title = "...", xaxis = (...), ...) > for dir in directories > ... do some work ... > plot!(plt, result, ...) > end > > You can set up the plot attributes in the first call, and then add series > (data) with your results. > > In your original code, what if there's something in that "do some work" > that calls a plotting command? (answer... your code breaks) So the > mutating plot call without an AbstractPlot as the first argument is really > only meant for quick, one-off, analytic work. It's not meant to be the > primary usage pattern. > > I would argue that "plots(plt, ...)" is like "write(stream, ...)" >> > > In this example, plt is a julia object that is mutated, whereas stream is > effectively unchanged (it still points to the same file descriptor, or > whatever it wraps). > > The better analogies (IMO) are: > > plt = plot() > x = rand(10) > > # these are similar > push!(x, rand()) > plot!(plt, x) > > # these are similar > show(io, x) > display(plt) > > >
