[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-dev] call-backs, co-routines and inversion of control

On Jan 17, 2013 1:14 AM, "Julian Rohrhuber" <julian.rohrhuber@xxxxxxxxxxxxxxxxxx> wrote:
> > Anyone interested in this particular feature would check out the
> > branch while developing it into finished state, then people can test
> > it, then it can be merged back into master. Another good thing with
> > this approach is that the merge back can be compressed into one or a
> > few commits, instead of having half-finished work spread out over
> > multiple commits, making it hard to backtrack in case of discovered
> > bugs or regressions, etc.
>
> It would be good, I just doubt that this is what would be happening now. Maybe I'm too pessimistic, but it seems to me that currently, the branch would just stay untouched and untested.

I'm afraid this is likely to be the case. I admit, I haven't played with topic branches much / at all...

I don't have specific comments on the proposed feature, as it's far removed from my usage patterns. I can't recall ever using "bind," in fact, partly because I never understood the point of it. The method's help gives no reason why one should prefer it to makeBundle:

"Just as in makeBundle, the Function func is evaluated, and all OSC messages generated by it are deferred and added to a bundle, which is sent to the server, using the server default latency."

If it weren't for this thread, I'd never guess what's the expected behavior for server sync. (I'd assume that sync is meaningless inside a single bundle, and structure my code to sync up using other means.)

So, whatever happens with this feature, let's not forget the documentation. If it's doing invisible stuff, then the documentation should explain the correct use of the invisible stuff and the expected behavior when the usage is correct. (To be honest, even after this thread, I'm still confused what the current expected behavior is! Let alone the new behavior... That's part of my skepticism about the proposal: if the new feature is more confusing or less clear-cut than the current situation, then it isn't ready for inclusion in the main library.)

hjh