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.