On 16/03/12 01:33, Tim Landscheidt wrote:
Magnus Manske wrote:
[...] At the risk of over-designing, would it be worth to gather language-independent requirements for a module/library, on the toolserver wiki or on meta, and then keep implementations of that standard (yes, I know, "one more standard") available on the toolserver? At the very least, a language-neutral brainstorming might prevent design flaws, especially with database-with-API-fallback in mind.
It depends on what you mean by "requirement". Something like "a library *must* provide a function normalizeLink() with these semantics" would probably deter developers from trying to implement it. If on the other hand there was an algorithm "if you want to normalize links, do A, B, C, D and E" and corresponding test cases to check compliance, I think it would be much more inviting.
Tim
I think it really makes sense to define the names of a set of available functions. That would really make much simpler the development of portable tools, or working on different languages, without having to relearn the framework used. That said, each of us would probably push for their own API to be standarised. I don't think providing tests is the panacea for making people implement them. They are obviously nice, but as it would be open source, each user doesn't need to reimplement them according to the specification. The same code could be shared. The problem is in adoption of the API, and agreeing on an "standarised" one.