Hello. Can we at least start with designing new APIs before ripping out old system? Then we can compre effort of migrating vs ripping.
-- Bacek On Sun, Jan 2, 2011 at 2:10 PM, Christoph Otto <[email protected]> wrote: > On 12/31/2010 10:50 AM, Andrew Whitworth wrote: >> >> On Fri, Dec 31, 2010 at 12:05 PM, chromatic<[email protected]> wrote: >>> >>> I agree with the rationale for replacing the existing threading system, >>> but is >>> it really so unrecoverable that we can't use our traditional mechanism of >>> replacement? >>> >>> 1) design a better API >>> 2) hide the current malfeasances behind said API >>> 3) replace the backend in place >> >> I do understand your point, and I thought about suggesting something >> like that instead. However, considering the amount of (known-working) >> code in src/thread.c compared to the interfaces and logic we would >> need to update to make an API that we wanted for the future and the >> amount of work it would take to transform the current system to fit >> the new API, it really doesn't make a lot of sense. > > If we have a use case where threads allow a user to do some kind of useful > work, we should preserve that. Replacing an interface while maintaining the > old one is harder than ripping it out and reimplementing it from the ground > up. It's very much worthwhile if the old interface is in some way usable, > but I don't think that's the case here. If someone can come up with a use > case for the current threading code, we'll preserve the interface while we > reimplement. Otherwise, we should consider ourselves free to rip out the > old code and start afresh. > > Christoph > > _______________________________________________ > http://lists.parrot.org/mailman/listinfo/parrot-dev > _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
