[PHP-DEV] T_INTERFACE and T_ABSTRACT as valid class names
Hi,
I've already opened a feature request (#43048) but I feel, that there
need to be a discussion on that topic. The problem is, that the current
pseudo-namespacing used by a huge number of projects (PEAR-style, with
underscores and the related file organisation), could not be easily
ported to namespaces, as the name Interface and Abstract is not a
valid classname. So something like ...
namespace Zend::Db;
class Abstract {...}
... will not work. Same for ...
namespace Zend::Db::Adapter;
interface Interface {...}
Nevertheless it would break some syntax highlighting libraries or maybe
the tokenizer extension, I would propose to allow at least Abstract
and Interface as a class/interface name. This would make porting to
the namespace methodology much easier (I see it quite plainly, a lot of
people would develop cripple names like Intrfce or Abstrct just to make
the PHP parser happy).
cu, Lars
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
[PHP-DEV] PHP 4 Bug Summary Report
PHP 4 Bug Database summary - http://bugs.php.net Num Status Summary (628 total including feature requests) ===[*Programming Data Structures]= 40496 Assigned Test bug35239.phpt still fails (works in PHP 5) ===[*Regular Expressions]= 42283 Open problem in regular expressions ===[Apache2 related]== 38670 Open Whole 4.4.x branch has problem with open_basedir option nested from Apache2 ===[Arrays related]=== 31114 Assigned foreach modify array (works with PHP 5.1) 37451 Open array_multisort fails to trigger by val copy of data (works in PHP = 5.1) 39764 Suspended array_key_exists inconsistent behavior 42177 Open Warning array_merge_recursive(): recursion detected comes again... ===[CGI related]== 42180 Open php in fastcgi environment periodicaly get 90% of CPU ===[Class/Object related]= 39254 Open Refcount error with static variables and object references (PHP4 only) 39681 Open this assignment outside class breaks static function call (PHP4 only) ===[Documentation problem] 29045 Suspended gzopen for URL 36663 Open unexpected difference between zlib.output_compression and ob_gzhandler ===[FDF related]== 34811 Assigned fdf_get_value max size ===[Feature/Change Request]=== 3066 Open Parameter for dns functions to select different DNS 3799 Suspended default_charset brings small incompatibility 3830 Open Function to timeout/break off a function 5007 Analyzed enable no-resolve mode for here docs 5169 Open Missing recursive behavior 5311 Analyzed implement checkdnsrr() and getmxrr() on windows 5575 Open open_basedir to ~ 5601 Analyzed @function() should not turn of error reporting for critical errors 5804 Open parser error if any spaces follow indentifier in with here doc syntax 5883 Assigned --enable-trans-sid modification request 5954 Open Informix can't reliably figure if a text result column is NULL 5975 Open version of strip_tags() that specifies tags to strip (instead of tags to keep) 6118 Open Can not supress runtime warnings on foreach 6268 Open ternary op return only by value 6399 Open checkdate should be able to validate a time as well as a date (timestamp) 6427 Open func_get_arg() does not support references 6503 Open no support for multiple resultset query? 6512 Analyzed sort() Does not sort stings as expected 6574 Open SMTP functions via IMAP c-client library 6680 Open regexps (ereg*) ignores locale settings 6911 Open Problem with array_merge(_recursive) 6927 Suspended 6932 Open Filesize / File_exists and include_path 6993 Open uninstalling is a pain in the ass 7006 Open preg_replace ( string pattern, array replacement, string subject ); 7028 Analyzed xml=shared and wddx do not work together 7132 Assigned fsockopen doesn't report dns lookup failure 7398 Open Stored procedure error return values not passed through 7507 Open Better ODBC error reporting/fetching 7541 Open please consider also support HPUX shl_* 7553 Open RFC: Uplevel Block structure 7559 Open zend_hash_get_current_key_ex returning persistent strings 7578 Open next() and current() do not return referenceing arrays 7808 Open variable value triggerd by function 7923 Analyzed htmlentities doesn't work for ISO 8859-2 7930 Open List() constructor reference assignment 8100 Assigned extract(), extra feature 8108 Analyzed implement trans-sid as output handler 8295 Open absolute path in extension= directive in php.ini not recognized 8395 Open register_shutdown_function() error 8397 Open Multi-results sets are not suppported 8427 Analyzed Unwanted references 8428 Open continue doesn't pass thru a switch statement 8595 Open More effective parsing of list() (+other) 8640 Open enumeration type 8685 Open heredoc: remove column 1 closing identifier requirement 8809 Open Cookieless session with Header redirects 8827 Open PHP_AUTH_PW stores password when using External Authentication 8855 Open session_start should return also FALSE 8897 Open Significant portions of the InterBase API have no PHP representation. 8948 Open readline_completion_function enhance 9095 Open colon/semicolon delimitd extension_dir ? 9195 Analyzed Default class function arguments 9262 Analyzed Inconsistency in the implementation of here-docs 9266 Analyzed Unable to load 14 of
[PHP-DEV] PHP 6 Bug Summary Report
PHP 6 Bug Database summary - http://bugs.php.net Num Status Summary (60 total including feature requests) ===[*General Issues]== 26771 Suspended register_tick_funtions crash under threaded webservers ===[*Unicode Issues]== 42163 Open fgetcsv() gives different output with and without Unicode ===[Apache2 related]== 42209 Open fail on make for sapi/apache2handler/apache_config.lo ===[Arrays related]=== 35277 Suspended incorrect recursion detection 41758 Assigned SORT_LOCALE_STRING broken for sort() in PHP6 ===[Class/Object related]= 33595 Assigned recursive references leak memory 41461 Assigned E_STRICT notice when overriding methods not defined by an Interface in hierarchy ===[Compile Failure]== 42606 Open unicode/constants.c relies on ICU draft api ===[Feature/Change Request]=== 20377 Open php_admin_value affects _only_ .htaccess 27618 Open curl_multi_info_read does not appear to work 29479 Suspended changing current process name 34211 Open PDO_OCI: Allow for data type TIMESTAMP(0) WITH LOCAL TIME ZONE 34252 Open Base functions extension and refactoring 34527 Open trim functions extension 34775 Open parse_url() provide better error description on failure 34882 Open Unable to access *original* posted variable name with dot in 35309 Open Database connection pooling 37081 Open Make the include-errors mention faulty permissions 37380 Open DOMDocument-createAttribute[NS] can't set value 37546 Open DOMDocumentFragment-appendXML namespace support 37796 Open t_is_not_identical for ? 38622 Open Proposed new security scheme for shared hosting (safe mode substitute) 38946 Open pecl/docblock should be merged into ext/tokenizer 40013 Open php_uname() doesnt return nodename 40499 Open filter sapi does not register any highlightning filter 41019 Assigned auto update feature for FastCGI for IIS 41119 Open range() function behavior different on PHP6 and PHP5 41602 Open POSIX functions on Windows using Cygwin Library 42262 Open get_magic_quotes_gpc() should be there and return false 42727 Open Zend doesn't fail with syntax error 42922 Open request for 64bit numbers in php6 ===[Filesystem function related]== 27792 Assigned Functions fail on large files (filesize,is_file,is_dir) 42037 Open fgetc() retuns one char when fails to read on php6 42057 Open fwrite() writes data into file when length is given as a negative value 42110 Open fgetcsv doesn't handle \n correctly in multiline csv record 42125 Open fgetss reads an extra char from file created using file_put_content() 42126 Open size of the file differ, when created using file_put_content() on php6 42167 Open fgetcsv gives different output on php6 compared to php5 42219 Open length argument of fgetcsv() is not effective/working in PHP6 42229 Open fgetcsv() behaves differently for a file containing '\n' with php5 and php6. ===[GD related]=== 34670 Assigned imageTTFText for Indian scripts (Devanagari) 34992 Assigned imageconvolution does not respect alpha ===[I18N and L10N related] 42471 Open locale_set_default returns true on invalid locales ===[ODBC related]= 39756 Assigned Crashes in fetching resultsets with LONG ASCII columns from MaxDB ===[OpenSSL related]== 25614 Suspended openssl_pkey_get_public() fails when given a private key ===[Other web server]= 26495 Suspended Using WebSite Pro 2.5 with ISAPI, cookies are not working ===[PDO related]== 35368 Suspended PDO query does not work properly with serialize 39171 Assigned pdo_mysql configure script sets empty default socket 42079 Open pdo_mysql always links to 3.x libraries (== PDO* in HEAD is out-dated) ===[Performance problem]== 42528 Open Out of char(8-bit) range value doesn't roll back, with uni-code ON. ===[Program Execution] 39992 Open proc_terminate() leaves children of child running ===[Scripting Engine problem]= 33487 Assigned Memory allocated for
Re: [PHP-DEV] T_INTERFACE and T_ABSTRACT as valid class names
The following is just an opinion from an user and should be considered as
such.
You should consider that the PEAR way of naming classes was the nasty
workaround that the namespaces is trying to solve. Therefore, just trying to
make the language fit your needs so you can still use that nasty workaround
into the new feature is not smart. It's like moving one step forward, two
backward.
You have namespaces now, and you want to use them? Forget about PEAR style
and refactor the damn framework if necessary. It's more consistent and
elegant if you use the right name for a class (Abstract or Interface is just
too vague):
namespace Zend::Db;
class AbstractDb { ... }
namespace Zend::Db::Adapter;
class AdapterInterface { ... }
2007/10/20, Lars Strojny [EMAIL PROTECTED]:
Hi,
I've already opened a feature request (#43048) but I feel, that there
need to be a discussion on that topic. The problem is, that the current
pseudo-namespacing used by a huge number of projects (PEAR-style, with
underscores and the related file organisation), could not be easily
ported to namespaces, as the name Interface and Abstract is not a
valid classname. So something like ...
namespace Zend::Db;
class Abstract {...}
... will not work. Same for ...
namespace Zend::Db::Adapter;
interface Interface {...}
Nevertheless it would break some syntax highlighting libraries or maybe
the tokenizer extension, I would propose to allow at least Abstract
and Interface as a class/interface name. This would make porting to
the namespace methodology much easier (I see it quite plainly, a lot of
people would develop cripple names like Intrfce or Abstrct just to make
the PHP parser happy).
cu, Lars
Re: [PHP-DEV] exception policy for core
Hello Lukas, I think all pecl modules should follow the core rules and that means CODINT_STYLE should apply to pecl as much as it does to core. We should hence provide an easy to read (as in html or pdf or whatever) version that is accessible online easier and in a more prominent space than the current thing. Unless there is already something better than going to cvs.php.net or getting a CVS checkout and if so then we should provide better links to it. Especially better links on the pecl pages. marcus Sunday, October 21, 2007, 10:39:11 AM, you wrote: On 17.10.2007, at 22:11, Marcus Boerger wrote: Hello Derick, right, maybe we need writen down rules easy to read for pecl and core other then the CODING_STYLES bile. So how do you propose to proceed? What is not easy to read in the current CS? Should the note about not throwing exception for anything but constructor errors be added to the current CS? Do we bother with a CS for pecl, or do we hold off on that until something becomes a candidate to be bundled? regards, Lukas Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] exception policy for core
On 22.10.2007, at 17:31, Marcus Boerger wrote: Hello Lukas, I think all pecl modules should follow the core rules and that means CODINT_STYLE should apply to pecl as much as it does to core. We should hence provide an easy to read (as in html or pdf or whatever) version that is accessible online easier and in a more prominent space than the current thing. Unless there is already something better than going to cvs.php.net or getting a CVS checkout and if so then we should provide better links to it. Especially better links on the pecl pages. Ok, I will work on something like this next weekend. I will write it up on the wiki, but it should be easy to port that to php.net once its approved. Then again, we could just link to the file in CVS and I could instead work on improving the current document. I am still not clear what exactly you find lacking in the current document .. only that its only available in CVS? I presume that anyone working on core or pecl will have no trouble checking out that file. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dynamic class names and namespaces
On Sunday 21 October 2007, Stanislav Malyshev wrote:
Using dynamic class names works fine without namespaces, but
doesn't work at all with namespaces. Take this simple example:
?php
namespace test;
class Foo {}
$class = Foo;
$foo = new test::$class();
?
Will produce the following message:
Fatal error: Class 'test::test' not found in foo.php on line Y
I don't think partially variable class name is supposed to work. It is
interesting though how the engine managed to parse this at all...
Ahh, I see, that's a bit disappointing. Any reason why it doesn't/shouldn't
work ?
/Magnus
--
One of the most striking differences between a cat and a lie is that a cat has
only nine lives.
-- Mark Twain, Pudd'nhead Wilson's Calendar
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dynamic class names and namespaces
Ahh, I see, that's a bit disappointing. Any reason why it doesn't/shouldn't work ? Yes. Test::Foo is a class name, so you can't make part of it variable and part not, just as you couldn't write: $var = bar; $a = new foo$var(); and expect new instance of class foobar. You'd have to compose the full name in variable and then use it. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] import/use last call
Hi all! Since many packages (wordpress, propel, horde, phing, etc.) use import as either class or function name, and we couldn't find a good solution to make it work with import keyword without going into all kinds of troublesome hacks, so we are thinking about replacing 'import' keyword with 'use' keyword, which is already reserved. If you know any reason why this may be a problem - please speak now (or forever hold your peace :). Please do not answer this email with proposals to replace 'namespace' keyword with 'package', etc. - it will be offtopic. For this topic please let's discuss only using keyword 'use' instead of 'import'. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Message (Your message dated Mon, 22 Oct 2007 15:41:37...)
Your message dated Mon, 22 Oct 2007 15:41:37 -0700 with subject Returned mail: see transcript for details has been submitted to the moderator of the TOURBUS list: =?UTF-8?Q?Bob_Rankin?= [EMAIL PROTECTED]. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: import/use last call
Stanislav Malyshev wrote: Hi all! Since many packages (wordpress, propel, horde, phing, etc.) use import as either class or function name, and we couldn't find a good solution to make it work with import keyword without going into all kinds of troublesome hacks, so we are thinking about replacing 'import' keyword with 'use' keyword, which is already reserved. If you know any reason why this may be a problem - please speak now (or forever hold your peace :). Please do not answer this email with proposals to replace 'namespace' keyword with 'package', etc. - it will be offtopic. For this topic please let's discuss only using keyword 'use' instead of 'import'. Hold off for a bit - I may have a simple solution that solves the problem for class names, method names and functions, have to code the patch tonight first to prove it works. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: import/use last call
Hello Gregory, even if you can solve it easily your patch will not solve the fact that we won't have a token for that keyword the, or am i missing something? marcus Tuesday, October 23, 2007, 1:18:52 AM, you wrote: Stanislav Malyshev wrote: Hi all! Since many packages (wordpress, propel, horde, phing, etc.) use import as either class or function name, and we couldn't find a good solution to make it work with import keyword without going into all kinds of troublesome hacks, so we are thinking about replacing 'import' keyword with 'use' keyword, which is already reserved. If you know any reason why this may be a problem - please speak now (or forever hold your peace :). Please do not answer this email with proposals to replace 'namespace' keyword with 'package', etc. - it will be offtopic. For this topic please let's discuss only using keyword 'use' instead of 'import'. Hold off for a bit - I may have a simple solution that solves the problem for class names, method names and functions, have to code the patch tonight first to prove it works. Greg Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: import/use last call
Hold off for a bit - I may have a simple solution that solves the problem for class names, method names and functions, have to code the patch tonight first to prove it works. OK, please send it as soon as you have it :) -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] import/use last call
Stanislav Malyshev wrote: Since many packages (wordpress, propel, horde, phing, etc.) use import as either class or function name, and we couldn't find a good solution to make it work with import keyword without going into all kinds of troublesome hacks, so we are thinking about replacing 'import' keyword with 'use' keyword, which is already reserved. If 'use' is already reserved, it makes the most sense IMO. -- Brian Moon Senior Developer -- http://dealnews.com/ It's good to be cheap =) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: import/use last call
Marcus Boerger wrote: Hello Gregory, even if you can solve it easily your patch will not solve the fact that we won't have a token for that keyword the, or am i missing something? marcus Hi Marcus, Just finished the patch (see separate reply), and in my tests, the keyword still works as a keyword. So unless I'm not understanding your question, yes, we will have a token for the keyword. Greg P.S. feel free to call me Greg :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: import/use last call
Stanislav Malyshev wrote:
Hold off for a bit - I may have a simple solution that solves the
problem for class names, method names and functions, have to code the
patch tonight first to prove it works.
OK, please send it as soon as you have it :)
Hi,
The attached patch is for PHP 5.3, if it is acceptable, I will port it
to PHP 6, which is not difficult, although it does involve a lot of
cut/pasting.
The patch does these things:
1) fixes an unrelated bug I found in implementation of LSB - static is
not checked for in zend_do_import()/zend_do_namespace() and other places
that we check for self and parent
2) fixes a rather serious error in the fix for Bug #42859 - missing
parens in zend_do_import()
3) adds import and namespace as valid function/class names
4) allows any string for method names, just as we allow any string for
variable names
5) fixes a bug in logic for $class-list where $class- list (note the
whitespace between - and list) returns a T_LIST instead of T_STRING
6) It allows import ::Classname as Blah which is currently a parse error
7) class constants are unchanged - reserved words still error out.
Note that the zend_compile.c fixes can all be committed directly as they
are all bugfixes and not related to the import/namespace/reserved words fix.
To implement this, I added several states to the lexer in order to
return T_STRING whenever possible, which is after T_NEW, T_INTERFACE,
T_CLASS, T_EXTENDS and in the T_IMPLEMENTS list. In addition, after
T_FUNCTION outside of a class, it returns T_STRING for import and
namespace but no other reserved words. After T_FUNCTION inside of a
class (method declaration), it returns T_STRING for all possible
strings. After :: or - T_STRING is always returned. Also, rather than
take the approach LSB does with T_STATIC, I have the lexer initialize
the string value of T_IMPORT and T_NAMESPACE so we can preserve case for
autoloading needs. The parser frees the unused char * when normal
import/namespace declarations are called.
In the parser, I use fully_qualified_class_name instead of
namespace_name for both import syntaxes. This introduces a minor issue
in that this is no longer a parse error:
import static::oops as Classname;
However, if Classname is used, this will simply result in Fatal
error: Class 'static::oops' not found in... and shouldn't be too big of
a deal. Also in the parser, I inserted T_IMPORT and T_NAMESPACE as
aliases to T_STRING in global situations to allow for static method
calls, class constants, and fully-qualified namespace calls.
Basically this script is now possible with the patch:
?php
namespace import;
import ::Exception as Test;
function import() {echo 'import function';}
interface import {}
interface fooey {}
class Exception extends ::Exception implements fooey, import {}
class namespace {
const HI = 3;
function list() {echo __METHOD__;}
}
import();
var_dump(namespace::HI);
namespace::list();
?
and results in this output:
[EMAIL PROTECTED]:~/workspace/php5$ sapi/cli/php -n testme.php
import functionint(3)
import::namespace::list
I have not performed profiling on the patch, instead focusing on
correctness for now.
The patch looks complicated because of the additional states, but is
really not that complicated, honest.
:)
Greg
? Zend/tests/zend_function_name.phpt
Index: Zend/zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.647.2.27.2.41.2.10
diff -u -r1.647.2.27.2.41.2.10 zend_compile.c
--- Zend/zend_compile.c 17 Oct 2007 10:01:21 - 1.647.2.27.2.41.2.10
+++ Zend/zend_compile.c 23 Oct 2007 03:15:41 -
@@ -2975,7 +2975,7 @@
lcname = zend_str_tolower_dup(class_name-u.constant.value.str.val,
class_name-u.constant.value.str.len);
- if (!(strcmp(lcname, self) strcmp(lcname, parent))) {
+ if (!(strcmp(lcname, self) strcmp(lcname, parent)
strcmp(lcname, static))) {
efree(lcname);
zend_error(E_COMPILE_ERROR, Cannot use '%s' as class name as
it is reserved, class_name-u.constant.value.str.val);
}
@@ -4582,7 +4582,9 @@
if (((Z_STRLEN(name-u.constant) == sizeof(self)-1)
!memcmp(lcname, self, sizeof(self)-1)) ||
((Z_STRLEN(name-u.constant) == sizeof(parent)-1)
- !memcmp(lcname, parent, sizeof(parent)-1))) {
+ !memcmp(lcname, parent, sizeof(parent)-1)) ||
+ ((Z_STRLEN(name-u.constant) == sizeof(static)-1)
+ !memcmp(lcname, static, sizeof(static)-1))) {
zend_error(E_COMPILE_ERROR, Cannot use '%s' as namespace
name, Z_STRVAL(name-u.constant));
}
efree(lcname);
@@ -4596,7 +4598,7 @@
{
char *lcname;
zval *name, *ns, tmp;
- zend_bool warn = 0;
+ zend_bool warn = 0, shorthand = 0;
if (!CG(current_import)) {
CG(current_import) = emalloc(sizeof(HashTable));
@@ -4611,11 +4613,12 @@
Re: [PHP-DEV] Order of class resolution with namespaces and autoload
Quoting Stanislav Malyshev [EMAIL PROTECTED]: import Exception; - name conflict, which seems correct import Exception is a no-op, so I don't understand how you could have got name conflict. Do you mean import Test::Exception? That should work, if it didn't it's a bug. It turns out that this does not happen with CVS PHP 5.3. With Greg's first patch for fixing multiple uses of import Test::Exception, however, this is the reproduce script and error: ?php namespace Foo; import Exception; results in: Maya:/tmp chuck$ php import_exception.php Fatal error: Import name 'Exception' conflicts with defined class in /private/tmp/import_exception.php on line 4 Also, with unpatched 5_3 CVS, I get this: Warning: The import statement with non-compound name 'Exception' has no effect in /tmp/import_exception.php on line 4 I think that either import ::Exception needs to work, or import Exception shouldn't issue a warning. import Exception as Error; - Fatal error: Import name 'Error' conflicts with defined class in /Users/chuck/Desktop/php namespaces/2.php on line 4 (this I don't understand) I'm afraid I am missing something since in line 4 of 2.php there's no definition of any class or import. Can you give me full examples of non-working parts? It might be there's some bug in there. This is another one that only happens with Greg's initial patch (I haven't tried the next one yet Greg, sorry). For Greg's benefit here's the reproduce script: ?php namespace Foo; import Exception as Error; And result: Maya:/tmp chuck$ php import_exception_alias.php Fatal error: Import name 'Error' conflicts with defined class in /private/tmp/import_exception_alias.php on line 4 import ::Exception as Error; - parse error (can't import a top-level class name that way) Well, we might allow importing global classes, if it's needed. I think this would be a good thing. Therefore, in my mind, in order to write durable code that will not break no matter what other classes other developers define or import, I should always prefix builtin classes with ::. Other developers shouldn't define or import classes into your namespace... I think you need to envision working in a large team on a large project here, but you may simply not see the need. -chuck -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Order of class resolution with namespaces and autoload
Quoting Stanislav Malyshev [EMAIL PROTECTED]: Yes. I think that if you use an unqualified name it should always be relative to the namespace (and importing internal classes into your namespace lets you use short names for them, avoiding ::Exception). Unfortunately, there are problems with this solution, since it makes common case harder to implement - internal classes are more frequently used than overridden. It makes harder to convert library code which does not use tricks like overriding system classes - which is on my experience most of the code - you have now to go to almost every file and find all the system classes you have used there and put imports for them. My last word on this is just going to be to ask you to consult with the Zend Framework team (Matthew W.), PEAR2 (Greg), and perhaps some other large PHP class libraries/frameworks. I don't think it's unreasonable to say that namespaces should be heavily influenced by the kind of large projects that will use them. I'm speaking for Horde; if all the other large projects prefer it the way it currently is, then that's fine, I can live with that, but if not, I just ask that you reconsider. Thanks, -chuck -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Order of class resolution with namespaces and autoload
namespace Foo; import Exception; Once more, import with one-term argument is a no-op. And will stay so. That's why we have the warning. I think that either import ::Exception needs to work, or import Exception shouldn't issue a warning. We'll discuss this one. I wonder if anybody else feels a need for it? I think you need to envision working in a large team on a large project here, but you may simply not see the need. I'd say if you have large team which has a possibility of having classes with same names running into each other, why not having them reside in different namespaces? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Order of class resolution with namespaces and autoload
Stanislav Malyshev wrote: namespace Foo; import Exception; Once more, import with one-term argument is a no-op. And will stay so. That's why we have the warning. I think that either import ::Exception needs to work, or import Exception shouldn't issue a warning. We'll discuss this one. I wonder if anybody else feels a need for it? One of the nice features of import is that we will be able to take older code, plop a namespace declaration at the top of the file and a few imports and without recoding anything have full access to class names, i.e. refactoring class names without actually having to touch the code. As such, this may mean aliasing top-level classes to another name. I don't have a specific example off the top of my head, but I hope this makes sense. I think you need to envision working in a large team on a large project here, but you may simply not see the need. I'd say if you have large team which has a possibility of having classes with same names running into each other, why not having them reside in different namespaces? After some reflection, I think the only use case would be in an autoload implementation. If an unknown class is simply used, the executor assumes you want the current namespace. The only way around this is to do something like import Classname as Classname; which seems kind of silly. Another possibility for all of this would be to have use trigger autoload if the class doesn't exist, as a runtime option. import could be a non-autoloading version of the same thing. i.e.: ?php namespace Blah; use Burp::Exception; use Burp::thing as mine; import Burp::another; $b = new Exception; // Burp::Exception $c = new mine; // Burp::thing $a = new another; // Burp::another ? would trigger autoload for Burp::Exception and Burp::thing and fatal error if the class can't be loaded, and simply alias Burp::another to another in the script. This may be too much, I'm on the fence on its utility, but it would provide a more abstract way of triggering a friendly error message if a class is not found, something like class Burp::Exception was not found, and could not be autoloaded (include_path=.:/whatever). Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
