in reply to Working with Standard Modules...

We're running into the exact same problem at my job with Spreadsheet::ParseExcel and OLE::StorageLite. Spreadsheet::ParseExcel does a number of horrific things, not limited to A coworker of mine is working on OLE::StorageLite is frustrated by its interesting OO implemetation. For example, it uses magic numbers (defined by M$oft) to determine which class to instantiate. This is all done through a single constructor. Polymorphic constructors are all good, but the determination of which class is made using a series of if-else clauses, not a single function. And, it only gets better from there.

Personally, I'd rewrite it, submit it as OO::Benchmark and start a new 'class' of module. :-)

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Replies are listed 'Best First'.
(tye)Re: Working with Standard Modules...
by tye (Sage) on Sep 26, 2001 at 19:16 UTC

    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")
[reply]
      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]
(jeffa) 2Re: Working with Standard Modules...
by jeffa (Bishop) on Sep 26, 2001 at 21:57 UTC
    You should see the source for SOAP::Lite!! Don't get me wrong - the functionality is great, i owe a lot to the authors, but open up the hood . . .
    • undocumented methods (seek and ye shall find!)
    • several more packages in one file
    • and my favorite first line in a method: shift->new()
    At least the code is well formatted. Sometimes, that's all i really need. :)

    jeffa

[reply]
[d/l]

In Section Meditations