Thanks for the note Wizard.

First I must admit and apologize for having cited the wrong module dependancy. In fact it is Class::MethodMapper not Class::MethodMaker. In the past I had evaluated class generation tools such as these and generally understand their purpose and advantages.

In this case I don't feel that this type of modules would really help significantly in the implementation of this class. As well, it is my opinion that fewer dependancies means greater chance of adoption of a module. (at least that is what I have observed locally)

Additionally, making your code dependent on another module does present a certain risk. In this case certain modules have not been touched for 18 to 20 months. What happens when you need features added or bugs fixed but the maintainer has moved on or does not respond to your patches/requests? Given the complexity of a vCalendar / vCard file parser/generator I don't think it merits these risks in exchange of anticipated returns.

Finally, I'd like to apologize again to Martyn for my error in mentioning his module incorrectly and by no means did I mean to imply that a dependancy on Class::MethodMaker is a bad thing.

J

On Tuesday, January 7, 2003, at 11:20 AM, Wizard wrote:

This is something that seems good to me.  However, I'm somewhat
perturbed at
your mention of reliance on a another module as a reason against using
something.  I'm biased; I'm the maintainer of Class::MethodMaker.
Not trying to insult any author in particular, I have also chosen in several
cases not to use existing CPAN modules because they or modules they were
dependent upon didn't pass the -w or -T test, or where hugely bloated for
what I was doing and therefore ran significantly slower than my code (300%
in one case). I feel that both of these are legitimate reasons for shying
away from certain CPAN code.

If Jay has simply chosen not to use CPAN modules simply because he's biased
toward his own code, that is pretty unfair. I think that he should at least
take a look at it. I haven't looked at either the Net::ICal or Jay's module
but if they are competing for the same user space, perhaps the two
maintainers should discuss a collaboration. This could prove to be the best
option for all involved, as it could produce a better module then either one
alone.

small note: The collaboration thing doesn't always work out. It didn't in my
case, but I still think it's worth the effort.

Grant M.
[EMAIL PROTECTED]





Reply via email to