Re: stem3 function

[Michael Goffioul]

On 11/30/07, David Bateman <address@hidden> wrote:
> I had hoped that all of the specialized functions I wrote could be used
> with JHandles. However, of course as you implement hggroups you have
> better matlab compatibility and so need a specific backend function.

Most (if not all) of the functions you wrote recently *are* compatible with
JHandles, because JHandles implements all core graphic objects and
your functions only uses core objects. The problem is when I want to
make JHandles more compatible with Matlab by using hggroup objects
and dynamic properties (with listeners); the front-end (argument parsing,
checking and pre-processing) is mixed with object creation, which makes
it difficult for JHandles to hook up its own object creation function. If I
take the stem example, I'd have to duplicate __stem__.m completely,
while the only actual needed thing is to "overload" the 2 plot commands.

> When Octave implements hggroups this issue will go away and the same
> frontend functions might be used for both.
>
> In any case, can you suggest a change? I suppose the change is like the
> change to __bar__.m and __bars__.m that you made.

Indeed. In general, for any graphic object (in the Matlab sense), you'd
have a __go_xxxx__ function that creates it: this function would receive
all the needed data to build the object correctly. All the rest is part of
the front-end and can be shared. What was nice with the bar example is
that the bar.m function can be used to generate the bar data; so JHandles
don't even need to implement that (in the listeners).

Michael.