phpgroupware-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Phpgroupware-developers] Standard source code header and php Docum


From: Kai Hofmann
Subject: RE: [Phpgroupware-developers] Standard source code header and php Documentor
Date: Fri, 27 Jun 2003 12:55:08 +0200

Hi Dave,

> > Last but not least using another free php project would be a better
> > political choice
> > and the documentation would be more similar to the pear one.
>
> I did not make the decision, all I am saying is why start changing it
> when the job is not yet complete?  It would be less work to 
> finish what has been started, rather start over.

The job has never really started - thats what I saw in the whole API source
code
so there is nothing to finish.
And comments that already there can be used by simple copy&paste with the
phpdocumentor format.

> > Sorry I don't see it in this way - so maybe someone other will do 
> > that.
> 
> Then how do you see it?  cos you have lost me.  You are saying 6mths
> work to start from scratch, so obviously it would be faster 
> to build on the existing base.

Again: there is no existing base - for an example please take a look into
the
phpgwapi/inc/access_* classes:

class.accounts.inc.php
No comment at all - but it is no class and only a few lines of code

class.accounts_ldap.inc.php
- Copyright header
- 1 method out of 14 has a comment

class.accounts_sql.inc.php
- 13 methods only 2 of them have docs

class.accounts_contacts.inc.php
- 13 methods all undocumented

class.accounts_shared.inc.php
- 8 methods only 2 with a doc

These four classes have been already documented by me completly now - 
but I have only submitted one as a patch.
The rest of the api looks the same - maybe 10-15% of the methods is
documented right now.
Most of the class/glbal variables are undocumented.

So before discussing this point with me you should take one or two days to
read the complete
api source code (as I did by creating the argiuml diagram - which toks much
longer).

> Well, the "bug reports" you have logged, not all are bug reports.  The
> form they have taken has not been very useful.  For example ~10 reports
> for different apps, with the same name is very annoying.

So for what I had to set the module specification?
The topic was correct for all - SYNTAX ERROR.
Adding the Module name again to the topic is data doublication.
But as I have seen by the session classes that the normal way you are
working :(

> We currently
> have ~160 open bugs, so clear descriptions make my (and others) life a
> lot easier.

When I would have cvs access to the api I would never have reported these - 
I had fixed them and then you have nevern known that they are there ...
But it seems you like it more to discusses these things than "just doing
it".

> You have also failed to listen to feedback on the tracker.  Also code
> changes which are not bugs are feature requests.  

Bad design is in my opinion also a bug in the design! so they are no feature
requests.
but ok I will keep all bugs (code or design) for me internal and will not
report anything more
in the future - because when you are not interested it makes no sense for
me.


Seems to be better when I only do what my employer wants me to do and
nothing more.

Greetings

    PowerStat




reply via email to

[Prev in Thread] Current Thread [Next in Thread]