-----BEGIN PGP SIGNED MESSAGE----- Moin,
On Saturday 10 September 2005 21:00, chromatic wrote: > On Sat, 2005-09-10 at 20:21 +0200, Tels wrote: > > On Saturday 10 September 2005 19:27, chromatic wrote: > > > You can always just not run the tests and hope that things work. > > > If the tests don't add any value to you, ignore them. > > > > They add some value to me (show that at least something works). > > Either they're valuable enough that you install their prerequisites or > they're not. But how am I supposed to find this out? I dont even know whether the required modules are used for the tests only, without digging through the source... > > Btw, my graph-perl-usage project is about the same topic: don't load > > unnec. modules. > > *You* don't get to decide which modules *I* use are unnecessary. No, but I can give you hints. Like if you load Data::Dumper, but never use it. You are free to ignore me, tho. And, actually, in _my_ code, I _do_ decide which moduls to use, and when, and when not. And for that I need a way to find out what they currently use. (Think of it like a profiler, without a profiler it is silly to optimize running time.) When I write code, I can either copy&paste everything ever needed into it (but that would be bad), or use a gazillion modules (that would be equally bad). Finding the right balance is the proper way. And without the information what is used by whom and when, you cannot change that. (Like in profiling, you first must measure what takes how much time, and then you can optimize it). I never said that using modules is bad. But using a gazillion modules surely adds quite a few complexity layers to your module, and makes me want to not use it. > You > don't know what problem I'm trying to solve, what my constraints are, > and how I want to solve those problems. When I give away code I write, > I hope that it's valuable to other people. I'm open to suggestions, > but I'm only going to go so far to make it useful to other people, > especially if those suggestions are to duplicate existing, well-tested > code that I don't have to maintain or to optimize for constraints I > don't have and don't believe in. I agreed with you to some point. Code reuse is good, but sometimes it creates more problems than it solves. > If I mark a module with "build_requires" in my Build.PL file, I know > that that means and I do it for a reason. If you don't want to run the > tests, you don't have to install that module. Life's good. Yes. But I was talking about a case where Build.PL wasn't even used by the module in question... > I don't think the answer is "don't use modules" or, as in the p5p > discussion to which I linked, "add these simple extra four lines of > code to every module to prevent using another module which already > solves this problem". As I said, it is about finding the balance. It's abit like the age-old debate about inlining functions, vs. calling them. Sometimes you want to inline them to not have the calling overhead. But most of the time you don't want to inline everything. > Some of the problems the testing modules solve > are difficult enough that it takes a lot of us to get them right and I > don't have a lot of hope that any one of us could get it right > individually every time we retype the same sort of code. > > Test::Exception, for example, is a lot more valuable to me than the way > I tested exceptions before the module existed. It has a better > interface, has more features, and requires me to use much less code. > The same goes for Test::MockObject, Test::Class, Test::LongString, > Test::Builder::Tester, .... > > Code reuse is not the problem. Manual installation is the problem. Acually, in theory anything and all that gets installed should also be tested and evaluated, for security and not breaking anything else. So automated installs are not the answer for all questions :) > Maybe there could be some sort of bundle installer that grabs a module > and all of its dependencies for people who do offline installations. > That might be a great thing. But I'd still need to install all the testing modules just to run the tests prior to install the module itself. Hm. It should be possible to take the offline-prepared bundle and run the testsuite, and only then install the module and the absolute nec. dependencies. Best wishes, Tels - -- Signed on Sat Sep 10 21:03:22 2005 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. "Elliot, Sie Schwachkopf!" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iQEVAwUBQyMyJHcLPEOTuEwVAQHjjwf/QXtRvByIw0K8dgp5Oxekncyj/Gklttcz h1quREA5cRoPVElSzaSu/LAyR6j0PMzlsTVSlyQajlsgOKx5D6SRQhNjMWMyTanp Wclm9xyviJQZzhb1hKrg1Qq4ok+q3JrjnkKIBfbZKxzQOtu280szE+MjJYiJ4zhe zEXZiYvuqwDp+qpUw1zyysn0FLC4+SYGi5CUTlIxCvkK2X+9geVmM+TwvwcYNILe hZ4tTtOTdx3ZEWTM8j5LsZTUocbPK69e3Gn0Gq+8og9bBcQSAAIBOPYVpQpYeMjE vMEfyVJ5xBUfMlhexUd19E13/W3uBLRcu+fzZbfS0rH7dc71vuVrmw== =XfkB -----END PGP SIGNATURE-----
