sort of like the version property of the DynAPI object ?
(but remembering to increase it before the release is difficult ;)
One serious thing about patches is this: they should be considered
as "dynapi-developer" material not end user code.. Patches are usually
only tested on a single system (1 maybe 2 browsers) and therefor might
not be stable to include in the real code.
I do agree that comments should be more clear for the patch, and I think
this mailing list can be helpfull for that because patches can be mailed
containing a better explanation (thank god for interpreted code).
if the code was documentated by the authors, the documentation wouldn't be
the
problem here ;-) I think that the documentation project is a good idea and
that new code (basically patches/bug-fixes) should be explained (possibly
using
the mailing list again) so that the "people doing the documentation" can
update
the docs..
the private and public problem could be solved with a good developers
reference
stating what's private and what's not.. other documentation should simply
talk about
public functions/properties only and leave the "inner-workings" of the
DynAPI out of
the picture, just a thought.
I've been looking at Dan's original developers reference (making some
changes
and updates) but it's far from uptodate.. so if anybody wants it just say
it, and
I'll mail it to you (developers reference, NOT end-user documentation)
Pascal Bestebroer
pa...@dy...
http://www.dynamic-core.net
-----Oorspronkelijk bericht-----
Van: dyn...@li...
[mailto:dyn...@li...]Namens SReindl
Verzonden: vrijdag 27 oktober 2000 13:02
Aan: dynapi dev
Onderwerp: [Dynapi-Dev] identification od versions
Hi DynApicators,
as I follow the discussion in here and in the help list, I believe, one of
the problems is the identification of the versions.
So, why not inserting a line, which shows at least the date and time of
creation or, if there is some kind of central control (who?), a running
version number? This should help to avoid confusion.
Also, I would appreciate if (patch) authors could mark the lines they
changed, may be together with a short explanation of why they did it. If you
have problems with the file size, you can remove the comments by your own.
Thirdly, concerning the "documentation project": I would appreciate very
much, if the code could be documented by the author at least in so far as
that I would like to know the purpose and scope (see below) of the function.
It's not that I cannot understand, what she/he was doing, but it costs some
extra time to analyze the code.
Lastly, I think, many functions are merely ment for INTERNAL use inside of
the DynAPI. In the language of OOP, they would be marked protected or even
private. They are not part of the API. Could we get some agreement of how
name those functions and to distinguish them from "outer" (exported, public,
...) API functions? For users, it should be not neccessary to understand all
this internal stuff to use the API.
Greetings,
Dr. Stephan Reindl
Mail: SR...@la... <mailto:SR...@la...>
Internet: www.lamello.de <http://www.lamello.de>
_______________________________________________
Dynapi-Dev mailing list
Dyn...@li...
http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
|
