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

Re: [Sc-devel] 3.2 RC cutoff time [was Re: Quarks and svn]

Hi James,

There is a wider debate to be had, but we don't have time. I committed the fix for PauseStream:start to have nil as default for quant (r7142)

I can see how a general Quant default mechanism would help resolve this to individual choice over more cases, but we don't have time for the necessary consultation on all this at this late notice; I have to sleep soon anyway. 

Your assertions below could lead us off into the old debates once more. I do {{}.fork }.fork all the time and it never hurt me ;  ) We could take the discussion off list if you want to swap hierarchical scheduling examples; it might be I'm misunderstanding something. But I don't think you can convince me that quants based on 'beats' are necessarily compatible with the most flexible time representations. Anyway, an argument for another day, not at this proximity to 3.2 cutoff. 


On 27 Jan 2008, at 23:29, James Harkins wrote:

On Jan 27, 2008, at 6:13 PM, Click Nilson wrote:

the patch looks nice for me, since I overwrite all the quant defaults where they're 1.0 myself (my hacky class file attached for fun). Of course, I'd want the default for Quant.default to be 0.0  ;  )

Quant.new *is* 0.0.asQuant :)  So the patch that I submitted would give you exactly that behavior, unless you change Quant.default.

I would have to vote against hard coding 0.0 in method argument lists. Having a nil default in the method headers reverts to Quant.default, which normally will behave as if it were 0.0.

yes, 'everyone' was probably an over-reaction, but I just had nightmare thoughts of the amount of code that might depend on Task().start or whatever. 

That's a legitimate concern. I was just pointing out that the situation in the library is not so uniform as you assumed.

1.0, I believe, comes from James McCartney, who would counter your argument with the observation that scheduling a task from outside the clock gives you no assurance of any kind of synchronization with other processes. (Recalling discussion from a few years ago about why it's a bad idea to play a pattern or routine inside another routine -- which is a slightly different issue, but related.)

Anyway, we, at least, are in agreement on the basic point that consistency is better, and imposing the fewest assumptions in default behavior is also better.


: H. James Harkins

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal."  -- Whitman

Sc-devel mailing list