(tye)Re: Working with Standard Modules...

In general, I'd like to give a gentle shove in the direction of patching the module and keeping the name the same. If that turns out to not work, then any new module dealing with benchmarking should really go under Devel::, so I could also support patching Benchmark.pm into Devel::Benchmark and making Benchmark.pm deprecated.

But I'd prefer to not have two separate places where the basic timing code is actively maintained. That type of thing happens a lot, but that doesn't mean that it doesn't suck. Take any number of interesting problem domains and try to find the best of the many CPAN modules that address it and you'll see what I mean by "sucks". (:

- tye (but my friends call me "Tye")

Comment on (tye)Re: Working with Standard Modules...

Replies are listed 'Best First'.
Re: (tye)Re: Working with Standard Modules... by demerphq (Chancellor) on Sep 29, 2001 at 06:01 UTC
But I'd prefer to not have two separate places where the basic timing code is actively maintained Exactly! Thats why I wanted to use the timing code from Benchmark in the first place. Incidentally I think one problem with actually deprecating Benchmark is that there is a fundamental difference in psychology to using a module and using an object. In a module you expect to get everything you need. In an object you expect to only get what makes sense. Consider in Benchmark you have code from 4 different groups of functionality: Time object manipulation routines Timing routines (ie actually calculate th time elapsed) Caching routines Report production routines So how to rework this? My current plan is bascially this: `Benchmark::TestBench -- Timing routines Benchmark::Testbench::Std -- The high level report Benchmark::Result -- A time object Benchmark::Testbench::Test -- new, used by ::Series Benchmark::Testbench::Series -- New, replaces ::Std` [download] Right now the question is whether timethis,timethese and cmpthese should go into the same class that has the actually timing routines. I say no, because they have more to do with handling user input and formatting and printing results than anything else. Anyway, i should have been in bed long ago so... Till next time. :-) Yves -- You are not ready to use symrefs unless you already know why they are bad. -- tadmc (CLPM)	[reply] [d/l]

Replies are listed 'Best First'.

Re: (tye)Re: Working with Standard Modules...
by demerphq (Chancellor) on Sep 29, 2001 at 06:01 UTC

But I'd prefer to not have two separate places where the basic timing code is actively maintained

Exactly! Thats why I wanted to use the timing code from Benchmark in the first place.

Incidentally I think one problem with actually deprecating Benchmark is that there is a fundamental difference in psychology to using a module and using an object. In a module you expect to get everything you need. In an object you expect to only get what makes sense.

Consider in Benchmark you have code from 4 different groups of functionality:

Time object manipulation routines
Timing routines (ie actually calculate th time elapsed)
Caching routines
Report production routines

Benchmark::TestBench      -- Timing routines
Benchmark::Testbench::Std -- The high level report
Benchmark::Result         -- A time object

Benchmark::Testbench::Test   -- new, used by ::Series
Benchmark::Testbench::Series -- New, replaces ::Std
[download]

Anyway, i should have been in bed long ago so...

Till next time. :-)

Yves
--
You are not ready to use symrefs unless you already know why they are bad. -- tadmc (CLPM)

[reply]
[d/l]