Re: [PHP-DEV] is this a bug?
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.php.net/bug.php?id=33951 Ron "Rob Richards" <[EMAIL PROTECTED]> schreef in bericht news:[EMAIL PROTECTED] > The warning is being issued from libxml and the URL (which it encodes > internally) is just there to inform you that it had problems dealing > with the external entitity. Either surpress the errors when calling > whichever function or you can use the new error handling for xml in 5.1 > which wont issue/display errors directly but any can be retrieved after > the function call. > > Rob > > Ron Korving wrote: > > >Yes, spaces are illegal.. Thing is though, the output of the warning has > >nothing to do with urls (unless it just assumes the stream is always from a > >remote source or something). > > > >I'll post a bugreport. > > > >Ron > > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is this a bug?
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 improved. > > You can see the warnings at http://bugs.php.net/bug.php?id=33951 AFAICS these are all libxml2 warnings. We would have to start intercepting those warnings and decide which one we want to show and which not... Too much hassle IMHO. In your scenario, which should be shown? And with the new libxml error handler code in PHP 5.1, the developer can decide, what he wants to show and what not... See http://www.php.net/libxml_use_internal_errors and http://php5.bitflux.org/xml5_1/slide_13.php for some explenation and examples chregu > Ron > > "Rob Richards" <[EMAIL PROTECTED]> schreef in bericht > news:[EMAIL PROTECTED] > >>The warning is being issued from libxml and the URL (which it encodes >>internally) is just there to inform you that it had problems dealing >>with the external entitity. Either surpress the errors when calling >>whichever function or you can use the new error handling for xml in 5.1 >>which wont issue/display errors directly but any can be retrieved after >>the function call. >> >>Rob >> >>Ron Korving wrote: >> >> >>>Yes, spaces are illegal.. Thing is though, the output of the warning has >>>nothing to do with urls (unless it just assumes the stream is always from > > a > >>>remote source or something). >>> >>>I'll post a bugreport. >>> >>>Ron >>> >>> > > -- christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 http://www.bitflux.ch | [EMAIL PROTECTED] | gnupg-keyid 0x5CE1DECB -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is this a bug?
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 of the world. Besides that, don't we all want to see PHP become better and better? :) Of the 3 warnings: (1) Warning: I/O warning : failed to load external entity "/non%20existant%20file.xsd" in /www/admin/dev/bugreports/dom-validate/index.php on line 4 (2) Warning: xmlSchemaParse: could not load '/non existant file.xsd'. in /www/admin/dev/bugreports/dom-validate/index.php on line 4 (3) Warning: Invalid Schema in /www/admin/dev/bugreports/dom-validate/index.php on line 4 I would prefer to just see warning of the highest level (3), but it does lack the information that says the actual XSD-file is missing. Again, for me personally, this requires no fix. Ron "Christian Stocker" <[EMAIL PROTECTED]> schreef in bericht news:[EMAIL PROTECTED] > > > 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 improved. > > > > You can see the warnings at http://bugs.php.net/bug.php?id=33951 > > AFAICS these are all libxml2 warnings. We would have to start > intercepting those warnings and decide which one we want to show and > which not... Too much hassle IMHO. In your scenario, which should be shown? > > And with the new libxml error handler code in PHP 5.1, the developer can > decide, what he wants to show and what not... See > http://www.php.net/libxml_use_internal_errors > and > http://php5.bitflux.org/xml5_1/slide_13.php > for some explenation and examples > > chregu > > > Ron > > > > "Rob Richards" <[EMAIL PROTECTED]> schreef in bericht > > news:[EMAIL PROTECTED] > > > >>The warning is being issued from libxml and the URL (which it encodes > >>internally) is just there to inform you that it had problems dealing > >>with the external entitity. Either surpress the errors when calling > >>whichever function or you can use the new error handling for xml in 5.1 > >>which wont issue/display errors directly but any can be retrieved after > >>the function call. > >> > >>Rob > >> > >>Ron Korving wrote: > >> > >> > >>>Yes, spaces are illegal.. Thing is though, the output of the warning has > >>>nothing to do with urls (unless it just assumes the stream is always from > > > > a > > > >>>remote source or something). > >>> > >>>I'll post a bugreport. > >>> > >>>Ron > >>> > >>> > > > > > > -- > christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich > phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 > http://www.bitflux.ch | [EMAIL PROTECTED] | gnupg-keyid 0x5CE1DECB -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PATCH] Namespace Patch, Beta 1
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 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:class1;
> - Import aliases: import ns:class1 as my_alias;
> - Namespace imports: import namespace ns;
> - Anonymous namespaces: namespace { class file_class{} }
> - Namespace-private classes: namespace ns{ private class prv_class{} }
>
> Two new functions have also been added to support namespace imports (more
> on
> that below):
>
> - get_imported_namespaces([$className])
> Returns an array of imported namespaces for the current file. If a class
> name is passed, and this class is currently being autoloaded (also meaning
> that this function is called inside __autoload), then the list of returned
> imported namespaces is based on the file that triggered the __autoload
> call.
>
> - autoload_import_class($className, $namespaceName)
> Imports a class in a given namespace for the currently executing file (can
> ONLY be used inside __autoload!)
>
> Imports
> ---
> Imports and namespace imports are handled completely by the user with the
> use of the __autloload function. This means that there are no restrictions
> on class file naming/directory structure. For simple imports, the class
> name will be passed with its full name (including the colons, such as
> "ns:class1"). For namespace imports, only the class name will be called.
> Since the user needs to determine which namespace (or namespaces) a class
> belongs to, the "get_imported_namespaces" function is provided to check
> the
> imported namespaces for the currently-executing file. Once the user is
> satisfied with a match, he/she needs to perform an "import" for this
> class,
> but this needs to be done on the executing file, not the file where
> __autoload is defined. For this reason, the autoload_import_class function
> is provided. A sample usage of both these functions is at
> tests/classes/namespace_autoload.php.
>
> Namespace-private classes
> -
> Classes marked as "private" from within a namespace can only be used by
> classes defined in the same namespace.
>
> Anonymous namespaces
>
> Classes defined inside anonymous namespaces can only be used within the
> file
> that declared the anonymous namespace.
>
>
> I believe the attached patch solves the issues that were presented long
> ago
> for namespaces. Referring to the post by Daniel Cogwill at
> http://www.zend.com/lists/engine2/200304/msg00164.html, the following are
> my answers to the problems he found at the time:
>
> 1) import-all silently hides local names.
> A: If a global class is defined with the same name as a class in a
> namespace, and the namespace class has been imported in the same script,
> the global class takes precedence. The namespace class can still be used
> by
> using its full name, i.e. namespace_name:class_name.
>
> 2) Interestingly (and I assume this is simply a bug), functions and
> classes
> behave differently wrt to import-all and duplicate definitions.
> A: Irrelevant in this patch.
>
> 3) There is no way to hide names from import (i.e. make a name
> non-exportable). This is a fundamental namespace feature, and there is
> already an appropriate keyword (private).
> A: Namespace-private classes are supported, using the "private" keyword.
>
> 4) The semantic meaning of successive imports depends on their relative
> ordering.
> A: The engine does not attempt to determine which class is included, the
> user decides the most appropriate behavior inside __autoload.
>
> 5) The most egregious issue is that an import in an included file affects
> the scope of the including file.
> A: Imports in this patch only affect the file they are in.
>
>
> Since I could not find a way to add the tests/classes/namespace directory
> and subdirectories, I zipped them separately, as before.
>
> Let me know if you have any questions on the attached patch.
>
>
> Best regards,
>
> Jessie Hernandez
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Namespace Patch, Beta 1
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:class1;
- Import aliases: import ns:class1 as my_alias;
- Namespace imports: import namespace ns;
- Anonymous namespaces: namespace { class file_class{} }
- Namespace-private classes: namespace ns{ private class prv_class{} }
Two new functions have also been added to support namespace imports (more on
that below):
- get_imported_namespaces([$className])
Returns an array of imported namespaces for the current file. If a class
name is passed, and this class is currently being autoloaded (also meaning
that this function is called inside __autoload), then the list of returned
imported namespaces is based on the file that triggered the __autoload
call.
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_imported_namespaces($className) would return for file2, and outside
of the __autoload function,
get_imported_namespaces($className) would return the namespaces for
file1. That seems like
complicated semantics. Is there some way this could be simplified? Maybe
there should be two functions,
one that returns namespaces for file2 and is incorrect(throws an error)
to call from anywhere other than
__autoload(), and one that returns namespaces for file2.
- autoload_import_class($className, $namespaceName)
Imports a class in a given namespace for the currently executing file (can
ONLY be used inside __autoload!)
Imports
---
Imports and namespace imports are handled completely by the user with the
use of the __autloload function. This means that there are no restrictions
on class file naming/directory structure. For simple imports, the class
name will be passed with its full name (including the colons, such as
"ns:class1"). For namespace imports, only the class name will be called.
Since the user needs to determine which namespace (or namespaces) a class
belongs to, the "get_imported_namespaces" function is provided to check the
imported namespaces for the currently-executing file. Once the user is
satisfied with a match, he/she needs to perform an "import" for this class,
This seems like it would be slow, as the user might have many
namespaces(directories) to search for matching
files. This would of course be up to the user. And it doesn't bother me
that a full namespace import
may not be as fast as a more specific import. In development it might be
convenient, but at some point, it's not
that big a deal to specify the classes you use.
but this needs to be done on the executing file, not the file where
__autoload is defined. For this reason, the autoload_import_class function
is provided. A sample usage of both these functions is at
tests/classes/namespace_autoload.php.
I like the option of having namespaces, and from the description this
seems to be a light method of doing it. It does
require some effort from the user. It seems that for most cases
__autoload will be the same every time, maybe with
different paths or file naming conventions.
John
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is this a bug?
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 improved.
You can see the warnings at http://bugs.php.net/bug.php?id=33951
AFAICS these are all libxml2 warnings. We would have to start
intercepting those warnings and decide which one we want to show and
which not... Too much hassle IMHO. In your scenario, which should be
shown?
And with the new libxml error handler code in PHP 5.1, the developer can
decide, what he wants to show and what not... See
http://www.php.net/libxml_use_internal_errors
and
http://php5.bitflux.org/xml5_1/slide_13.php
for some explenation and examples
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:
PHP: Behind the Parser
XML;
$doc = simplexml_load_string($xmlstr);
$xml = explode("\n", $xmlstr);
print_r(libxml_get_errors());
?>
Array
(
[0] => LibXMLError Object
(
[level] => 3
[code] => 76
[column] => 0
[message] => Opening and ending tag mismatch: titles line 2 and
title
[file] =>
[line] => 2
)
[1] => LibXMLError Object
(
[level] => 3
[code] => 76
[column] => 0
[message] => Opening and ending tag mismatch: movie line 2 and
mdovie
[file] =>
[line] => 2
)
)
This seems to be a bug to me, or the column stuff will only work when
validating with a dtd/..?
Nuno
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Property Overloading RFC
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 when the code "echo $object->a" or
"$object->a = 42" are executed and the property "a" is not declared in the
class. The magic methods are responsibly for:
- checking if the property actually "exists"
- setting the value or returning the value depending on the action
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 declared usually - unless you
define an array with property names as a class constant (which is not
allowed either).
3. There is no way for the magic methods to return a meaningfull error when a
property doesn't "exist". Of course it is possible to throw an error with
"trigger_error" or "throw" in case a property doesn't "exist" in a specific
class, but the file and line numbers would not match the actually get/set
action. debug_backtrace() can be used to retrieve the correct file and line,
but as you have to do this for every class where you want to use setters and
getters *and* you have to implement your own error message rendering
function this is not really a suitable option either.
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
visibility for those virtual properties. Marcus already has a patch for
this somewhere, which uses the "abstract" keyword for this purpose:
- In combination to the introduced keyword we need an easy way to check if a
passed property name is declared in the class as 'virtual'. Currently (with
the 'abstract' keyword properly implemented) you'd have to do:
isAbstract() ) {
/* throw error */
}
} catch ($e) {
/* throw error */
}
}
}
$b = new Base();
echo $b->foo;
?>
This is ofcourse overly complicated. A better workable solution would be -
without breaking BC (suggestions for syntax here are very welcome):
foo;
?>
- Problem 3 can be solved by:
* allowing optional by-ref parameters to the __set
and __get function, so that their signatures become:
function __set($name, $value [, &$error] )
function __get($name [, &$error] )
If the parameter is not given things behave just like they do now ->
__set
and __get can not throw meaningful errors with the correct file/line of
the
conflicting statement
If the parameter is used in the function's declaration and is set to
"false" when the __set or __get function returns, the engine can throw
an
error on the assignment line with the correct file/line combination. If
it's set to "true" (or "null") then the engine should not throw any
error.
* Use a different __set and __get function for 'abstract' properties, then
the engine can already determine if you're doing something wrong before
executing the __set and __get methods.
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is this a bug?
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: This seems to be a bug to me, or the column stuff will only work when validating with a dtd/..? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Property Overloading RFC
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(). Those methods are called when the code "echo $object->a" or
"$object->a = 42" are executed and the property "a" is not declared in the
class. The magic methods are responsibly for:
- checking if the property actually "exists"
- setting the value or returning the value depending on the action
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 declared usually - unless you
define an array with property names as a class constant (which is not
allowed either).
3. There is no way for the magic methods to return a meaningfull error when a
property doesn't "exist". Of course it is possible to throw an error with
"trigger_error" or "throw" in case a property doesn't "exist" in a specific
class, but the file and line numbers would not match the actually get/set
action. debug_backtrace() can be used to retrieve the correct file and line,
but as you have to do this for every class where you want to use setters and
getters *and* you have to implement your own error message rendering
function this is not really a suitable option either.
what about:
Features:
1) Easy way to document properties
2) No BC break with code relies on __get, __set
Clases GetSet0, GetSet1 and GetSet2 are equivalent and third class
GetSet3 use different methods to handle $x property;
There is a nice way to declare reaonly properties
property $x { getMethod }
or
property $x { getMethod, null }
and writeonly propeties :)
property $x { null, setMethod }
If someone touch undeclared property and class don't have __get/__set
Zend engine can raise exception ... It's good way? I don't know.
--
Ondrej Ivanic
([EMAIL PROTECTED])
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] parent::construct not reliable working on php5.1 b2/b3
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->(CLASSNAME) . But when working with php 5.2 b2 or b3 in the old OR the new style, I get the PHP Fatal error from above. Is there any hints to look at this problem? regards meno -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] parent::construct not reliable working on php5.1 b2/b3
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 works with php > 4.x when I use the old style of constructor calling > $this->(CLASSNAME) . But when working with php 5.2 b2 or b3 in the old > OR the new style, I get the PHP Fatal error from above. > Is there any hints to look at this problem? Why do you call _construct instead of __construct? And how do you do it? Did you read everything at http://php.net/construct (including Note)? What about php 5.0? -- Paweł Bernat; uselessness' lover; select''as email; Slowly and surely the unix crept up on the Nintendo user ... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Namespace Patch, Beta 1
"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_imported_namespaces($className) would return for file2, and outside > of the __autoload function, > get_imported_namespaces($className) would return the namespaces for > file1. That seems like > complicated semantics. Is there some way this could be simplified? Maybe > there should be two functions, > one that returns namespaces for file2 and is incorrect(throws an error) > to call from anywhere other than > __autoload(), and one that returns namespaces for file2. > To clarify the usage of this function (using your same example of file1 and file2): - get_imported_namespaces() can be called in any file. It will return the namespace imports for the currently-executing file (whether it's file1 or file2). - When inside __autoload, get_imported_namespaces($className) will return the namespace imports for the file that triggered the __autoload call (in this case, file2). - When not inside __autoload, get_imported_namespaces($className) will return an empty array. I don't think the above usage is complicated. The only thing that can be changed is the behavior of get_imported_namespaces($className) when not inside __autoload. Right now it's returning an empty array. Will it be better to return false and/or generate an error? > >Imports > >--- > >Imports and namespace imports are handled completely by the user with the > >use of the __autloload function. This means that there are no restrictions > >on class file naming/directory structure. For simple imports, the class > >name will be passed with its full name (including the colons, such as > >"ns:class1"). For namespace imports, only the class name will be called. > >Since the user needs to determine which namespace (or namespaces) a class > >belongs to, the "get_imported_namespaces" function is provided to check the > >imported namespaces for the currently-executing file. Once the user is > >satisfied with a match, he/she needs to perform an "import" for this class, > > > > > This seems like it would be slow, as the user might have many > namespaces(directories) to search for matching > files. This would of course be up to the user. And it doesn't bother me > that a full namespace import > may not be as fast as a more specific import. In development it might be > convenient, but at some point, it's not > that big a deal to specify the classes you use. > This same search would have to be done by the engine, and although a bit faster, this could also be slow depending on the number of imported namespaces. Also, if the search is done by the engine, then a file structure/naming convention would have to be enforced (that's why I had the class_path .ini variable before), and some already mentioned that they have different conventions, hence we need to provide flexibility to the user. I agree with you that it's not a big deal to be explicit in specifying which classes will be imported (in fact, when I have to write a Java class at work, I always specify each class one-by-one, regardless of how many imports I have to do, as it also makes the code clearer). > >but this needs to be done on the executing file, not the file where > >__autoload is defined. For this reason, the autoload_import_class function > >is provided. A sample usage of both these functions is at > >tests/classes/namespace_autoload.php. > > > > > I like the option of having namespaces, and from the description this > seems to be a light method of doing it. It does > require some effort from the user. It seems that for most cases > __autoload will be the same every time, maybe with > different paths or file naming conventions. > You are correct, this is a very lightweight implementation. Very few (from 2-4 IIRC, depending on the type of import) hashtables are searched (this is including class_table), and this number does not increase with the number of class imports nor with the number of namespace imports. Right now, it requires some initial effort from the user to implement the imports, but as you said, this would only need to be done once (once the __autoload function is defined, this can be included from all other scripts). -- Jessie -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Namespace Patch, Beta 1
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 used "out of the box". Marcus, what do you think? Regards, Jessie Hernandez -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Namespace Patch, Beta 1
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 = strtr($class, '_', '/') I don't know if you took that into account though... Regards, -- Michael - < mike(@)php.net > signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [PATCH] Namespace Patch, Beta 1
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 the file path. -- Jessie -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is this a bug?
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 I was reading again the example I wrote, I found that libxml always returns column 0: This seems to be a bug to me, or the column stuff will only work when validating with a dtd/..? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: thienvk
thienvk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Namespace Patch, Beta 1
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 although if this only addresses classes it might have. One note,
we need to make sure we don't complicate the language too much... But
anyway, hopefully next week or so I'll have more constructive feedback.
At 12:07 AM 8/2/2005 -0400, 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:class1;
- Import aliases: import ns:class1 as my_alias;
- Namespace imports: import namespace ns;
- Anonymous namespaces: namespace { class file_class{} }
- Namespace-private classes: namespace ns{ private class prv_class{} }
Two new functions have also been added to support namespace imports (more on
that below):
- get_imported_namespaces([$className])
Returns an array of imported namespaces for the current file. If a class
name is passed, and this class is currently being autoloaded (also meaning
that this function is called inside __autoload), then the list of returned
imported namespaces is based on the file that triggered the __autoload
call.
- autoload_import_class($className, $namespaceName)
Imports a class in a given namespace for the currently executing file (can
ONLY be used inside __autoload!)
Imports
---
Imports and namespace imports are handled completely by the user with the
use of the __autloload function. This means that there are no restrictions
on class file naming/directory structure. For simple imports, the class
name will be passed with its full name (including the colons, such as
"ns:class1"). For namespace imports, only the class name will be called.
Since the user needs to determine which namespace (or namespaces) a class
belongs to, the "get_imported_namespaces" function is provided to check the
imported namespaces for the currently-executing file. Once the user is
satisfied with a match, he/she needs to perform an "import" for this class,
but this needs to be done on the executing file, not the file where
__autoload is defined. For this reason, the autoload_import_class function
is provided. A sample usage of both these functions is at
tests/classes/namespace_autoload.php.
Namespace-private classes
-
Classes marked as "private" from within a namespace can only be used by
classes defined in the same namespace.
Anonymous namespaces
Classes defined inside anonymous namespaces can only be used within the file
that declared the anonymous namespace.
I believe the attached patch solves the issues that were presented long ago
for namespaces. Referring to the post by Daniel Cogwill at
http://www.zend.com/lists/engine2/200304/msg00164.html, the following are
my answers to the problems he found at the time:
1) import-all silently hides local names.
A: If a global class is defined with the same name as a class in a
namespace, and the namespace class has been imported in the same script,
the global class takes precedence. The namespace class can still be used by
using its full name, i.e. namespace_name:class_name.
2) Interestingly (and I assume this is simply a bug), functions and classes
behave differently wrt to import-all and duplicate definitions.
A: Irrelevant in this patch.
3) There is no way to hide names from import (i.e. make a name
non-exportable). This is a fundamental namespace feature, and there is
already an appropriate keyword (private).
A: Namespace-private classes are supported, using the "private" keyword.
4) The semantic meaning of successive imports depends on their relative
ordering.
A: The engine does not attempt to determine which class is included, the
user decides the most appropriate behavior inside __autoload.
5) The most egregious issue is that an import in an included file affects
the scope of the including file.
A: Imports in this patch only affect the file they are in.
Since I could not find a way to add the tests/classes/namespace directory
and subdirectories, I zipped them separately, as before.
Let me know if you have any questions on the attached patch.
Best regards,
Jessie Hernandez
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Property Overloading RFC
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 extend it? Does it have to know about the get/set methods and the necessary declaration of attributes? And as far as "magic" fields are concerned: IMHO the currently available mechanism of checking the property name against a (possibly e.g. from a DB dynamically created) array in the object is sufficient. So personally I'd not add a language feature as it adds complexity with little (or arguable) gain. My $.02, - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] PHP_INI_SYSTEM and httpd.conf
>> 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 good point to more clearly state somewhere? Goba -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] > PHP include_path maximimal length?
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.php.net/unsub.php
Re: [PHP-DEV] Property Overloading RFC
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 members, in that using
self:: in a base class doesn't allow access to those static members of
inheriting classes? ie, will the above example throw an error or not, like it
would if a similar thing with statics were to try and be done.
Derick Rethans wrote:
> This is ofcourse overly complicated. A better workable solution would be -
> without breaking BC (suggestions for syntax here are very welcome):
>
> class Base
> {
> abstract public $x = 1;
>
> function __get($name)
> {
> if (!self::isVirtual($name))) {
> /* throw error */
> }
> }
> }
>
> $b = new Base();
> echo $b->foo;
> ?>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Property Overloading RFC
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
definitely be instead using plain old properties. I wonder if adding
this language feature might be a bit too hopeful. For instance, most
implementations I have seen of __get()/__set() use them because it isn't
possible to know the names of the variables in advance. Simplexml and
ext/soap are great examples of extensions that were they implemented in
userspace would not be able to use the abstract/virtual keyword proposed
because until the specific class is instantiated, one can't know what
they will be working with. The Savant template engine may use them for
grabbing filtered variables in the future, another good example of "you
must document this with prose, not with program syntax".
Having said this, if the proposal continues, I do have some suggestions.
2)
isAbstract($name))) {
/* throw error */
}
}
}
?>
or
isVirtual($name))) {
/* throw error */
}
}
}
?>
I prefer the 2nd, as it will not confuse with abstract classes (and it
will definitely confuse users if we start mixing metaphors
programmatically).
I also prefer $this-> to self:: as it will allow (as James Crumpton
raised) inheritance without redefinition of __get()/__set().
- Problem 3 can be solved by:
* allowing optional by-ref parameters to the __set
and __get function, so that their signatures become:
function __set($name, $value [, &$error] )
function __get($name [, &$error] )
If the parameter is not given things behave just like they do now ->
__set
and __get can not throw meaningful errors with the correct file/line of
the
conflicting statement
If the parameter is used in the function's declaration and is set to
"false" when the __set or __get function returns, the engine can throw
an
error on the assignment line with the correct file/line combination. If
it's set to "true" (or "null") then the engine should not throw any
error.
* Use a different __set and __get function for 'abstract' properties, then
the engine can already determine if you're doing something wrong before
executing the __set and __get methods.
It seems to me the best solution would be to allow error to be set to
false or an exception object, which would be then thrown as if it was on
the offending line. This would allow the user to customize the error
message as well as the line/file.
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] cgi dates
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.c 3 Aug 2005 06:14:04 -
@@ -2,7 +2,7 @@
+--+
| PHP Version 5|
+--+
- | Copyright (c) 1997-2004 The PHP Group|
+ | Copyright (c) 1997-2005 The PHP Group|
+--+
| This source file is subject to version 3.0 of the PHP license, |
| that is bundled with this package in the file LICENSE, and is|
@@ -1412,9 +1412,9 @@
SG(request_info).no_headers = 1;
}
#if ZEND_DEBUG
- php_printf("PHP %s (%s) (built:
%s %s) (DEBUG)\nCopyright (c) 1997-2004 The PHP Group\n%s", PHP_VERSION,
sapi_module.name, __DATE__, __TIME__, get_zend_version());
+ php_printf("PHP %s (%s) (built:
%s %s) (DEBUG)\nCopyright (c) 1997-2005 The PHP Group\n%s", PHP_VERSION,
sapi_module.name, __DATE__, __TIME__, get_zend_version());
#else
- php_printf("PHP %s (%s) (built:
%s %s)\nCopyright (c) 1997-2004 The PHP Group\n%s", PHP_VERSION,
sapi_module.name, __DATE__, __TIME__, get_zend_version());
+ php_printf("PHP %s (%s) (built:
%s %s)\nCopyright (c) 1997-2005 The PHP Group\n%s", PHP_VERSION,
sapi_module.name, __DATE__, __TIME__, get_zend_version());
#endif
php_end_ob_buffers(1 TSRMLS_CC);
exit(1);
Index: sapi/cgi/getopt.c
===
RCS file: /repository/php-src/sapi/cgi/getopt.c,v
retrieving revision 1.8
diff -u -r1.8 getopt.c
--- sapi/cgi/getopt.c 8 Jan 2004 08:18:08 - 1.8
+++ sapi/cgi/getopt.c 3 Aug 2005 06:14:58 -
@@ -2,7 +2,7 @@
+--+
| PHP Version 5|
+--+
- | Copyright (c) 1997-2004 The PHP Group|
+ | Copyright (c) 1997-2005 The PHP Group|
+--+
| This source file is subject to version 3.0 of the PHP license, |
| that is bundled with this package in the file LICENSE, and is|
Index: sapi/cgi/php_getopt.h
===
RCS file: /repository/php-src/sapi/cgi/php_getopt.h,v
retrieving revision 1.6
diff -u -r1.6 php_getopt.h
--- sapi/cgi/php_getopt.h 8 Jan 2004 17:33:22 - 1.6
+++ sapi/cgi/php_getopt.h 3 Aug 2005 06:14:46 -
@@ -2,7 +2,7 @@
+--+
| PHP Version 5|
+--+
- | Copyright (c) 1997-2004 The PHP Group|
+ | Copyright (c) 1997-2005 The PHP Group|
+--+
| This source file is subject to version 3.0 of the PHP license, |
| that is bundled with this package in the file LICENSE, and is|
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
