Shouldn't PHP suppress this warning then? Right now 3 warnings are shown for
just one bad statement. I think one warning would suffice. Of course this is
all rather unimportant and very low-priority, but I still think it's a
situation that could be improved.
You can see the warnings at http://bugs
On 2.8.2005 10:16 Uhr, Ron Korving wrote:
> Shouldn't PHP suppress this warning then? Right now 3 warnings are shown for
> just one bad statement. I think one warning would suffice. Of course this is
> all rather unimportant and very low-priority, but I still think it's a
> situation that could b
The 5.1 error handling looks very promising. For me personally, the 3
warnings are no problem. I want to suppress all 3 of them (so I don't really
care if I suppress 1 or 3 and I don't really care how these warnings are
formatted). But I figured what goes for me, doesn't necessarily go for the
rest
This sounds awesome. Good job, Jessie. Keep it up!
- David
> -Original Message-
> From: Jessie Hernandez [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 02, 2005 6:07 AM
> To: internals@lists.php.net
> Subject: [PHP-DEV] [PATCH] Namespace Patch, Beta 1
>
> Attached is the latest versi
Jessie Hernandez wrote:
Attached is the latest version of the namespace patch! It finally includes
namespace imports and it even includes anonymous namespace support. Also,
the previous bison shift/reduce conflict has been removed. Here is a
summary of its features:
- Simple imports: import ns:
On 2.8.2005 10:16 Uhr, Ron Korving wrote:
Shouldn't PHP suppress this warning then? Right now 3 warnings are shown
for
just one bad statement. I think one warning would suffice. Of course this
is
all rather unimportant and very low-priority, but I still think it's a
situation that could be impr
Hello!
we're finding some problems with property overloading (__get() and
__set()). Here is an RFC describing what we'd like to see changed.
Please comment on this.
Introduction:
PHP currently supports property overloading with the magic functions __get()
and __set(). Those methods are called
Column numbers in errors are not yet implemented everywhere in libxml
and 0 is often returned.
Rob
Nuno Lopes wrote:
The most interesting example is at http://php.net/libxml_get_errors
But while I was reading again the example I wrote, I found that libxml
always returns column 0:
Th
Derick Rethans wrote:
Hello!
we're finding some problems with property overloading (__get() and
__set()). Here is an RFC describing what we'd like to see changed.
Please comment on this.
Introduction:
PHP currently supports property overloading with the magic functions __get()
and __set().
Hello,
With my application that uses heavily inherent classes, sometimes I
get the following message:
PHP Fatal error: Call to undefined method Rank::_construtor() in
.../inc/Links.class.php. It works with php
4.x when I use the old style of constructor calling
$this->(
On Tue, Aug 02, 2005 at 03:42:00PM +0100, Meno Abels wrote:
> Hello,
>
> With my application that uses heavily inherent classes, sometimes I
> get the following message:
> PHP Fatal error: Call to undefined method Rank::_construtor() in
> .../inc/Links.class.php. It work
"John LeSueur" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> >
> so, if I understand correctly, if your __autoload is defined in a
> different file(file1) from where the import was
> called(file2), then get_imported_namespaces() returns the namespace
> imports for file1.
> get_impo
Forgot to mention, since I expect the majority of users to follow the PEAR
convention for their classes (basically one class per file, file is named
like class, with "namespace" directories), then maybe a default
implementation can be provided in SPL's autoload. That way, namespace
imports can be u
Hi Jessie Hernandez, you wrote:
> Forgot to mention, since I expect the majority of users to follow the PEAR
> convention for their classes (basically one class per file, file is named
> like class, with "namespace" directories)
With the minor but essential logical difference:
$file = str
Hi Michael,
Yes, I am aware of this. Underscores were used due to the lack of
namespaces. For user classes which use namespaces (and in the case where
some PEAR classes get modified to be under namespaces), the colon would be
used as the separator, and this would get replaced by the slash to form
OK thanks for the info. I'll add that to the documentation.
Nuno
- Original Message -
Column numbers in errors are not yet implemented everywhere in libxml
and 0 is often returned.
Rob
Nuno Lopes wrote:
The most interesting example is at http://php.net/libxml_get_errors
But while
thienvk
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
FYI, I haven't had a chance to look at this patch yet (nor a lot of the
emails on the subject). After PHP 5.1 goes RC and we start our Unicode
work, I should have time to look into it. Interesting to see if it
addresses the issues we had in the past. I think some of them weren't
solvable althou
Derick Rethans wrote:
class. The magic methods are responsibly for:
- checking if the property actually "exists"
This is something I wouldn't encourage as one of the virtues of fully
dynamic languages is the "lack" of checking this. Otherwise what happens
if e.g. one inherits such a class to
>> I can clearly set the PHP_INI_SYSTEM option in the httpd.conf.
>> As stated in http://php.net/configuration.changes you should use the
>> 'php_admin_xx' directive instead of 'php_xx'.
>
> *cough*
> Yes, you're right.
> Sorry for the noise.
So since Sean misunderstood something, this might be a
Hmm, it looks like that the include_path value is limited to a specific
size under FreeBSD. Anyone know if this, right?
--
Yours,
Weyert de Boer ([EMAIL PROTECTED])
innerfuse*
http://www.innerfuse.biz/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www
My concern with the self::isVirtual() syntax would be...
class Base {
function __get($name) {
if (!self::isVirtual($name))
throw;
}
}
class Foo {
abstract public $bar = 1;
}
$f = new Foo;
echo $f->bar;
... Are these 'virtual' members going to work like static me
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
using __get()/__set() for finite, concrete properties should almost
defin
I missed one...Index: sapi/cgi/cgi_main.c
===
RCS file: /repository/php-src/sapi/cgi/cgi_main.c,v
retrieving revision 1.266
diff -u -r1.266 cgi_main.c
--- sapi/cgi/cgi_main.c 16 Jun 2005 14:54:51 - 1.266
+++ sapi/cgi/cgi_main.
24 matches
Mail list logo
