I don't understand why it's so important not to depend on boost_date_time. It
Might not be a big deal, I just have no problems to compile tu_timer related stuff, but I do have problems to work with boost_date_time.
The problem with tu_ was initially knowledge. I tought it was best to use existing *standard* or de-facto standard classes rather then custom ones, in particular to help a team of developers with a good documentation and more peer-reviewd implementations of common algorithms. I haven't seen the timer one, but that's a single function and I don't have any big problem with it. If boost provides an equivalent function "for free" (ie: not increasing deps) that's fine too for me.
Again: it's not the names, it's the lack of classes documentation, proper copy constructors or assignment operators and so on... it's usually not-clean code in general. And yes, I confirm we never discussed timers in particular till now.
I'd say tu_timer is clear and simple enough and with enough commentary there. "lack of classes documentation" is unfair this time:) I just give my vote for tu_timer against boost_date_time, it makes my programming easier at the moment. _______________________________________________ Gnash-commit mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-commit
