Re: [PHP-DEV] true namespaces, yet another point of view
On 29.09.2008, at 00:21, Gregory Beaver wrote: Lukas Kahwe Smith wrote: On 24.09.2008, at 01:17, Guilherme Blanco wrote: For those that do not understand very well the explanation of jvlad... He's suggesting to change the class struct to be an scope struct, and have a property that tells if it's a namespace or a class, and reuse the implementation of class which already works very well. The nested support is achieved afai understand through the Adjacency List algorithm... can you confirm this to me? or just leave the organization of things to classes (with long class names with a nice prefix to prevent collissions) and leave it to class_alias() (and equivalent features for functions .. also with the option of a compile time aliasing) to handle the aliasing. this removes the need for namespaces and use statements, while making it possible to make class/function names short (that are long for organizational and collision prevention reasons). Hi, This approach doesn't work because aliasing with class_alias() does not allow name conflicts: Well my point was .. Library code uses long names, glue code can alias. Of course sometimes the lines between what is library and glue code are hard to draw. Anyways, I guess we are close to a good solution for namespaces in 5.3 .. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] solving the namespace conflict issues betweenfunction/staticmethod class constant/ns constant
Maybe just use . as namespace separator. MyNameSpace.SomeClass::_getInstance()-SomeDBClass-Query(); That will eliminate all resolution problems, it isn't used for anything than string concatenation, and it's one symbol. It's 100% better than \ and I think it would be better than ::: or and so on. A point against \ is that it has special meaning in every programming language as escape character, so it is 100% bad to use it.
Re: [PHP-DEV] solving the namespace conflict issues betweenfunction/staticmethod class constant/ns constant
Hi, I think we need string concatenation here and there ;) Regards, Stan Vassilev - Original Message - From: Arvids Godjuks To: Stan Vassilev | FM Cc: PHP Internals List Sent: Monday, September 29, 2008 9:19 AM Subject: Re: [PHP-DEV] solving the namespace conflict issues betweenfunction/staticmethod class constant/ns constant Maybe just use . as namespace separator. MyNameSpace.SomeClass::_getInstance()-SomeDBClass-Query(); That will eliminate all resolution problems, it isn't used for anything than string concatenation, and it's one symbol. It's 100% better than \ and I think it would be better than ::: or and so on. A point against \ is that it has special meaning in every programming language as escape character, so it is 100% bad to use it.
Re: [PHP-DEV] solving the namespace conflict issues betweenfunction/staticmethod class constant/ns constant
String concatenation woun't be affected, because you can't concatenate class definitions like in my example. To concatenate you should use variables or strings/numbers. So I don't see any complications with that. 2008/9/29 Stan Vassilev | FM [EMAIL PROTECTED] Hi, I think we need string concatenation here and there ;) Regards, Stan Vassilev - Original Message - From: Arvids Godjuks To: Stan Vassilev | FM Cc: PHP Internals List Sent: Monday, September 29, 2008 9:19 AM Subject: Re: [PHP-DEV] solving the namespace conflict issues betweenfunction/staticmethod class constant/ns constant Maybe just use . as namespace separator. MyNameSpace.SomeClass::_getInstance()-SomeDBClass-Query(); That will eliminate all resolution problems, it isn't used for anything than string concatenation, and it's one symbol. It's 100% better than \ and I think it would be better than ::: or and so on. A point against \ is that it has special meaning in every programming language as escape character, so it is 100% bad to use it.
Re: [PHP-DEV] solving the namespace conflict issues betweenfunction/staticmethod class constant/ns constant
String concatenation woun't be affected, because you can't concatenate
class definitions like in my example.
To concatenate you should use variables or strings/numbers. So I don't see
any complications with that.
MyNameSpace.SomeClass::_getInstance()-SomeDBClass-Query();
You're forgetting constants:
define('MyNameSpace', 'Hi ');
class SomeClass { function world() { return 'world'; }}
MyNameSpace.SomeClass::world(); // Hi world
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/soap and http header
Hi Brian,
I think you patch does the things you like properly, but why do we need
such ability? I don't see a use-case.
In case of accepting this patch, we also need to care about duplicate
headers.
Thanks. Dmitry.
Brian J. France wrote:
After some more testing I needed to tweak the patch and the example,
here is version 2.
$opts = array('http' = array('header' = 'X-foo: bar'));
$ctx = stream_context_create($opts);
Brian
--- ext/soap/php_http.c.orig2008-09-26 05:39:50.0 -0700
+++ ext/soap/php_http.c2008-09-26 06:42:34.0 -0700
-391,7 +391,8 @@
PG(allow_url_fopen) = old_allow_url_fopen;
if (stream) {
-zval **cookies, **login, **password;
+php_stream_context *context = NULL;
+zval **cookies, **login, **password, **tmpzval = NULL;
int ret = zend_list_insert(phpurl, le_url);
add_property_resource(this_ptr, httpurl, ret);
-638,6 +639,19 @@
proxy_authentication(this_ptr, soap_headers TSRMLS_CC);
}
+/* get context to check for http headers */
+if (SUCCESS == zend_hash_find(Z_OBJPROP_P(this_ptr),
+ _stream_context, sizeof(_stream_context),
(void**)tmp)) {
+context = php_stream_context_from_zval(*tmp, 0);
+}
+
+/* Send http headers from context */
+if (context
+php_stream_context_get_option(context, http, header,
tmpzval) == SUCCESS
+Z_TYPE_PP(tmpzval) == IS_STRING Z_STRLEN_PP(tmpzval)) {
+smart_str_appendl(soap_headers, Z_STRVAL_PP(tmpzval),
Z_STRLEN_PP(tmpzval));
+}
+
/* Send cookies along with request */
if (zend_hash_find(Z_OBJPROP_P(this_ptr), _cookies,
sizeof(_cookies), (void **)cookies) == SUCCESS) {
zval **data;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 6 Bug Summary Report
PHP 6 Bug Database summary - http://bugs.php.net/ Num Status Summary (67 total -- which includes 30 feature requests) ===[*General Issues]== 26771 Suspended register_tick_funtions crash under threaded webservers ===[Apache2 related]== 44083 Open virtual() not outputting results if zlib.output_compression = On ===[Arrays related]=== 35277 Suspended incorrect recursion detection 41758 Assigned SORT_LOCALE_STRING broken for sort() in PHP6 43109 Open array_intersect() emits unexpected no of notices when 2d array is passed as arg ===[Class/Object related]= 41461 Assigned E_STRICT notice when overriding methods not defined by an Interface in hierarchy ===[COM related]== 45836 Open cannot use com ===[Compile Failure]== 42606 Open unicode/constants.c relies on ICU draft api 44502 Suspended Compiling ok with MySQL 5.0 ===[Documentation problem] 46057 Open Problem in documentation ===[Filesystem function related]== 42110 Open fgetcsv doesn't handle \n correctly in multiline csv record 44034 Open FILE_IGNORE_NEW_LINES in FILE does not work as expected when lines end in \r\n 45585 Open fread() return value for EOF inconsistent between PHP 5 and 6 ===[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 ===[mbstring related]= 44868 Open Replaces UTF-8 symbol with incorrect symbol ===[MySQL related] 44076 Open mysql_result returns nothing with blob 45246 Open make error after ./configure --with-mysql ===[ODBC related]= 39756 Open 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 ===[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 43784 Assigned escapeshellarg removes % from given string ===[Regexps related]== 44923 Open ereg functions are not unicode aware: provide wrapper functions in PCRE ===[Reproducible crash]=== 45107 Open setting ext_dir to ./ (and other ini settings) causes apache crash ===[Scripting Engine problem]= 42194 Open $argc/$argv[] won't work when .php extension is assigned to php.exe ===[Session related]== 44860 Open session_encode() fails for php_binary serializer ===[Strings related]== 44075 Verified strtok misbehaving 45566 Open Strict comparision on $_SERVER values fail ===[Unicode Engine related]=== 45087 Open Illegal or truncated character in input ===[URL related]== 45602 Open urlencode/urldecode should use ASCII encoding ===[XML related]== 45022 Open Can't get php6 snap to ./configure on mac, fails at libxml2 ===[XSLT related]= 38218 Assigned php:functionString tries to access objects with their names in lowercase ===[Zlib Related]= 30153 Suspended FATAL erealloc() error when using gzinflate() Assigned bugs and feature requests (reminders sent): andrei 41758: SORT_LOCALE_STRING broken for sort() in
[PHP-DEV] Disable PHAR by default
Seems like PHAR causes quite unexpected things, f.e. http://bugs.php.net/bug.php?id=46194 where PHP crashes if file does not exist. Please, can this crap be disabled by default (ALWAYS) and only those who actually need it can enable it? --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Disable PHAR by default
Hello Jani, we're in alpha and fix all of those issues. in contrast to 99.9% of our users it is very easy for you to disable it. But the majority will only get the extension when we enable by default. And it is one of the big plans for 5.3 to finally support native packaging to make a lot of things easier. Once again if you don't like it, just disable it like you configure any of your installations specifically for your needs - others cannot. marcus Monday, September 29, 2008, 1:15:16 PM, you wrote: Seems like PHAR causes quite unexpected things, f.e. http://bugs.php.net/bug.php?id=46194 where PHP crashes if file does not exist. Please, can this crap be disabled by default (ALWAYS) and only those who actually need it can enable it? --Jani Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Disable PHAR by default
Top posting since you started it.. :) Yes, I do disable everything I don't need. You don't need to lecture me about that. I was just pointing out that this ext/phar/ seems to do things most enabled by default extensions don't do. Like affect the very core of PHP. So enabling such by default isn't very good idea IMO.. And this extension was sneaked in core by promising something along the lines of 'it will not be enabled by default'...iirc.. --Jani Marcus Boerger wrote: Hello Jani, we're in alpha and fix all of those issues. in contrast to 99.9% of our users it is very easy for you to disable it. But the majority will only get the extension when we enable by default. And it is one of the big plans for 5.3 to finally support native packaging to make a lot of things easier. Once again if you don't like it, just disable it like you configure any of your installations specifically for your needs - others cannot. marcus Monday, September 29, 2008, 1:15:16 PM, you wrote: Seems like PHAR causes quite unexpected things, f.e. http://bugs.php.net/bug.php?id=46194 where PHP crashes if file does not exist. Please, can this crap be disabled by default (ALWAYS) and only those who actually need it can enable it? --Jani Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Disable PHAR by default
On Mon, Sep 29, 2008 at 3:32 PM, Jani Taskinen [EMAIL PROTECTED] wrote: Top posting since you started it.. :) Yes, I do disable everything I don't need. You don't need to lecture me about that. I was just pointing out that this ext/phar/ seems to do things most enabled by default extensions don't do. Like affect the very core of PHP. So enabling such by default isn't very good idea IMO.. And this extension was sneaked in core by promising something along the lines of 'it will not be enabled by default'...iirc.. It can be disabled during beta-phase. Currently, we should focus on finding bugs and fixing those — that's what alpha is about. It's easier to do this, if phar is enabled. -- Alexey Zakhlestin http://blog.milkfarmsoft.com/
Re: [PHP-DEV] Disable PHAR by default
Currently, we should focus on finding bugs and fixing those — that's what alpha is about. It's easier to do this, if phar is enabled. Precisely. If phar hadn't been enabled by default we wouldn't know about this missing check until someone hit it in production! - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php7- dropping the $ from the variable name - rfc
On Thu, Sep 18, 2008 at 9:25 PM, Jordan Moore [EMAIL PROTECTED] wrote: On Thu, Sep 18, 2008 at 11:06 AM, Brian Moon [EMAIL PROTECTED] wrote: mike wrote: Personally I love the $. It makes it so much easier to identify variables. It's a single character. Can't see the need honestly to even bring this up. +1,000,000. Horrible idea. *facepalm* -- Brian Moon Senior Web Engineer -- When you care enough to spend the very least. http://dealnews.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I'm unsure how the parser works, so ignoring those potential issues, this change would... 1. Break every single PHP script that is currently in existence. maybe an legacy mode can be included in ini 2. Break syntax highlighting (and probably other tools/functions) for every IDE that is currently in existence. this can be fixed by each ide , I talk about something like I'm not sure that much more needs to be said. I can give another practical example in wxjscript from this javascript example that can be run on apache server you can see that is simpler to read and to learn at least for an beginner http://www.wxjavascript.net/mysql/index.html What i want to say is that php must go forward and yes you can change/break things in the engine like in the php 4 to php 5 migration or php5 to php6 In time maybe an fast javascript engine could replace php if it doesn't change in the right direction or it goes to java bloatware way -- Jordan Ryan Moore -- developer flamerobin.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Disable PHAR by default
Totally hating to bring this up again (and hijacking this thread), but can we please enable ext/xsl by default in 5.3? : - David Am 29.09.2008 um 13:24 schrieb Marcus Boerger: Hello Jani, we're in alpha and fix all of those issues. in contrast to 99.9% of our users it is very easy for you to disable it. But the majority will only get the extension when we enable by default. And it is one of the big plans for 5.3 to finally support native packaging to make a lot of things easier. Once again if you don't like it, just disable it like you configure any of your installations specifically for your needs - others cannot. marcus Monday, September 29, 2008, 1:15:16 PM, you wrote: Seems like PHAR causes quite unexpected things, f.e. http://bugs.php.net/bug.php?id=46194 where PHP crashes if file does not exist. Please, can this crap be disabled by default (ALWAYS) and only those who actually need it can enable it? --Jani Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] solving the namespace conflict issues betweenfunction/staticmethod class constant/ns constant
2008/9/29 Arvids Godjuks [EMAIL PROTECTED]: String concatenation woun't be affected, because you can't concatenate class definitions like in my example. To concatenate you should use variables or strings/numbers. So I don't see any complications with that. 2008/9/29 Stan Vassilev | FM [EMAIL PROTECTED] Hi, I think we need string concatenation here and there ;) Regards, Stan Vassilev - Original Message - From: Arvids Godjuks To: Stan Vassilev | FM Cc: PHP Internals List Sent: Monday, September 29, 2008 9:19 AM Subject: Re: [PHP-DEV] solving the namespace conflict issues betweenfunction/staticmethod class constant/ns constant Maybe just use . as namespace separator. MyNameSpace.SomeClass::_getInstance()-SomeDBClass-Query(); That will eliminate all resolution problems, it isn't used for anything than string concatenation, and it's one symbol. It's 100% better than \ and I think it would be better than ::: or and so on. A point against \ is that it has special meaning in every programming language as escape character, so it is 100% bad to use it. What would happen to a class with a toString() method? -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Disable PHAR by default
Jani Taskinen wrote: Seems like PHAR causes quite unexpected things, f.e. http://bugs.php.net/bug.php?id=46194 where PHP crashes if file does not exist. Please, can this crap be disabled by default (ALWAYS) and only those who actually need it can enable it? Hi Jani, Classic overreacting, and disrespect to years of careful work. First of all, this bug has existed for all of 10 hours, and the problem is easy to fix, and caused because I never imagined PHP would be stupid enough to pass in a null pointer to zend_compile_file (kind of hard to compile a file whose name is undefined). This is a 3-line fix, and is only caused by a bug in the CGI handler coupled with lighttpd, which is setting filename to 0x0, something none of the other sapis do when a file is non-existent. Let's think about this for a second: why pass in a null pointer for a filename to a function whose purpose is to compile a file in the first place? How about we disable the CGI sapi under lighttpd by default? Don't be such a weenie. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Disable PHAR by default
On Mon, 2008-09-29 at 14:32 +0200, David Zülke wrote: Totally hating to bring this up again (and hijacking this thread), but can we please enable ext/xsl by default in 5.3? : Only possible when bundling libxslt - no way. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Disable PHAR by default
On Mon, 2008-09-29 at 15:35 +0400, Alexey Zakhlestin wrote: It can be disabled during beta-phase. Currently, we should focus on finding bugs and fixing those — that's what alpha is about. It's easier to do this, if phar is enabled. Exact. That's my idea, too. By enabling by default we get more tests of at least the basic functionality, maybe not functional tests but more runs of make test and way more testing of fancy overwrites phar does. Additionally a /working/ phar is an extremely helpful feature for many people. So, if the problems continue we have to disable it (or possibly even drop it), if it stabilizes well we probably keep it enabled. Same goes for other stuff newly enabled by default. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Disable PHAR by default
hi Johannes. On Mon, Sep 29, 2008 at 3:15 PM, Johannes Schlüter [EMAIL PROTECTED] wrote: On Mon, 2008-09-29 at 14:32 +0200, David Zülke wrote: Totally hating to bring this up again (and hijacking this thread), but can we please enable ext/xsl by default in 5.3? : Only possible when bundling libxslt - no way. What David meant is to do the same as ext/libxml (and related). It would help a lot to spread ext/xslt availability. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php7- dropping the $ from the variable name - rfc
marius popa wrote: 1. Break every single PHP script that is currently in existence. maybe an legacy mode can be included in ini we want less of such legacy mode options, not more plus this would have to be configured per application and not just per server 2. Break syntax highlighting (and probably other tools/functions) for every IDE that is currently in existence. this can be fixed by each ide , I talk about something like sure it can be fixed, but you missed the *every* part plus IDEs, editors, highlight tools etc. would have to support both old and new for quite a while I'm not sure that much more needs to be said. I can give another practical example in wxjscript from this javascript example that can be run on apache server you can see that is simpler to read and to learn at least for an beginner http://www.wxjavascript.net/mysql/index.html so instead of clearly marking variables with $ as such there they need to be declared with 'var' instead, and '-' is replaced by '.' ... ... i don't see much of a difference there from a learning point of view though What i want to say is that php must go forward and yes you can change/break things in the engine like in the php 4 to php 5 migration or php5 to php6 sure we can break things if there is a compelling reason to do so, i'm just totally missing the compelling part here ... -- Hartmut Holzgraefe, MySQL Regional Support Manager EMEA Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] solving the namespace conflict issues betweenfunction/staticmethod class constant/ns constant
toString() should work as expected, because you first realize that this is a class, so it is concatenation and toString() should be called. As I understand namespaces are resoved in compile time, so when it comes to executing code - byte code for MY_CONST.MyCLASS::staticMethod() and MY_NAMESPACE.MyCLASS::staticMethod() are to different opcodes, right? I know that there is a patch for resolving constant values on compile time, if it is applied to 5.3 - that all constants should become values in opcodes. On compile time we know what constants we have and what namespaces we have before current position in code - if we get something not defined neither as constant, neither as namespace - treat that as undefined constant, because if you forget to import a namespace - you'r will get a fatal error anyway - this is one way. Other way - make such error fatal, so programmer will fix it the minute it happened and will make sure he uses it right. Ok, we got situation then constant name and namespace name are the same - throw a fatal error like if we had to functions with same name. Above written is on assumption I correctly understood how PHP parser translates the code into opcodes. Well, we can do it the most easy way - use : for namespace. It has no drawbacks as . or any other separators does (::: is too long, \ is special symbol, etc), is completely new in PHP and defines that it is a namespace 100%. Everybody happy, no name conflicts, 5.3 is pushed out with completely working namespaces without any need to cut functions and constants. 2008/9/29 Richard Quadling [EMAIL PROTECTED] 2008/9/29 Arvids Godjuks [EMAIL PROTECTED]: String concatenation woun't be affected, because you can't concatenate class definitions like in my example. To concatenate you should use variables or strings/numbers. So I don't see any complications with that. 2008/9/29 Stan Vassilev | FM [EMAIL PROTECTED] Hi, I think we need string concatenation here and there ;) Regards, Stan Vassilev - Original Message - From: Arvids Godjuks To: Stan Vassilev | FM Cc: PHP Internals List Sent: Monday, September 29, 2008 9:19 AM Subject: Re: [PHP-DEV] solving the namespace conflict issues betweenfunction/staticmethod class constant/ns constant Maybe just use . as namespace separator. MyNameSpace.SomeClass::_getInstance()-SomeDBClass-Query(); That will eliminate all resolution problems, it isn't used for anything than string concatenation, and it's one symbol. It's 100% better than \ and I think it would be better than ::: or and so on. A point against \ is that it has special meaning in every programming language as escape character, so it is 100% bad to use it. What would happen to a class with a toString() method? -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php7- dropping the $ from the variable name - rfc
sure we can break things if there is a compelling reason to do so, i'm just totally missing the compelling part here ... This is not going to happen. This thread is over. -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
On Mon, Sep 29, 2008 at 12:21 AM, Ryan Panning [EMAIL PROTECTED] wrote:
+1, I second this completely
From someone who *was* using namespaces developing against the 5.3 branch,
this is going to happen sooner or later. I found that :: just causes to many
questions when used in namespaces. Using :: or - just for the sake of
reusing existing tokens is just wrong. I'm in favor of # if it can be worked
out.
+1 as well, but I must say # is not right, it is a very black/filled
character, as in it doesn't visually#separate#words#that#well. Using
the dot would be really nice, but I guess it would break with
something like this : concat.foo.bar().baz so it's not an option.
Using a single colon might work out ? foo:bar:class::staticFunc()
sounds good to me, but maybe I missed something.
I also had the idea of using the underscore, even though I guess we
can't go through with this as people _might_ have used double
underscores in their class names, I guess it would work out quite well
with single underscores, for example :
class Foo_Bar {
public static function callMe()
}
Foo_Bar::callMe();
..would be read as class Bar in namespace Foo, but it would be
transparent to everyone since if you use something with a fully
qualified name you don't need to use them, right ?
Anyway it's just a couple ideas, but please stop holding on to that
double colon.
--
Jordi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/soap and http header
Dmitry Stogov wrote: Hi Brian, I think you patch does the things you like properly, but why do we need such ability? I don't see a use-case. In case of accepting this patch, we also need to care about duplicate headers. Some web services require custom headers for authentication or to bounce along information about the originating request in order to do proper logging and accounting about which top-level users are causing the backend web services requests. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
Hi, Ok before we all go crazy with the NS separator debate, some reading (which also links to a few interesting posts/sites): http://marc.info/?l=php-internalsm=113313170231815w=2 http://marc.info/?l=php-internalsm=113345477123705w=2 http://marc.info/?l=php-internalsm=117742643931293w=2 I have also emailed Jessie to see if we can somehow resurrect the content on http://www.phpnamespaces.org/ I invite anyone that seriously wants to have that debate again to scavenge through all of that, write a page on the wiki first. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Platform maintainers overview?
Hi, Christian poked me offlist about the rounding patch. While talking about that patch with Johannes I began to wonder if we have any interest in maintaining a page on the wiki (or a README in php-src) with contact information for each OS/CPU/Webserver combination. I guess for Apache on Linux x86 we have all of internals. For windows and IIS we have the windows team (presumably on all CPU variations?). FreeBSD is covered by Yahoo. I guess Sun will eventually cover Sparc. So that leaves other web servers, OS's and CPU's to ..? regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/soap and http header
Hi Rasmus, Rasmus Lerdorf wrote: Dmitry Stogov wrote: Hi Brian, I think you patch does the things you like properly, but why do we need such ability? I don't see a use-case. In case of accepting this patch, we also need to care about duplicate headers. Some web services require custom headers for authentication or to bounce along information about the originating request in order to do proper logging and accounting about which top-level users are causing the backend web services requests. Could you give an example. Thanks. Dmitry. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
2008/9/29 Jordi Boggiano [EMAIL PROTECTED]
On Mon, Sep 29, 2008 at 12:21 AM, Ryan Panning [EMAIL PROTECTED] wrote:
+1, I second this completely
From someone who *was* using namespaces developing against the 5.3
branch,
this is going to happen sooner or later. I found that :: just causes to
many
questions when used in namespaces. Using :: or - just for the sake of
reusing existing tokens is just wrong. I'm in favor of # if it can be
worked
out.
+1 as well, but I must say # is not right, it is a very black/filled
character, as in it doesn't visually#separate#words#that#well. Using
the dot would be really nice, but I guess it would break with
something like this : concat.foo.bar().baz so it's not an option.
Using a single colon might work out ? foo:bar:class::staticFunc()
sounds good to me, but maybe I missed something.
I also had the idea of using the underscore, even though I guess we
can't go through with this as people _might_ have used double
underscores in their class names, I guess it would work out quite well
with single underscores, for example :
class Foo_Bar {
public static function callMe()
}
Foo_Bar::callMe();
..would be read as class Bar in namespace Foo, but it would be
transparent to everyone since if you use something with a fully
qualified name you don't need to use them, right ?
Anyway it's just a couple ideas, but please stop holding on to that
double colon.
--
Jordi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I agree with you totally that :: makes too much trouble - people are trying
to fix all issues for a few month's now and every time it results in we cut
$something then it works! and of course developers as myself start to shout
that we don't need namespaces half implemented, because they are useless
when.
I took part in discussion in two threads by this time:
here: solving the namespace conflict issues between function/static method
class constant/ns constant
AND
here: true namespaces, yet another point of view
Firstly I also proposed . as a separator, but it has issues with constants:
?php
define('CONST', 'hello ');
class Test {
static function print() {
return 'world!';
}
}
echo CONST.Test::print();
?
That now results in hello world!. So if CONST is a namespace and we have
constant named the same - a problem occures. Well, that can be worked around
- we can check for name collision and give an error, but I think people will
shout at that as bad, wy we can't have namespace and constant named equaly?
Well, I would live with that perfectly, but something tells me developers
will be against this.
Other problem is resolution.
MYNAMESPACE.Test::print() - what is it? A constant named MYNAMESPACE or a
namespace itself?
As I understand, during compile time that isn't a problem to resolve whether
it is constant or namespace? Ok, we done that. Then we hit SOMETHING witch
isn't a constant, not namespace. Ups, what error should we give? Undefined
constant or missing namespace? Well, as i think of this - only good solution
is Fatal error, but then any forgottent to be set constant will result in
fatal error. To me that is good - I woun't forget to define any constants!
But as I predict - most will shout that it's too harsh, and they will be
right at some point (I myself started with a Pascal, so to me an undefined
variable === compile error (Fatal error in PHP terms), so it's natural to me
to have a Fatal at this point).
So -1 on .
So . is more suitable than ::, but also has it's problems - easier o
resolve, but problems.
In thouse threads people presented next options for namespace separators:
1). .. as separator. Well, two symbols, has no side effects, but looks
quite strage: namespace A..B::staticMethod(). I don't think it's a good one,
so -1.
2). Someone proposed \ as separator. A\B::staticMethod() - Looks crazy,
isn't it? And we all know, that \ mostly has special meaning in programming
languages as escape character. -1.
3). # Co. A#B::staticMethod() - no side effects, bot looks dirty. -1
from me.
4). ::: or . If ::: makes sence, than that man, who proposed should
be joking. ::: - no side effects, just little more to type. A candidate.
Neither -1, nor +1.
So as prevoius speaker suggested, and I personaly got to conclusion in other
thread that : is ideal. Short, isn't taken.
?php
D:F:G:B:H use A;
A:B::staticMethod();
A:B-test();
:phpversion();
?
Looks great, clearly seen and distinguished from :: .
So maybe it is time to stop arguing and maybe use :? Because it finaly comes
out as good choise in many threads.
Please, think about us - developers! We don't want complicated resoution
rules. We don't want half functional namespaces with only classes or without
constants, ect. And : is something is natural, because we allready have ::
separator for static methods. Easy to understand, handy to use, everybody is
happy. Don't you want that?
+1 for
Re: [PHP-DEV] ext/soap and http header
just curious, why is ext/soap internally duplicating this http stuff
instead of using the http stream stuff directly? or did I
misunderstand something?
Am 29.09.2008 um 10:11 schrieb Dmitry Stogov:
Hi Brian,
I think you patch does the things you like properly, but why do we
need
such ability? I don't see a use-case.
In case of accepting this patch, we also need to care about duplicate
headers.
Thanks. Dmitry.
Brian J. France wrote:
After some more testing I needed to tweak the patch and the example,
here is version 2.
$opts = array('http' = array('header' = 'X-foo: bar'));
$ctx = stream_context_create($opts);
Brian
--- ext/soap/php_http.c.orig2008-09-26 05:39:50.0 -0700
+++ ext/soap/php_http.c2008-09-26 06:42:34.0 -0700
-391,7 +391,8 @@
PG(allow_url_fopen) = old_allow_url_fopen;
if (stream) {
-zval **cookies, **login, **password;
+php_stream_context *context = NULL;
+zval **cookies, **login, **password, **tmpzval = NULL;
int ret = zend_list_insert(phpurl, le_url);
add_property_resource(this_ptr, httpurl, ret);
-638,6 +639,19 @@
proxy_authentication(this_ptr, soap_headers TSRMLS_CC);
}
+/* get context to check for http headers */
+if (SUCCESS == zend_hash_find(Z_OBJPROP_P(this_ptr),
+ _stream_context,
sizeof(_stream_context),
(void**)tmp)) {
+context = php_stream_context_from_zval(*tmp, 0);
+}
+
+/* Send http headers from context */
+if (context
+php_stream_context_get_option(context, http, header,
tmpzval) == SUCCESS
+Z_TYPE_PP(tmpzval) == IS_STRING
Z_STRLEN_PP(tmpzval)) {
+smart_str_appendl(soap_headers, Z_STRVAL_PP(tmpzval),
Z_STRLEN_PP(tmpzval));
+}
+
/* Send cookies along with request */
if (zend_hash_find(Z_OBJPROP_P(this_ptr), _cookies,
sizeof(_cookies), (void **)cookies) == SUCCESS) {
zval **data;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP-DEV] alpha3
I thought that : was rejected because of the terniary operator? I'm not
going to search now for the discussion but for sure there were serious
objections against : , otherwise it would be natural to use it. How you
propose to handle the ambiguities like:
?
print name1:name2?name3:name4:name5:name6;
/*
could mean:
$something?(namespace:namespace:constant) : (constant);
$something?(namespace:constant) : (namespace:constant);
and so on...
*/
?
Parenthesis are a solution, but I have no knoledge of the internal parsing
hence I dont know is it possible.
AFAIK the actual problem with the current implementation with :: is that is
ambigous like:
?
name1::name2();
/*
which could mean:
class::staticcall();
namespace::function();
and so on..
*/
?
My proposal is (if possible/reasonable/performance wise of course) to have a
fatal error thrown when during the parse time the engine discovers
duplicates like the one described above. What is the point to name in the
same way a class and a static method and a namespace and a function in the
same way? In my (very humble) opinion this is the best solution, because we
keep the :: operator that we are familiar with, the ambiguity is resolved
(just not allowing it) and (I guess) the php 5.3 will not be delayed much.
Is there any other logical problem with the namespaces besides this
ambiguity? Have I missed something else?
In fact I'm using a lot the namespaces in their current implementation and
I'm very happy with it. I Never had problems with the ambiguity, because I
never even needed to use duplicated names for the different objects
(classes, constants, static methods, functions).
Vesselin Kenashkov
On Mon, Sep 29, 2008 at 7:05 PM, Arvids Godjuks [EMAIL PROTECTED]wrote:
2008/9/29 Jordi Boggiano [EMAIL PROTECTED]
On Mon, Sep 29, 2008 at 12:21 AM, Ryan Panning [EMAIL PROTECTED]
wrote:
+1, I second this completely
From someone who *was* using namespaces developing against the 5.3
branch,
this is going to happen sooner or later. I found that :: just causes to
many
questions when used in namespaces. Using :: or - just for the sake of
reusing existing tokens is just wrong. I'm in favor of # if it can be
worked
out.
+1 as well, but I must say # is not right, it is a very black/filled
character, as in it doesn't visually#separate#words#that#well. Using
the dot would be really nice, but I guess it would break with
something like this : concat.foo.bar().baz so it's not an option.
Using a single colon might work out ? foo:bar:class::staticFunc()
sounds good to me, but maybe I missed something.
I also had the idea of using the underscore, even though I guess we
can't go through with this as people _might_ have used double
underscores in their class names, I guess it would work out quite well
with single underscores, for example :
class Foo_Bar {
public static function callMe()
}
Foo_Bar::callMe();
..would be read as class Bar in namespace Foo, but it would be
transparent to everyone since if you use something with a fully
qualified name you don't need to use them, right ?
Anyway it's just a couple ideas, but please stop holding on to that
double colon.
--
Jordi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I agree with you totally that :: makes too much trouble - people are trying
to fix all issues for a few month's now and every time it results in we
cut
$something then it works! and of course developers as myself start to
shout
that we don't need namespaces half implemented, because they are useless
when.
I took part in discussion in two threads by this time:
here: solving the namespace conflict issues between function/static method
class constant/ns constant
AND
here: true namespaces, yet another point of view
Firstly I also proposed . as a separator, but it has issues with constants:
?php
define('CONST', 'hello ');
class Test {
static function print() {
return 'world!';
}
}
echo CONST.Test::print();
?
That now results in hello world!. So if CONST is a namespace and we have
constant named the same - a problem occures. Well, that can be worked
around
- we can check for name collision and give an error, but I think people
will
shout at that as bad, wy we can't have namespace and constant named equaly?
Well, I would live with that perfectly, but something tells me developers
will be against this.
Other problem is resolution.
MYNAMESPACE.Test::print() - what is it? A constant named MYNAMESPACE or a
namespace itself?
As I understand, during compile time that isn't a problem to resolve
whether
it is constant or namespace? Ok, we done that. Then we hit SOMETHING witch
isn't a constant, not namespace. Ups, what error should we give? Undefined
constant or missing namespace? Well, as i think of this - only good
solution
is Fatal error, but then any
Re: [PHP-DEV] alpha3
+1 for : from me. Ternary. Operator. Trouble. Otherwise it'd get my vote too. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/soap and http header
David Zülke wrote:
just curious, why is ext/soap internally duplicating this http stuff
instead of using the http stream stuff directly? or did I misunderstand
something?
good question. :)
As I remember php streams weren't able to do all necessary things which
were necessary for ext/soap, but probably they can be reused now.
Thanks. Dmitry.
Am 29.09.2008 um 10:11 schrieb Dmitry Stogov:
Hi Brian,
I think you patch does the things you like properly, but why do we need
such ability? I don't see a use-case.
In case of accepting this patch, we also need to care about duplicate
headers.
Thanks. Dmitry.
Brian J. France wrote:
After some more testing I needed to tweak the patch and the example,
here is version 2.
$opts = array('http' = array('header' = 'X-foo: bar'));
$ctx = stream_context_create($opts);
Brian
--- ext/soap/php_http.c.orig2008-09-26 05:39:50.0 -0700
+++ ext/soap/php_http.c2008-09-26 06:42:34.0 -0700
-391,7 +391,8 @@
PG(allow_url_fopen) = old_allow_url_fopen;
if (stream) {
-zval **cookies, **login, **password;
+php_stream_context *context = NULL;
+zval **cookies, **login, **password, **tmpzval = NULL;
int ret = zend_list_insert(phpurl, le_url);
add_property_resource(this_ptr, httpurl, ret);
-638,6 +639,19 @@
proxy_authentication(this_ptr, soap_headers TSRMLS_CC);
}
+/* get context to check for http headers */
+if (SUCCESS == zend_hash_find(Z_OBJPROP_P(this_ptr),
+ _stream_context, sizeof(_stream_context),
(void**)tmp)) {
+context = php_stream_context_from_zval(*tmp, 0);
+}
+
+/* Send http headers from context */
+if (context
+php_stream_context_get_option(context, http, header,
tmpzval) == SUCCESS
+Z_TYPE_PP(tmpzval) == IS_STRING Z_STRLEN_PP(tmpzval)) {
+smart_str_appendl(soap_headers, Z_STRVAL_PP(tmpzval),
Z_STRLEN_PP(tmpzval));
+}
+
/* Send cookies along with request */
if (zend_hash_find(Z_OBJPROP_P(this_ptr), _cookies,
sizeof(_cookies), (void **)cookies) == SUCCESS) {
zval **data;
--
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
Re: [PHP-DEV] alpha3
On Monday 29 September 2008 18:05:48 Arvids Godjuks wrote: So as prevoius speaker suggested, and I personaly got to conclusion in other thread that : is ideal. Short, isn't taken. $a = $b?A:B:C:D; -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Adding pecl/http to core
Mike, I have a few questions about the API and target use cases. What is the best medium to ask these questions and document them? This thread certainly is not the best place im sure of. Thanks, Ralph Michael Wallner wrote: Jani Taskinen wrote: So pecl/http is actually ext/curl with OO API? Not really. libcurl is not HTTP only, pecl/http utilizes libcurl for it's HTTP request functionality. pecl/http also provides much improved HTTP response and zlib functionality besides an swizz-army-knife for URLs. Why not merge the two then..? Or rather, replace ext/curl with pecl/http once latter has BC API for us non-oo folks out there.. You don't have to write OO code to use pecl/http, neither do you have the possibility to query any protocol other than HTTP with pecl/http. Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
Monday 29 September 2008 18:35:45 Stefan Walk napisał(a): On Monday 29 September 2008 18:05:48 Arvids Godjuks wrote: So as prevoius speaker suggested, and I personaly got to conclusion in other thread that : is ideal. Short, isn't taken. $a = $b?A:B:C:D; Will _you_ write such code? No. Will anybody from this list write such code? No. Will any good PHP developer write such code? No. So why do you think that's a problem? It would be a problem only for people writing such code, and I think that such people will be able to do something stupid with every syntax. PS. Somebody might also write $a = $b ? $c ? true : false ? true : false : true; Does it mean, that ternary is bad? Of course not. PS2. *I* *personally* like :: much more than : and I think, that conflicting namespaced functions and class functions should just result in an error, as has Vesselin Kenashkov suggested. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
On 9/29/08, Stefan Walk [EMAIL PROTECTED] wrote: So as prevoius speaker suggested, and I personaly got to conclusion in other thread that : is ideal. Short, isn't taken. $a = $b?A:B:C:D; It's only a problem when you use fully qualified names inside a ternary operation, and can easily be fixed with parenthesis in this particular case, so it still looks much better than the current situation to me, and I'm pretty sure everyone would agree on using : as a separator if it weren't from that small glitch. The use of parenthesis is not that big a deal if it's restricted to ternary operator uses, there are some places already where you're forced to use them for disambiguation. We could also keep ::foo() as the way to address the global namespace, which might allow $a ? ::foo() : ::bar() without parenthesis ? I don't know enough about the parser to say though. -- Jordi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
So as prevoius speaker suggested, and I personaly got to conclusion in other thread that : is ideal. Short, isn't taken. $a = $b?A:B:C:D; Will _you_ write such code? No. Will anybody from this list write such code? You may want to write $a = $b?A:B:C and how would php compiler resolve A:B:C? A:B vs C or A vs B:C? To me it's better to stay with :: -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
On Mon, 2008-09-29 at 19:24 +0200, Janusz Lewandowski wrote: Monday 29 September 2008 18:35:45 Stefan Walk napisał(a): On Monday 29 September 2008 18:05:48 Arvids Godjuks wrote: So as prevoius speaker suggested, and I personaly got to conclusion in other thread that : is ideal. Short, isn't taken. $a = $b?A:B:C:D; Will _you_ write such code? That's not the point. The point is the parser can't easily identify it - we barely care about namespaces, so someClass :: method ( ) ; is as valid as someClass::method(); independent from the context, same should be true for namespaces and their separator independent from the context. ... but well, that was all discussed multiple times before johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
On Mon, 29 Sep 2008 19:30:00 +0300, Vesselin Kenashkov [EMAIL PROTECTED] wrote: My proposal is (if possible/reasonable/performance wise of course) to have a fatal error thrown when during the parse time the engine discovers duplicates like the one described above. What is the point to name in the same way a class and a static method and a namespace and a function in the same way? In my (very humble) opinion this is the best solution, because we keep the :: operator that we are familiar with, the ambiguity is resolved (just not allowing it) and (I guess) the php 5.3 will not be delayed much. There's nothing familiar about :: to 99.99% of PHP developers who haven't already been playing with the alphas. It has no magical significance in namespace mythos. If the reuse of a symbol is causing problems, change the symbol to one that doesn't cause problems. Finding a symbol that doesn't cause problems may not be a simple task, but please don't pretend that has any special significance to namespaces in concept. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] true namespaces, yet another point of view
For those that do not understand very well the explanation of jvlad...
He's suggesting to change the class struct to be an scope struct, and
have a property that tells if it's a namespace or a class, and reuse
the implementation of class which already works very well.
The nested support is achieved afai understand through the Adjacency
List algorithm... can you confirm this to me?
or just leave the organization of things to classes (with long class
names with a nice prefix to prevent collissions) and leave it to
class_alias() (and equivalent features for functions .. also with the
option of a compile time aliasing) to handle the aliasing.
this removes the need for namespaces and use statements, while making it
possible to make class/function names short (that are long for
organizational and collision prevention reasons).
Hi,
This approach doesn't work because aliasing with class_alias() does not
allow name conflicts:
?php
class foo {
function __construct(){echo 'hi',\n;}}
class_alias('foo', 'XMLReader');
$a = new XMLReader;
?
results in:
Warning: Cannot redeclare class XMLReader in
/home/cellog/workspace/php5/test.php on line 4
?php
class foo {
function __construct(){echo 'hi',\n;}}
use ::foo as XMLReader;
$a = new XMLReader;
?
results in:
hi
I'm sorry I don't see anything related to namespaces in the sample. It looks
like just a trick that allows to bypass restrictions imposed on
class_alias(). If you need to provide a clear way on creating your very own
XMLReader class in the global namespace, while the class with the same name
is already registered by an extension, why not to create
remove_class()/unregister_class() and/or replace_class() functions which
will legitimate class removal/overriding?
Still not sure if it's needed at all. With namespaces, you can create your
own little world inside your private namespace and have as many overrided
classes as you want. Why bother with global namespace?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Platform maintainers overview?
hi! On Mon, Sep 29, 2008 at 5:05 PM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: Christian poked me offlist about the rounding patch. While talking about that patch with Johannes I began to wonder if we have any interest in maintaining a page on the wiki (or a README in php-src) with contact information for each OS/CPU/Webserver combination. I guess for Apache on Linux x86 we have all of internals. For windows and IIS we have the windows team (presumably on all CPU variations?). Almost yes, and definitively all versions of (active) windows or MSFT softwares. FreeBSD is covered by Yahoo. I guess Sun will eventually cover Sparc. So that leaves other web servers, OS's and CPU's to ..? We have one or two PPC boxes making their way to us, more on that once we know how it will work. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Disable PHAR by default
the bug is updated with my comments, i think it's a cgi not phar issue. can u pls have a look soon? thanks -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespace issues
On Tue, Sep 23, 2008 at 11:47:30AM +0400, Dmitry Stogov wrote:
Stanislav Malyshev wrote:
3. Functions will not be allowed inside namespaces. We arrived to
conclusion that they are much more trouble than they're worth, and
summarily we would be better off without them. Most of the functionality
could be easily achieved using static class methods, and the rest may be
emulated with variable function names, etc.
Comments?
3. In case we remove functions we also need to remove constants as they
have exactly the same ambiguity problems.
Classes inside name spaces raise the same issue:
?php
namespace n_1;
class c_1 {
const CNST_1 = constant\n;
public static function f_1() {
echo function\n;
}
}
echo n_1::c_1::CNST_1;
n_1::c_1::f_1();
?
The currently proposed operator is a major problem.
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] solving the namespace conflict issues betweenfunction/staticmethod class constant/ns constant
Hi Greg: On Sun, Sep 28, 2008 at 09:58:25PM -0500, Gregory Beaver wrote: The second highest vote was :::, but there was strong objection to this as well from some. Sounds like you have the tally or know where it is (or you have an excellent memory). Do you have a URI for it, please? Regardless of opposition, it did get the second highest vote count, so has support from several people. The problem, I still believe, is that we are focused on having the same:::stupid:::operator:::between:::everything. ... In truth, it will be a lot easier to debug code if this is a different separator, as the boundary between namespace and element will be crystal clear. For instance: ... my::framework..someFunction()-aProperty-someMethod(); Good points. And thanks for the patch. (Perhaps we can harness the vast amounts of energy inside Greg to resolve our oil dependence?) Regardless of whether we use the same separator between namespaces and the elements or if we just use a different separator between namespaces and the elements, some separator needs to change. Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] solving the namespace conflict issues betweenfunction/staticmethod class constant/ns constant
On Mon, Sep 29, 2008 at 8:36 PM, Daniel Convissor [EMAIL PROTECTED] wrote: Hi Greg: On Sun, Sep 28, 2008 at 09:58:25PM -0500, Gregory Beaver wrote: The second highest vote was :::, but there was strong objection to this as well from some. Sounds like you have the tally or know where it is (or you have an excellent memory). Do you have a URI for it, please? Regardless of opposition, it did get the second highest vote count, so has support from several people. The problem, I still believe, is that we are focused on having the same:::stupid:::operator:::between:::everything. ... In truth, it will be a lot easier to debug code if this is a different separator, as the boundary between namespace and element will be crystal clear. For instance: ... my::framework..someFunction()-aProperty-someMethod(); Good points. And thanks for the patch. (Perhaps we can harness the vast amounts of energy inside Greg to resolve our oil dependence?) Regardless of whether we use the same separator between namespaces and the elements or if we just use a different separator between namespaces and the elements, some separator needs to change. I always liked ~ use some~long~namespace; some~long~namespace~class::function(); some~namespace~function(); some~namespace~$var; new ~ArrayIterator(); Keep up the good work everyone--I'm really looking forward to 5.3. I've already started using the alpha. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
Le lundi 29 septembre 2008 à 13:48 -0500, Larry Garfield a écrit :
On Mon, 29 Sep 2008 19:30:00 +0300, Vesselin Kenashkov [EMAIL PROTECTED]
wrote:
My proposal is (if possible/reasonable/performance wise of course) to have
a
fatal error thrown when during the parse time the engine discovers
duplicates like the one described above. What is the point to name in the
same way a class and a static method and a namespace and a function in the
same way? In my (very humble) opinion this is the best solution, because
we
keep the :: operator that we are familiar with, the ambiguity is resolved
(just not allowing it) and (I guess) the php 5.3 will not be delayed much.
There's nothing familiar about :: to 99.99% of PHP developers who haven't
already been playing with the alphas.
You are forgetting C++ (PHP's oop implementation looks a lot like C++'s
one, and my guess is it was made this way).
Around 40% of the PHP developpers in our team have C++ experience, and
would love to see namespaces in PHP. They don't really care about what
separator is used, but :: is what they already use in C++
You could say C++ is cheating because you *need* to have everything
defined in header files (eg, no autoload) and the lookup is done at
compile time (eg. we can take time to lookup exactly what we are
invoking), so using different operators isn't needed.
Also, unlike . (eg, echo foo.bar will echo foobar because of php's
permissive/compatible behaviour), :: isn't allowed for use anywhere
(unexpected T_PAAMAYIM_NEKUDOTAYIM) and is more suited for namespaces
separations (will not break previously badly-written code).
The current implementation in PHP 5.3.0 is nice, I used it for a few
months (had to adapt my code, like replacing import by use), and I
must say it's working, however if we are to change the namespace
separator by something else, it should have been done 3~4 months ago.
Doing it now may cause problem that we didn't think of in one or two
months, so either PHP 5.3.0 should be delayed and the separator changed,
either it's too late to change that.
Anyway I'd be in favor of the namespace resolution operator stuff like
: (also because it looks like it's smiling ;p )
some::long::namespace:someclass::function();
We see that we have some::long::namespace, and within this namespace we
call function(), which is a method of someclass.
Changing the operator within the namespace is not something wanted, the
goal is to improve calls lookups, and remove ambiguity to avoid cases
like:
namespace foo;
class bar {
function baz() {}
}
namespace foo::bar;
function baz() {}
In this case you have two different functions :
foo:bar::baz();
foo::bar:baz();
In each call, you immediatly see the difference between the namespace
part and the function/class part.
The only part in the implementation which will become a bit more complex
is to resolve a call from a namespace. Eg:
namespace foo;
bar:baz();
bar::baz();
In the first case we need to prefix foo:: and in the second one we
need to prefix foo:.
The good thing is since there's no reason to reference a namespace by
itself, there shouldn't be any problem to guess which separator should
be used.
Mark
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] solving the namespace conflict issues betweenfunction/staticmethod class constant/ns constant
On 30.09.2008, at 05:36, Daniel Convissor wrote: Hi Greg: On Sun, Sep 28, 2008 at 09:58:25PM -0500, Gregory Beaver wrote: The second highest vote was :::, but there was strong objection to this as well from some. Sounds like you have the tally or know where it is (or you have an excellent memory). Do you have a URI for it, please? I linked to one tally (not sure if its the final one) in my recent email: http://marc.info/?l=php-internalsm=113313170231815w=2 The problem, I still believe, is that we are focused on having the same:::stupid:::operator:::between:::everything. ... In truth, it will be a lot easier to debug code if this is a different separator, as the boundary between namespace and element will be crystal clear. For instance: ... my::framework..someFunction()-aProperty-someMethod(); Good points. And thanks for the patch. (Perhaps we can harness the vast amounts of energy inside Greg to resolve our oil dependence?) Regardless of whether we use the same separator between namespaces and the elements or if we just use a different separator between namespaces and the elements, some separator needs to change. This is a dangerous comment. Again to make it clear, with a single separator, whatever it may we, we will still have ambiguity. Only with two different separators as Greg describes can we really solve this problem. But yes, we I presume what you mean to say is that if we want to improve the situation we have to find a second separator. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
