Le 15.10.2007 20:17, Warp nous fit lire :
> Le Forgeron <jgr### [at] freefr> wrote:
>> A new user (better, an innocent user) does not have to know the
>> internal of the product to find the information.
> 
>   I thought the main audience of this new wiki was POV-Ray developers,
> with its main goal being the development of POV-Ray 4.0 and beyond.
> 
>   Perhaps the wiki could be split into two distinct parts: Development
> and users. The former would deal with the development of the program
> (especially concentrating on pov4), while the latter could contain
> everything related to using the program.
> 
I do not know.
I think it's better to have an approach with the "what" rather than
the "how".
That way, you can easily identify duplicated expression of a "need"
in the big collection.

Just taking an extreme example, with only shapes:
Imagine that Core has only available shapes like quartic, quadric,
and so.
And that so far, Cone/Ellipsoid/Cylinder/Plane are macro for the
right definition. (just assume that it's fine with the math, I did
not check).
Then someone push in the Core section, the superellipsoid object,
introducing also a macro for Box (that just a special superellipsoid).
You have everything you need... if you know where to look!
That's the problem: if someone want a box, should it look at the
core or scripting ?
What will stop the braves from adding a sphere in the Core section,
because there was none here and they missed the bable about
ellipsoid macro and the particular case of sphere in the dark part
of a page amongst a thousand others ?

A program is finished not when there is no more features to add, but
when there is no more to removed. (that's a bit of a caricature)

That example is trivial, but populate your wiki with the vaste
amount of possible features, you might very well end-up with two
suggestions for the same target, via differents means. By ordering
on the "how", you will more probably miss the detection of the
identical target.

If you order by the "what" (without considering its possible
implementations), it is easier to find similarities, then factoring
the variations and ending up with a potent yet usable single
implementation.
A bit of ordering at the conception then save you quite some work at
the code-writing stage. (and less code should also mean less
potential bugs, as long as you did not raise the complexity too much).

-- 
The superior man understands what is right;
the inferior man understands what will sell.
-- Confucius

Post a reply to this message