Derick Rethans wrote:
> Problems:
> 1. There is no way to document the 'virtual' properties with any of
>the existing documentation tools (such as phpdoc and doxygen)
> 2. There is no way how the magic methods know if a specific 'virtual'
>property exists or not as those properties are not
I wonder if it wouldnt be enough to be able to force the triggering of
__set(), __get() for all properties be enough to deal with your situation?
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Aug 2, 2005, at 6:05 AM, Derick Rethans wrote:
Solutions:
- For problem 1. we can introduce a keyword (or use an existing
one) to define
that it is a virtual property ('abstract' or 'virtual' come to
mind). When
declaring it like this it's easy to document, and we can also
implement
Yep, it's that simple! You can even import it and it'll work! In
zend_lookup_class, the standard class_table search is done first, but on
failure, before it calls __autoload, the class name will try to be
"resolved" using the import table for the executing file. If a matching
entry in the import ta
Jesse,
another thing to consider (if you havent already) is extension support.
IOW, how do i place my extension-created class into a namespace. Is this as
simple as declaring the class name as Ns:Class ?
l0t3k
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: ht
Maybe I'm alone on this, but all my class files are named as
Classname.class.php... (hint, hint) :)
...
On second thought, maybe it would be interesting/useful to have some mechanism
to allow a formatted string like "%s.foo.php" or "foo.%s.php" to be used by
spl's autoload? Not really sure ho
Hello Marcus,
This simple change will make class imports work out of the box, which is
pretty good. What won't work out of the box are namespace imports. I think
we should provide this also (using the same logic as I'm using in
namespace_autoload.php). Even though this will complicate the default
In general, unless the extension is a really ancient forgotten thing,
the person moving it should coordinate with the current maintainer to
set that up.
Would you mind creating the appropriate package.xml file and tarball
and releasing dbx via PECL, Marc?
Let me know if you need an account for th
Hi Marcus Boerger, you wrote:
> Hello Michael,
>
> i suffest that pear finally takes a better approach with the arrival of
> namespaces then the ugly workaround of '_'.
Of course -- PEAR would benefit a lot of namespaces!
--
Michael - < mike(@)php.net >
signature.asc
Description: OpenPGP dig
Hello Michael,
i suffest that pear finally takes a better approach with the arrival of
namespaces then the ugly workaround of '_'. If pear doesn#t want to i
suggest pear simply writes it's own __autoload().
marcus
Tuesday, August 2, 2005, 6:01:18 PM, you wrote:
> Hi Jessie Hernandez, you w
Hello Jessie,
what ever you want auto-of-the-box is good. I suggest the simplest
possible way as default which is we simply stay like we are doing now and
only include a replacement from ':' to the current directory separator.
That we would be searching for '.inc' and '.inc.php' per default in t
Hello Greg,
Wednesday, August 3, 2005, 4:56:26 AM, you wrote:
> Hi,
> As for the first question of how to document virtual properties, I have
> been recommending that users do this textually inside the docblock for
> __get()/__set(). This is actually ideal in almost every case, as anyone
> u
Hiyall,
A while back ext/dbx and ext/ircg were 'moved to pecl' (without any
discussion, but that's not the point).
However, there are no packages on pecl for either extension, which might
lead people to believe that a 'move to pecl' is more like a 'remove from
php' action. Should it not be polic
On Tue, 26 Jul 2005 17:50:07 -0700
[EMAIL PROTECTED] (Andi Gutmans) wrote:
> Hi all,
>
> As planned (a tiny bit delayed), I'd like to RC1 PHP 5.1 within
> the next few days. I suggest to aim for Tuesday in a week.
> If there are any critical issues which need addressing please
> email me.
Mind t
14 matches
Mail list logo
