Other possibility:
The PEAR package "PHP_UML" can parse PHP files/folders, and generate the API
in the form of a global standard XML file (and/or in the form of a full
XHTML documentation).
Namespaced code is supported.
But the parsed code must be object oriented, not procedural (for now).
Perhaps
22/05, and
once before, at the very beginning of May, with a different email though;
anyway, this no longer matters now).
Baptiste
-Original Message-
From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]
Sent: mercredi 11 juin 2008 22:15
To: Antony Dovgal
Cc: Baptiste Autin; internals@lis
a Docbook documentation about it, so I must have
a CVS account. I guess that the PEAR group will then give me the write
privilege on the relevant folder.
Could you please create my account?
If you cannot, or don't want, please tell me why!
Thank you,
Baptiste Autin
PEAR login: bap
Making a first release of the PEAR package "PHP_UML", which has been accepted
by the PEAR community recently.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
"clearly demonstrates" ??
Baptiste Autin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I know well the sacred "loose typing" anthem, but is there any hope to see
the class properties type hinted one day? (and the return value as well)
I mean, as an OPTION, as it is already done with function parameters...
Class A {
}
Class B {
public A $a;
}
Because:
1. It is so strange to se
?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Etienne
Kneuss
Sent: jeudi 27 septembre 2007 01:11
To: Baptiste Autin
Cc: Stanislav Malyshev; Zoe Slattery; Dmitry Stogov; Marcus Boerger; Lukas
Kahwe Smith; Michael Lively; internals@lists.php.net; Andi
>People generally prefer compile-time
>control which is derived from definition rather than per-instance
>runtime control (implementing interface vs. checking each time if class
>has certain methods).
It's me again, sorry.
So, if I understand you well, Stanislas, you are personally not much int
>If you mean Client's $structure, the you have to use static::$structure
>and it should work. However it's quite a bad design here since you have
>no way to ensure class inheriting from Entity would have $structure.
Couldn't I write: isset(static::$structure) ?
BTW, sorry for my recent vulgar
>It's becoming messy now - we now need to start to invent all kinds of
>complex propagation rules for it in parallel with the true object
>propagation rules. Why not just have an object then?
Because if you could only see the incredible number of "get_class($this)"
and of "if(__CLASS__!=get_class(
>__CLASS__ returns name of the class, get_parent_class() is the name of
>parent class, those are entirely different things, nothing to do with
>compiler/run time. Class always has one name and one parent or none.
Sorry, I meant:
__CLASS__
and
get_class($this)
They are both different things, and
e is an
ambiguity upon what you consider as your reference, when you write something
like parent::$structure.
There relies the problem; it's not a question of static or not static. The
problem just frequently occurs with static variables.
Anyway, I do agree with Stanislav when he writes
12 matches
Mail list logo
