Re: [PHP-DOC] PhD class renamings
On Tue, Jun 16, 2009 at 07:47, Christian Weiskecwei...@cweiske.de wrote: Hi Bjori, The directory structure is compatible with the intheworks namespace naming convention cs, right? (Meaning if we move to namespaces no change is needed) No. The new namespace convention would mean that - if we chose phd as namespace (note, lowercase!), the directory wouldn't be PhD/ but phd/. can't the module root (/phd) be the first level directory? /phd/phd/ and/or /phd/PhD/ is confusing and ugly :] But that is the only difference? Shame we loose the history... but this needs to be done We don't - philip wants to get someone to move them on the server, preserving history. Ouh, cool. (sorry for top-posting in the last reply, blame the gmail app on my new awesome HTC Magic *brag*) :P -Hannes
Re: [PHP-DOC] Conforming documentation style - how to document classes
On Mon, Jun 15, 2009 at 19:26, Philip Olsonphi...@roshambo.org wrote: On Jun 15, 2009, at 1:18 AM, G. T. Stresen-Reuter wrote: Is there an exemplary class definition in the existing documentation I could use as a foundation for fixing the structure of the Tidy classes (and other classes that I periodically run across with odd structure)? Do you feel like determining what might work best? I really like what Jakup did with the ext/datetime docs. -Hannes
Re: [PHP-DOC] Re: Enterprise classes
On Mon, Jun 15, 2009 at 19:48, Moacir de Oliveiramoacirdeoliveira@gmail.com wrote: Hi Christian 2009/6/15 Christian Weiske cwei...@cweiske.de Do I assume correctly that files like include/PhDEnterpriseReader.class.php are meant to replace include/PhDReader.class.php? The classes PhDReader and PhDFormat still there just for compatibility with the themes, and now are deprecated. I don't think is a good idea remove them now. The idea is write packages that will adapt the old themes to the enterprise formats. So it is to hard to try to merge these things in the first iteration? You'd like to keep some sort of backwards compatibility layer until someone has the time to upgrade the legacy themes? -Hannes
Re: [PHP-DOC] PhD class renamings
On Tue, Jun 16, 2009 at 10:09, Christian Weiskecwei...@cweiske.de wrote:
Hallo Hannes,
The directory structure is compatible with the intheworks namespace naming
convention cs, right?
(Meaning if we move to namespaces no change is needed)
No. The new namespace convention would mean that - if we chose phd as
namespace (note, lowercase!), the directory wouldn't be PhD/ but phd/.
can't the module root (/phd) be the first level directory?
/phd/phd/ and/or /phd/PhD/ is confusing and ugly :]
No, that does not work well. Having the module directory (phd) as the first
level dir would require anyone to checkout as phd/, but would not work
anymore for checkouts in directories like phd_0_4. For the autoloader to work
best - and easiest - a root PhD/ is required because then you can just
str_replace('_', '/', $class) . '.php'
and have the file name. If PhD/ wasn't there in cvs, it would still work as
described when installed - but not from cvs.
Fair enough
But that is the only difference?
Yes.
I don't see any explicit mention of the vendor directory must being
lowercase (although all examples are lowercased)..
But ok, then I prefer to use 'phd' and make dirty autoload workaround
until we move to namespaces.
..actually.
That will make the namespace name 'phd\PhD\', 'phd\PhD\Reader',
'phd\PhD\Package\PEAR' ?
That looks funny.
-Hannes
Re: [PHP-DOC] PhD class renamings
Hi Hannes, But that is the only difference? Yes. I don't see any explicit mention of the vendor directory must being lowercase (although all examples are lowercased).. That was consensus - lowercasity is to distinguish between normal directories (i.e. class dirs) and namespace dirs - at least in the PEAR2 standards. But ok, then I prefer to use 'phd' and make dirty autoload workaround until we move to namespaces. ..actually. That will make the namespace name 'phd\PhD\', 'phd\PhD\Reader', 'phd\PhD\Package\PEAR' ? No. When we use namespaces, we don't need the PhD class prefix anymore. So without namespaces: PhD_Package_PEAR_Web with namespace: phd\Package_PEAR_Web -- Regards/Mit freundlichen Grüßen Christian Weiske
Re: [PHP-DOC] PhD class renamings
On Jun 16, 2009, at 1:34 AM, Christian Weiske wrote: Hi Hannes, But that is the only difference? Yes. I don't see any explicit mention of the vendor directory must being lowercase (although all examples are lowercased).. That was consensus - lowercasity is to distinguish between normal directories (i.e. class dirs) and namespace dirs - at least in the PEAR2 standards. But ok, then I prefer to use 'phd' and make dirty autoload workaround until we move to namespaces. ..actually. That will make the namespace name 'phd\PhD\', 'phd\PhD\Reader', 'phd\PhD\Package\PEAR' ? No. When we use namespaces, we don't need the PhD class prefix anymore. So without namespaces: PhD_Package_PEAR_Web with namespace: phd\Package_PEAR_Web How about using namespaces now? For PhD HEAD. PHP 5.3 is the future, so let's get onboard. :) Regards, Philip
Re: [PHP-DOC] PhD class renamings
On Tue, Jun 16, 2009 at 16:10, Philip Olsonphi...@roshambo.org wrote: On Jun 16, 2009, at 1:34 AM, Christian Weiske wrote: Hi Hannes, But that is the only difference? Yes. I don't see any explicit mention of the vendor directory must being lowercase (although all examples are lowercased).. That was consensus - lowercasity is to distinguish between normal directories (i.e. class dirs) and namespace dirs - at least in the PEAR2 standards. But ok, then I prefer to use 'phd' and make dirty autoload workaround until we move to namespaces. ..actually. That will make the namespace name 'phd\PhD\', 'phd\PhD\Reader', 'phd\PhD\Package\PEAR' ? No. When we use namespaces, we don't need the PhD class prefix anymore. So without namespaces: PhD_Package_PEAR_Web with namespace: phd\Package_PEAR_Web How about using namespaces now? For PhD HEAD. PHP 5.3 is the future, so let's get onboard. :) Well, if someone wants to do the work.. feel free :D -Hannes
[PHP-DOC] phd install problems
My coworker is trying to install phd following the directions at http://wiki.php.net/doc/scratchpad/howto but it says: pear install doc.php.net/phd-beta phpdocs/PhD requires PHP extension xmlreader phpdocs/PhD requires PHP extension dom phpdocs/PhD can optionally use PHP extension haru No valid packages found install failed So he tried 'pecl install xmlreader' and got a strange compile error: gcc -I. -I/tmp/pear/download/xmlreader-1.0.1 -DPHP_ATOM_INC -I/var/tmp/pear-build-root/xmlreader-1.0.1/include -I/var/tmp/pear-build-root/xmlreader-1.0.1/main -I/tmp/pear/download/xmlreader-1.0.1 -I/usr/include/php -I/usr/include/php/main -I/usr/include/php/TSRM -I/usr/include/php/Zend -I/usr/include/php/ext -I/usr/include/php/ext/date/lib -I/usr/include/libxml2 -DHAVE_CONFIG_H -g -O2 -c /tmp/pear/download/xmlreader-1.0.1/php_xmlreader.c -fPIC -DPIC -o .libs/php_xmlreader.o /tmp/pear/download/xmlreader-1.0.1/php_xmlreader.c: In function 'xmlreader_objects_new': /tmp/pear/download/xmlreader-1.0.1/php_xmlreader.c:349: error: 'zend_object' has no member named 'in_get' /tmp/pear/download/xmlreader-1.0.1/php_xmlreader.c:350: error: 'zend_object' has no member named 'in_set' make: *** [php_xmlreader.lo] Error 1 ERROR: `make' failed We're using php 5.2.6 (configure flags listed at http://mongodb.pastebin.com/d9886fbe). Anyone know what's going on? It looks like xmlreader shouldn't even be a dependency for phd, as it's built into the main source now.
Re: [PHP-DOC] phd install problems
Hello Kristina, Anyone know what's going on? It looks like xmlreader shouldn't even be a dependency for phd, as it's built into the main source now. It is a dependency because PEAR automatically checks if it's enabled - be it in the core or as an extra module. So please recompile your php with the necessary extensions. -- Regards/Mit freundlichen Grüßen Christian Weiske -= Geeking around in the name of science since 1982 =- signature.asc Description: PGP signature
Re: [PHP-DOC] Conforming documentation style - how to document classes
On Jun 15, 2009, at 6:26 PM, Philip Olson wrote: On Jun 15, 2009, at 1:18 AM, G. T. Stresen-Reuter wrote: Hi, I'm not a big contributor (in fact, haven't done much more than test PhD and send some feedback) but I do work with the raw documentation quite a bit. I've found some apparent irregularities in how classes are documented. For example, the tidy.html has both procedural and OO versions of the function. The procedural version follows the convention found in other function definitions but the OO version seems to be missing the CLASSSYNOPSIS, OOCLASS, etc. elements thus there is no way to select just the OO methods. Is there an exemplary class definition in the existing documentation I could use as a foundation for fixing the structure of the Tidy classes (and other classes that I periodically run across with odd structure)? Greetings Ted, Do you feel like determining what might work best? He he he... no! There does seem to be some consensus among class definitions so, keep reading... On Jun 16, 2009, at 9:06 AM, Hannes Magnusson wrote: I really like what Jakup did with the ext/datetime docs. I simply don't know enough about programming and DocBook to be able to opine with any authority. I'll leave the decision on what format to follow to the experts and do my best to implement whatever decision is made. (and FWIW, I recently discovered http://www.php.net/manual/en/extensions.php and have simply stopped using the other categorizations as I find it hard to determine what category the function I'm looking for will be in) This could begin the process of knowing. Let's list all OOP +Procedural API extensions then determine the differences, and use one syntax. This may or may not be a complete list (likely not, but close): - Date/datetime (toc has both) - Dir (toc has both (sort of)) - DOM (not really, but domxml is procedural) - Fileinfo (toc is procedural) - Intl (toc is oop) - MaxDB (toc is procedural) - MySQLi (toc is oop) - SQLite (toc is procedural) - Tidy (???) - XMLWriter (toc is oop) While some were Procedural but are now OOP (so they differ): - Imagick (procedural api not listed (which seems fine, as it's dead/ old)) - Tidy? (???) - Zip (partial procedural exists for BC, needs clearer definition of difference) Unsure how to classify some: - Rar (appears to use both together (weird)) - SimpleXML (not sure why the procedural exists...) This list is more than big enough to start. It can always be added to! Summary: - We do it differently per extension, so are inconsistent - The TOC for these also differ (lists OOP and/or Procedural) - This is a problem Notes: - Eludes to it: http://cvs.php.net/viewvc.cgi/phpdoc/RFC/skeletons/method.xml - Docgen commit to handle it: http://news.php.net/php.doc.cvs/3884 So, if I understand the purpose of docgen, maybe we could start with skeleton functions and classes in PHP and use them to create the skeletons for the documentation? Ted PS: Should I be cc'ing people in addition to replying to the list? Personally I prefer to receive only one email per thread.
Re: [PHP-DOC] phd install problems
I compiled from source and worked fine, thank you. On Tue, Jun 16, 2009 at 12:52 PM, Christian Weiskecwei...@cweiske.de wrote: Hello Kristina, Anyone know what's going on? It looks like xmlreader shouldn't even be a dependency for phd, as it's built into the main source now. It is a dependency because PEAR automatically checks if it's enabled - be it in the core or as an extra module. So please recompile your php with the necessary extensions. -- Regards/Mit freundlichen Grüßen Christian Weiske -= Geeking around in the name of science since 1982 =-
