Hi Vlad, I will take a stab at that.
As I said, your code is good for a general purpose implementation. The problem is UT is not a collection of general purpose implementations, it is there to served a purpose and this should be in the most compact way. You have many unnecessary generalities in the code, like the templated constructor to TestNameRegexPredicate. This is open for the future but completely unnecessary to the task at hand. Binding down to concrete implementation is significantly more readable and intuitive. Your code has the elegance the C++-foo that can be found with boost and similar libraries like the MTL. But it is definitely not the most effective in terms time and intellectual resources needed to get it working. Sean On Sun, Jan 31, 2010 at 10:27 PM, Vlad <v...@demoninsight.com> wrote: > > On Jan 31, 2010, at 3:00 PM, Sean Farrell wrote: > >> but a bad engineer. Many things are off the top >> implementations which could be implemented very easily. Take the >> OpParser for example. All is needed are a few fixed command line >> options that can be read with a simple for loop. Like the wild card >> matcher, a simple explode and find would do the trick in about 10 >> lines of code. > > You're calling me a "bad engineer" based on the fact that I chose to > re-implement the opt parser? That's just unprofessional. When the code was > originally submitted the above *was less* than 10 lines of code: because it > used boost::program_options, it was trivial. My effort to get rid of boost > dependency was about 3x the effort to write the goddamn driver in the first > place -- and I chose to just reproduce the dependency functionality so that > things just plugged in. Furthermore, having a re-usable OptParser seems like > better modular design (and perhaps more future-proof) than your alternative. > From where I come from, that's not automatically "bad" engineering. > > The original code had been in use for some time where I work and was offered > "as is", as a free donation. Also remember that when the original code was > submitted, several people were asking "how do I submit a patch?", "when is > the next release?", etc -- there was no policy, no coding convention, no > project owners in sight, etc. I am glad that now things are getting better > but am surely sore that mine was the first patch to get the benefit of your > new policy. > > Adios. > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > _______________________________________________ > unittest-cpp-devel mailing list > unittest-cpp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/unittest-cpp-devel > ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ unittest-cpp-devel mailing list unittest-cpp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/unittest-cpp-devel
