On November 8, 2004 12:09 am, Derick Rethans wrote:
> The machine is out of diskspace, I will fix it right now.
>
> Derick
Looks much better now, thanks ;)
Benj
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Sun, 7 Nov 2004, Benj Carson wrote:
> I'm not exactly sure if this is the place to be mentioning this, but the
> last five 5.1.x-dev tarballs on snaps.php.net are damaged. It also appears
> as if the 5.0.x-dev tarballs are also affected.
The machine is out of diskspace, I will fix it right no
Hello,
I'm not exactly sure if this is the place to be mentioning this, but the
last five 5.1.x-dev tarballs on snaps.php.net are damaged. It also appears
as if the 5.0.x-dev tarballs are also affected.
When I do tar xvjf, tar dies with an 'Unexpected EOF in archive' error.
I've attached a l
would it be doable (and more acceptable / less confusing)
if __call could only be invoked statically if the class
was abstract and vice versa only be invoked on objects
if the class was not abstract? (the idea being to make the distinction
during parsing rather than execution, allowing you to throw
In most cases method overloading is used for objects and not for classes
(for example, initiating a SOAP object and then calling methods on it.).
It doesn't make sense to mix these two things because it would lead to
confusion what context the method was called in. You would either need
another
On Sun, Nov 07, 2004 at 12:38:06PM -0600, Michael Sims wrote:
> Sean Chittenden wrote:
> > A boolean value is returned as the strings 't' and 'f', not the
> > constants true and false. This presents all kinds of interesting
> > oddities for code that does something like:
I suspect that behavior h
On Sun, 07 Nov 2004 11:59:09 -0800, Sean Chittenden wrote:
>>> *nods* It's a pretty evil behavior, IMHO. It's all too common to
>>> have
>>
>> It has been like that for ages as far as I know and plenty of code
>> relies on it, so it can't be changed really.
>
> Better late than never. I've g
Brad,
Thank you for the useful link. Since our extensions are basically "loadable
modules" in OSX parlance, it should be safe to make PHP_SHLIB_SUFFIX = .so
there, right? I'd really like to go ahead and do it.
-Andrei
> -Original Message-
> From: Brad House [mailto:[EMAIL PROTECTED]
> Se
*nods* It's a pretty evil behavior, IMHO. It's all too common to
have
It has been like that for ages as far as I know and plenty of code
relies on it, so it can't be changed really.
Better late than never. I've got a ton of code depending on it too,
but believe me when I say doing:
find . -t
Sean Chittenden wrote:
*nods* It's a pretty evil behavior, IMHO. It's all too common to have
It has been like that for ages as far as I know and plenty of code
relies on it, so it can't be changed really.
100K lines of web goo. *sighs* Moved a large database schema from INTs
to BOOLs, and u
A boolean value is returned as the strings 't' and 'f', not the
constants true and false. This presents all kinds of interesting
oddities for code that does something like:
[...]
You're probably already aware of this, but you can use a bit(1) field
as a
boolean and this will map to PHP values tha
Sean Chittenden wrote:
> A boolean value is returned as the strings 't' and 'f', not the
> constants true and false. This presents all kinds of interesting
> oddities for code that does something like:
[...]
You're probably already aware of this, but you can use a bit(1) field as a
boolean and th
Timm Friebe wrote:
> is there any reason why __call shouldn't be invoked for static method
> calls?
None that I can think of. If it is doable it should be supported.
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5
Hi,
is there any reason why __call shouldn't be invoked for static method
calls?
Reproduce
-
php5 -r 'class A { function __call($name, $args) { var_dump($name,
$args); } } A::foo();'
Actual result
-
Fatal error: Call to undefined method A::foo() in Command line code on
line 1
Hi,
ok since tomorrow evening will be the speakers dinner decided to hold
the pdo meeting on tuesday evening at 21:00 CET (I hope that works for
you andi). We can probably do the meeting on efnet. Meeting place will
be #php.pdo. Beyond that I dont know what we can provide in terms of
audio. I brou
15 matches
Mail list logo
