On 2008-01-17 14:06, Dirk Meyer wrote: > Yes, conceptually they are the same, but the implentation is a very > different. 'main' needs a completly different JobServer. Right now we > have MainThreadCallback is a simple class, we would have to greate a > MainJobServer to inherit MainThreadCallback from JobServer. This is > writing code without the API feeling different. >
It might well be the case that although they are similar in concept in implementation they are so different that trying to reuse code will just complicate things. I'm not too familiar with how jobserver works so I'd have to look at it. > This would break some code, but I guess we are at a point where it > does not matter anymore. Yes, now's the time to do it. >> (I wonder if it'd be useful to have a convenience function >> Signal.connect_thread, in which the callback is wrapped in a >> ThreadCallback, so the handler is invoked in the specified thread.) > Yes Then either we should reserve 'main' to have special meaning, or add a connect_mainthread(). The former is probably better. > But we want to keep Timer with a start function, right? Yes, because Timer derives from NotifierCallback for implementation reasons, but I don't see it as a callback in the same sense that say MainThreadCallback or WeakCallback is used. Apply this litmus test: if it's something you might want to connect to a signal, it should have 'Callback' in the name and be callable. > twisted, camal case is what they use. So maybe we could start breaking > things completly and use camel case. I personally don't like variables > like 'in_progress = InProgress', it looks bad to me (that is why I > name the variable async most of the cases). inProgress = InProgress > looks better IMHO. I find in_progress more readable actually, and more easily distinguished from class names. But regardless, I'm going to oppose changing our naming conventions now because this is a far, far more massive and intrusive change than anything we've done so far (it affects almost every other line of every kaa module) and the reason is only cosmetic. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Freevo-devel mailing list Freevo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-devel
