Re: [PyX-devel] Re: [PyX-checkins] pyx/test/functional test_bargraph.py,1.7,1.8 test_graph.py,1.50,1.51

[Andre W. <wo...@us...>]

Hi Jörg,

On 22.07.04, Joerg Lehmann wrote:
> You misunderstood me. I did not mean that the user should call this
> function, but I was just suggesting that the style handles the return
> value separately, i.e., not in the function donedrawpoints. But this
> is not so important at all.

Ok. I might spend a separate function. But as you said, this is an
implementation detail and not so important.

> > First I thought it would be a bad idea to return something else than
> > the data instance at the plot command (because its like what we do in
> > canvas.insert etc.). On the other hand, the data is not -- *never* --
> > bound tightly to the graph. It contains no information about what's
> > plotted. (Currently, it does, because sharedata and privatedatalist is
> > storred in the data instance, but thats a misfeature we will resolve
> > in the future. Once we did, there seems to be no reason at all, why a
> > data instance does not contain any information about the output
read: data instance does contain any information about the output
> > created. In the future I don't see any reason, why the data would need
> > a container like privatedata/sharedata/styledata. It does not have to
> > store anything related to the graph.)
> 
> I'm getting confused...

The point is, that it does not make any sense, that the plot method
returns the data instance(s) in the future since those will not store
any information related to the current graph (as it currently does,
since privatedatalist and sharedata are instance variables of data
right now).

> > Hence I think it would be good to allow the styles to return something
> > related to the stuff actually drawn. The only remaining question is,
> > whether this fancy_return is the right thing to do. I'm still not
> > satisfied. In some sense it makes sense to make the finish process
> > visible. Back to #2: Explicit is better than implicit. What about
> > something along the lines:
> > 
> >     pd = graph.plot(data(...), [graph.style.line()])
> > 
> >     p = pd.finish()
> 
> I do not like this idea. Why should one finish the plot data? This
> sounds very strange to me. However, I could imagine a
> 
>     p = pd.getX()
> 
> with X={styleinfo,styledata,...} whathever you like.
> 
> > where pd are the "plot data" and p is the path. Its more or less back
> > to what we had in the sense, that we have this plot data construct,
> > which takes care about the graph instance needed, the data and styles
> > in use, the return values, the finishing process etc. Still, the
> > styles should be responsible to create the return value(s). In the
> > first we only need to return the path when creating a line. The plot
> > data instances will have a finish method only, which will take care of
> > the internals and return the draw results from the styles. And that's
> > it. I think that's probably ok. Its not that complicated and its quite
> > explicit.
> 
> As I said above, I do not like the name at all. And I also don't see
> a problem in returning something from the plot command which will
> only be populated with data later, namely when the graph has been 
> finished.

The point is, that it can't be just a list. Otherwise the user would
immediately split up the list content and we can't populate the items
later on:

    p1, p2 = g.plot(...)

(Still, we could some fancy_return construct for the return values p1
and p2).

So another possibility would be to return a container, i.e. an
instance of an empty class, where instance variables can be set as
needed:

    pd = g.plot(...)

We can than access those instance variables, once they are created
(after the graph was finished):

    c.stroke(pd.path)

But here's a problem. Suppose the styles create several paths (this
becomes possible in stacked bars once the new bars are finished):

    pd = g.plot(d, [graph.style.bar(), graph.style.line(),
                    graph.style.barpos(stack="ystack1"),
                    graph.style.bar(), graph.style.line()])

pd shall contain two paths now. Thats what styles get privatedata for.
But how to access that by the user. Back to my suggestion, it would
look like:

    p1, p2 = pd.finish()

Still, finish is the wrong name. We might come up with a single name
used in both cases: as a style method name (instead of introducing a
return value of donedrawpoints) and here as well. Something like
styledata (or stylesdata) ... this name has vanished internally in
favor of sharedata and privatedata. So we could use that ...

Still, not sure whether we're getting it right at all ... but I think
this solution would work well.


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/