Re^2: Writing TIMTOWDI-friendly CPAN Modules

It is vital to focus on interface early and to get it right first time

Well, I have found this is not always possible. Sometimes to find the best interface for a module you have to actually use it and also let others use it and give you feedback.

I think it's better to just release the module as soon as possible clearly stating on the docs that the API could change.

Comment on Re^2: Writing TIMTOWDI-friendly CPAN Modules

Replies are listed 'Best First'.
Re^3: Writing TIMTOWDI-friendly CPAN Modules by eyepopslikeamosquito (Archbishop) on May 15, 2005 at 12:31 UTC
By all means, state clearly that the interface could change. Given it's the OP's first CPAN module, however, he should certainly seek advice on a proposed interface, and especially on module name, before uploading. As for actually using the module to determine how good the interface is, that is one of the many benefits of test-driven development: each test is a first class user of the module's interface and the act of writing the tests often causes one to change the interface. An interface that is hard to test is often hard to use. Code that can be unit tested in isolation is well de-coupled. Writing tests early improves design and interface. The practicality of changing an interface depends on how widely the module is adopted. For example, because File::Find is so heavily used, it has become practically impossible to change its (unfortunate) interface ... well, until Perl 6 rolls out, that is.	[reply]

Replies are listed 'Best First'.

Re^3: Writing TIMTOWDI-friendly CPAN Modules
by eyepopslikeamosquito (Archbishop) on May 15, 2005 at 12:31 UTC

By all means, state clearly that the interface could change. Given it's the OP's first CPAN module, however, he should certainly seek advice on a proposed interface, and especially on module name, before uploading.

As for actually using the module to determine how good the interface is, that is one of the many benefits of test-driven development: each test is a first class user of the module's interface and the act of writing the tests often causes one to change the interface. An interface that is hard to test is often hard to use. Code that can be unit tested in isolation is well de-coupled. Writing tests early improves design and interface.

The practicality of changing an interface depends on how widely the module is adopted. For example, because File::Find is so heavily used, it has become practically impossible to change its (unfortunate) interface ... well, until Perl 6 rolls out, that is.

[reply]