Mail Archives: djgpp-workers/2001/10/12/05:26:18
> Right, except that findfirst was there first, and _dos_findfirst
> didn't seem like an important addition, so I guess no one looked very
> hard inside it.
May I say that's for me the limit of the 'one external function per file'
rule ? Instead of having one core code in one location privately shared by
multiple interfaces, you end up with multiple core codes with their own
interface or single core codes publicly shared by multiple interfaces (see
below).
> There is no one function per file rule, only one _external_ function
> per file rule. You will see that some source files in the library do
> have static helper functions, and those are not (and should not be)
> documented.
Ok, but the 'one external function per file rule' leads precisely to make
external functions of helper functions: the three low-level wrapper
functions I proposed are IMHO helper functions that shouldn't be exposed to
the public. Now they are exposed to the public: should I document them
anyway, given that the user will be already faced with no less than three
sets of find*() functions ? Won't a fourth set of find*() functions confuse
him ?
> An external function is something that functions in other modules can
> call.
So either a function is private to a module (static) or publicy exposed and
documented (external) ? Isn't there any room for functions private to the
library (non static, non publicy exposed and non documented in a .txh file
but only in their source file) ?
--
Eric Botcazou
ebotcazou AT multimania DOT com
- Raw text -