Bug #40837 [Com]: static and non-static functions can't have the same name
Edit report at https://bugs.php.net/bug.php?id=40837&edit=1 ID: 40837 Comment by: dmittner at llnw dot com Reported by:nick dot telford at gmail dot com Summary:static and non-static functions can't have the same name Status: Not a bug Type: Bug Package:Class/Object related Operating System: Irrelevant PHP Version:5.2.1 Block user comment: N Private report: N New Comment: Well, given the lack of similar support in other languages I can see this is an uphill battle not worth a long fight, so I'll leave with this departing thought (plus I doubt this is a proper place to debate merits of functionality changes): When I looked up this similar issue on other languages, I found people asking about it for Java and C#, and the responses fundamentally came down to the same thing: the compiler doesn't understand it. But it was clear that this is something people want in many languages, and I'd put forth that all of them doing it poorly isn't justification not to lead the charge to building a better convention. Fact is, static scope exists separate of instance scope for a reason. And if we're accepting that reason as enough to support both scopes' existence to begin with, why isn't that reason enough to take the next logical step and support resource signatures of the same name for each? Obviously using :: is out of the question and similar limitations in other languages is likely why it's not possible in them, but if we have new operators specifically to separate these, why not do it? Maybe it would put pressure on other languages to add similar support. The only remaining argument against it I could see would be one of code cleanliness and possible confusion having two methods with the same signature, but I'd have to dismiss that as minor (especially compared to overloading signatures in other languages) when there's a clear "static" presence on the method and the new operator on any calls to it. And with that, good day and happy programming. Previous Comments: [2013-04-21 22:34:18] ni...@php.net @dmittner: > ":: is not a "static access operator", it's a "scope resolution operator". It > calls a method (or accesses a property) in a certain scope." > > Conceptually that one operator is trying to do too much. That "certain scope" > it's trying to use isn't chosen by the programmer; it's chosen by the > context; by where it's being used. That's presumptuous and an unnecessary > limitation. Maybe I didn't phrase that well enough. By "in a certain scope" I meant the class before the :: operator. In Foo::bar() the bar() method is called in the Foo scope. So, as you can see the scope *is* chosen by the programmer and no presumption takes place. > "::" is (AFAIK) the only way to access specifically static resources in one > context, but then is also used to reference the resources of special names in > other contexts. Again, this might be a misunderstanding. The scope-resolution behavior is *not* restricted to special names. It's not just about parent::foo() [and self::foo() and static::foo()], I just used that as an example as it is the most commonly used. You can do a scope-resolution call on any class in the inheritance hierarchy (e.g. a grandparent). Actually right now you could even do the call to using a scope that is outside the hierarchy, but thankfully we'll be removing that anti-feature in the next version. What we could obviously do - as you suggest - is strictly decouple scoped static method calls and scoped non-static method calls, by having a Foo::bar() syntax and a Foo->bar() syntax (e.g. parent->bar()). In my eyes that's a bad idea. We'd be adding a lot of new complexity (by making static methods *actually* different and not just a modifier of normal methods) only for the very small gain of having statics and non-statics of the same name. By the way, I just looked at a few other languages and it seems like nearly all went the same way as PHP. C++ doesn't allow it, C# doesn't allow it, Java doesn't allow it. Python doesn't really have statics, but it has the @staticmethod decorator and with that it's obviously not allowed either. The only language I looked at and which *does* support this is Ruby. So, I really don't see a solid case for this feature request. [2013-04-21 21:47:20] billco at fnarg dot com My thoughts echo those of dmittner, while I think we all acknowledge the need for parent::method() functionality, I don't see why that small detail should invalidate this popular feature request. This seems like a limitation borrowed from C++, where it was a necessary evil of supporting multiple inheritance. PHP does not have MI and thus there was never a need fo
Bug #40837 [Com]: static and non-static functions can't have the same name
Edit report at https://bugs.php.net/bug.php?id=40837&edit=1 ID: 40837 Comment by: ni...@php.net Reported by:nick dot telford at gmail dot com Summary:static and non-static functions can't have the same name Status: Not a bug Type: Bug Package:Class/Object related Operating System: Irrelevant PHP Version:5.2.1 Block user comment: N Private report: N New Comment: @dmittner: > ":: is not a "static access operator", it's a "scope resolution operator". It > calls a method (or accesses a property) in a certain scope." > > Conceptually that one operator is trying to do too much. That "certain scope" > it's trying to use isn't chosen by the programmer; it's chosen by the > context; by where it's being used. That's presumptuous and an unnecessary > limitation. Maybe I didn't phrase that well enough. By "in a certain scope" I meant the class before the :: operator. In Foo::bar() the bar() method is called in the Foo scope. So, as you can see the scope *is* chosen by the programmer and no presumption takes place. > "::" is (AFAIK) the only way to access specifically static resources in one > context, but then is also used to reference the resources of special names in > other contexts. Again, this might be a misunderstanding. The scope-resolution behavior is *not* restricted to special names. It's not just about parent::foo() [and self::foo() and static::foo()], I just used that as an example as it is the most commonly used. You can do a scope-resolution call on any class in the inheritance hierarchy (e.g. a grandparent). Actually right now you could even do the call to using a scope that is outside the hierarchy, but thankfully we'll be removing that anti-feature in the next version. What we could obviously do - as you suggest - is strictly decouple scoped static method calls and scoped non-static method calls, by having a Foo::bar() syntax and a Foo->bar() syntax (e.g. parent->bar()). In my eyes that's a bad idea. We'd be adding a lot of new complexity (by making static methods *actually* different and not just a modifier of normal methods) only for the very small gain of having statics and non-statics of the same name. By the way, I just looked at a few other languages and it seems like nearly all went the same way as PHP. C++ doesn't allow it, C# doesn't allow it, Java doesn't allow it. Python doesn't really have statics, but it has the @staticmethod decorator and with that it's obviously not allowed either. The only language I looked at and which *does* support this is Ruby. So, I really don't see a solid case for this feature request. Previous Comments: [2013-04-21 21:47:20] billco at fnarg dot com My thoughts echo those of dmittner, while I think we all acknowledge the need for parent::method() functionality, I don't see why that small detail should invalidate this popular feature request. This seems like a limitation borrowed from C++, where it was a necessary evil of supporting multiple inheritance. PHP does not have MI and thus there was never a need for such a contrived "scope resolution" operator when something like Java's "super" would have sufficed. I can recognize that its usage dates back to the very beginning of PHP OOP, and it would be problematic to change the :: operator with all the existing code out there. Why can't we choose a new operator for pure static calls and get on with it ? It sounds like that would allow same-named static methods without ambiguity, while allowing the :: operator to continue as-is. [2013-04-21 18:57:01] dmittner at llnw dot com @ni...@php.net: While what you write is all technically correct, I think it comes down to this being the problem: ":: is not a "static access operator", it's a "scope resolution operator". It calls a method (or accesses a property) in a certain scope." Conceptually that one operator is trying to do too much. That "certain scope" it's trying to use isn't chosen by the programmer; it's chosen by the context; by where it's being used. That's presumptuous and an unnecessary limitation. "::" is (AFAIK) the only way to access specifically static resources in one context, but then is also used to reference the resources of special names in other contexts. Clearly people want to be able to call the same method name in both an object and static scope. It's the same reason people like function overloading: they have logic that accomplishes the same goal but done differently--this time based on scope. And we'd rather not dirty our code with resource names named differently just to identify scope. If the :: operator can't consistently serve this purpose because it's also having to accommodate "parent" and other special
Bug #40837 [Com]: static and non-static functions can't have the same name
Edit report at https://bugs.php.net/bug.php?id=40837&edit=1 ID: 40837 Comment by: billco at fnarg dot com Reported by:nick dot telford at gmail dot com Summary:static and non-static functions can't have the same name Status: Not a bug Type: Bug Package:Class/Object related Operating System: Irrelevant PHP Version:5.2.1 Block user comment: N Private report: N New Comment: My thoughts echo those of dmittner, while I think we all acknowledge the need for parent::method() functionality, I don't see why that small detail should invalidate this popular feature request. This seems like a limitation borrowed from C++, where it was a necessary evil of supporting multiple inheritance. PHP does not have MI and thus there was never a need for such a contrived "scope resolution" operator when something like Java's "super" would have sufficed. I can recognize that its usage dates back to the very beginning of PHP OOP, and it would be problematic to change the :: operator with all the existing code out there. Why can't we choose a new operator for pure static calls and get on with it ? It sounds like that would allow same-named static methods without ambiguity, while allowing the :: operator to continue as-is. Previous Comments: [2013-04-21 18:57:01] dmittner at llnw dot com @ni...@php.net: While what you write is all technically correct, I think it comes down to this being the problem: ":: is not a "static access operator", it's a "scope resolution operator". It calls a method (or accesses a property) in a certain scope." Conceptually that one operator is trying to do too much. That "certain scope" it's trying to use isn't chosen by the programmer; it's chosen by the context; by where it's being used. That's presumptuous and an unnecessary limitation. "::" is (AFAIK) the only way to access specifically static resources in one context, but then is also used to reference the resources of special names in other contexts. Clearly people want to be able to call the same method name in both an object and static scope. It's the same reason people like function overloading: they have logic that accomplishes the same goal but done differently--this time based on scope. And we'd rather not dirty our code with resource names named differently just to identify scope. If the :: operator can't consistently serve this purpose because it's also having to accommodate "parent" and other special names, then maybe we just need a new operator specifically for calling methods in a static scope and ONLY for doing that. The more I think about this the more I think :: is just broken because it's treated inconsistently. There's probably good reasons I'm not thinking of, but it seems :: could have always meant "static scope" and "->" could have always meant "object scope"; and "parent->resource" would have been valid right alongside "parent::resource", each accessing the parent's resource in legitimately different scopes. So leave :: as it is for backwards compatibility. Add support for "->" on special names for object scope and a new operator specifically for static scope. Then we'll be able to define both object-scope and static-scope versions of the same resources and we'll have operators to access each consistently. Ultimately it's not a huge deal. It'd just be nice to be able to use the same names in both scopes. But we can at least achieve the functionality for now by naming everything "$staticVariable" and "staticMethod()". It's just really gross. [2013-04-21 09:40:32] ni...@php.net We *can not* have static and non-static methods with the same name. This is *not* just a backwards compatibility concern. I think the issue here is that you got the meaning of the :: operator wrong. :: is not a "static access operator", it's a "scope resolution operator". It calls a method (or accesses a property) in a certain scope. E.g. Foo::bar() calls the method bar() in the scope of class Foo. bar() here can be any method. A "static" method just means that the method does not need $this. The Foo::bar() call will only work if a) the method is static or b) the method is non-static and we have a $this. The distinction between "static access operator" and "scope resolution operator" is important and helps you understand why some things are as they are. For example, if you want to access a parent method, then what do you write? parent::foo(). This means that you call foo() in the parent scope. I get that people might argue whether "calling non-static methods with ::" is useful in the general case, but calling parent methods is something everybody should understand and find useful. And using that example it's also easy
Bug #44999 [Com]: 0 equals any string
Edit report at https://bugs.php.net/bug.php?id=44999&edit=1 ID: 44999 Comment by: contact at caus909 dot net Reported by:ethan dot nelson at ltd dot org Summary:0 equals any string Status: Not a bug Type: Bug Package:Scripting Engine problem Operating System: windows 2003 PHP Version:5.2.6 Block user comment: N Private report: N New Comment: Maybe because that's not a bug... "It's not a bug, it's a feature". Equality (==) and identity (===) are different, if for your use, equality is the best, just use it then. Previous Comments: [2013-02-14 16:49:14] radamanf at gmail dot com I can see that it's no any logical explanation to keep this BUG unfixed! Status: Not a bug -> why??? It's not funny, so many years past. I do love to use PHP and like that no needed to define variable types, but this is generic FAIL. Come one guys, someone need to fix this, please. My PHP version PHP 5.3.10-1ubuntu3.5 with Suhosin-Patch (cli) (built: Jan 18 2013 23:45:59) [2012-08-24 08:16:07] bugs dot php dot net at simoneast dot net This is quite ridiculous. Can this 'feature' of PHP *please* be reconsidered? [2008-05-14 22:25:51] ethan dot nelson at ltd dot org I don't recall PHP ever behaving that way. So how do you alter a switch statement to use the identical operator instead of equivalency? It seems somewhat odd that any text character would be equvalent to integer 0. As I remember the chart it was something like: 0 == '0' true 0 == '' true 0 == null true 0 == false true 0 == 'text' false Basically if we are going to treat any string as equivalent to 0, the switch statement becomes useless when iterating through arrays unless you first strip key names of integer 0. [2008-05-14 22:20:01] cel...@php.net see Bug #44990 for explanation [2008-05-14 21:51:49] ethan dot nelson at ltd dot org Description: Right now, 0 compared to any string will prove true. Reproduce code: --- Expected result: False Actual result: -- True -- Edit this bug report at https://bugs.php.net/bug.php?id=44999&edit=1
Bug #63201 [Com]: PHP 5.4 and Function Overloading
Edit report at https://bugs.php.net/bug.php?id=63201&edit=1 ID: 63201 Comment by: sjaillet at gmail dot com Reported by:brainreflex at gmail dot com Summary:PHP 5.4 and Function Overloading Status: Open Type: Bug Package:Unknown/Other Function Operating System: OS X 10.7.5 PHP Version:5.4.7 Block user comment: N Private report: N New Comment: It's pretty annoying since this feature allowed a king of monkey patching in PHP 5.3 for writing tests cases. With PHP 5.4 & 5.5, redefining functions only work in the same file like in the follwing example: Previous Comments: [2013-04-20 00:50:18] sjaillet at gmail dot com Looks like it's an introduced bug since redefining functions still works well when functions had been called in the same file like the following : [2012-10-02 15:26:53] brainreflex at gmail dot com Description: 5.4 doesn't allow to redefine function if bult-in function had been called before. It's a bug or omission of documentation For more details look at http://vatson.com.ua/blog/2012/10/01/php-5-dot-4-and- function-overloading/ Test script: --- https://github.com/vatson/php-experiments Expected result: The same behavior for both versions -- Edit this bug report at https://bugs.php.net/bug.php?id=63201&edit=1
Bug #40837 [Com]: static and non-static functions can't have the same name
Edit report at https://bugs.php.net/bug.php?id=40837&edit=1
ID: 40837
Comment by: dmittner at llnw dot com
Reported by:nick dot telford at gmail dot com
Summary:static and non-static functions can't have the same
name
Status: Not a bug
Type: Bug
Package:Class/Object related
Operating System: Irrelevant
PHP Version:5.2.1
Block user comment: N
Private report: N
New Comment:
@ni...@php.net:
While what you write is all technically correct, I think it comes down to this
being the problem:
":: is not a "static access operator", it's a "scope resolution operator". It
calls a method (or accesses a property) in a certain scope."
Conceptually that one operator is trying to do too much. That "certain scope"
it's trying to use isn't chosen by the programmer; it's chosen by the context;
by where it's being used. That's presumptuous and an unnecessary limitation.
"::" is (AFAIK) the only way to access specifically static resources in one
context, but then is also used to reference the resources of special names in
other contexts.
Clearly people want to be able to call the same method name in both an object
and static scope. It's the same reason people like function overloading: they
have logic that accomplishes the same goal but done differently--this time
based
on scope. And we'd rather not dirty our code with resource names named
differently just to identify scope.
If the :: operator can't consistently serve this purpose because it's also
having to accommodate "parent" and other special names, then maybe we just need
a new operator specifically for calling methods in a static scope and ONLY for
doing that.
The more I think about this the more I think :: is just broken because it's
treated inconsistently. There's probably good reasons I'm not thinking of, but
it seems :: could have always meant "static scope" and "->" could have always
meant "object scope"; and "parent->resource" would have been valid right
alongside "parent::resource", each accessing the parent's resource in
legitimately different scopes.
So leave :: as it is for backwards compatibility.
Add support for "->" on special names for object scope and a new operator
specifically for static scope. Then we'll be able to define both object-scope
and static-scope versions of the same resources and we'll have operators to
access each consistently.
Ultimately it's not a huge deal. It'd just be nice to be able to use the same
names in both scopes. But we can at least achieve the functionality for now by
naming everything "$staticVariable" and "staticMethod()". It's just really
gross.
Previous Comments:
[2013-04-21 09:40:32] ni...@php.net
We *can not* have static and non-static methods with the same name. This is
*not* just a backwards compatibility concern.
I think the issue here is that you got the meaning of the :: operator wrong. ::
is not a "static access operator", it's a "scope resolution operator". It calls
a method (or accesses a property) in a certain scope.
E.g. Foo::bar() calls the method bar() in the scope of class Foo. bar() here
can be any method.
A "static" method just means that the method does not need $this. The
Foo::bar() call will only work if
a) the method is static or
b) the method is non-static and we have a $this.
The distinction between "static access operator" and "scope resolution
operator" is important and helps you understand why some things are as they
are. For example, if you want to access a parent method, then what do you write?
parent::foo(). This means that you call foo() in the parent scope.
I get that people might argue whether "calling non-static methods with ::" is
useful in the general case, but calling parent methods is something everybody
should understand and find useful. And using that example it's also easy to see
why you couldn't have the same static and non-static method. Consider this
small example:
class A {
public function foo() { echo 'non-static'; }
public static function foo() { echo 'static'; }
}
class B {
public function bar() { echo parent::foo(); }
}
(new B)->bar(); // What do you get?
Allowing static and non-static methods of the same name would require us to
completely change the concept of scope-resolution and find a different way to
call parent methods etc.
So, just to say it again: Removing "::"-calls to non-static methods is *not*
just a backwards compatibility issue, it would also cause problems with other,
currently used and encouraged language features.
Another thing that might help the understanding (apart from interpreting :: as
scope-resolution) is not seeing static and non-static methods as distinct
method types. Rather they are the same and "static" is just another method
modifier li
Bug #64684 [Com]: FILEINFO_MIME_ENCODING fail
Edit report at https://bugs.php.net/bug.php?id=64684&edit=1 ID: 64684 Comment by: rg at mejoramos dot com Reported by:rg at mejoramos dot com Summary:FILEINFO_MIME_ENCODING fail Status: Feedback Type: Bug Package:*Directory/Filesystem functions Operating System: Windoqs and Linux PHP Version:5.3.24 Assigned To:ab Block user comment: N Private report: N New Comment: Thanks by you interest. You can see ALL DETAIL by download: http://utp.guirv.com/descargas/?f=/PHP_BUG_64684.rar (318 bits) When you run in Windows: Warning: finfo_file(): Failed identify data 0:(null) in E:\HTTP... ...\PHP_BUG_64684\fileinfo.php on line 3 When you run in Linux CentOs: Warning: finfo_file() [function.finfo-file]: Failed identify data 0:(null) in /home/... .../PHP_BUG_64684/fileinfo.php on line 3 Previous Comments: [2013-04-21 16:28:56] a...@php.net I can't reproduce this using your snippet, I get us-ascii and that will be it in any case. For that I've created a file containing just 0. And, you might anyway be interested on the next 5.4 release as libmagic was upgraded, or already test the latest windows snapshot from http://windows.php.net/downloads/snaps/php-5.4/ . To reproduce this issue a reliable snippet in required. [2013-04-20 14:28:05] rg at mejoramos dot com Description: If FILE have contain exactly the string: "0" without quotes, then: in Windows output: Warning: finfo_file(): Failed identify data 0:(null) in ... in Linux output: Warning: finfo_file() [function.finfo-file]: Failed identify data 0:(null) in ... Why file have a "0" ? becouse I need read a integer in range 0-25 to take some decisions... Why I run finfo_file() ? Becouse I need know if last edition create UTF8 or ISO-8859-1 Test script: --- echo 'Encoding: '.finfo_file($finfo,$_FILES['name_in_FORM']['tmp_name'],FILEINFO_MIME_ENCODING); Remember: target file contain only the string: "0" without quotes. -- Edit this bug report at https://bugs.php.net/bug.php?id=64684&edit=1
Doc->Bug #64688 [Opn]: crypt doesn't truncate salt correctly for EXT_DES
Edit report at https://bugs.php.net/bug.php?id=64688&edit=1 ID: 64688 User updated by:chaos-master at gmx dot de Reported by:chaos-master at gmx dot de Summary:crypt doesn't truncate salt correctly for EXT_DES Status: Open -Type: Documentation Problem +Type: Bug Package:*Encryption and hash functions Operating System: GNU/Linux PHP Version:5.3.24 Block user comment: N Private report: N New Comment: changed bug type: doc -> bug Previous Comments: [2013-04-21 16:47:33] chaos-master at gmx dot de Description: --- >From manual page: >http://www.php.net/function.crypt#refsect1-function.crypt-examples --- The documentation for the crypt()-function asks to provide the complete hash as salt in order to verify a given hash. However if the given hash is an EXT_DES Hash this doesn't work correctly Test script: --- Expected result: $6$Rp.sVGo.zbHnQds.$I/mOIzdGE8g53MGbCe8gPcOdUMX.BiGz8Nx9HMa0UDKacGscGIAu.H75iG5U0d/niZk76y/LLHtHKZL9VdEZY0 $6$Rp.sVGo.zbHnQds.$I/mOIzdGE8g53MGbCe8gPcOdUMX.BiGz8Nx9HMa0UDKacGscGIAu.H75iG5U0d/niZk76y/LLHtHKZL9VdEZY0 _6C/.jjzcoAyXu0Z0XlM _6C/.jjzcoAyXu0Z0XlM _6C/.jjzcoAyXu0Z0XlM Actual result: -- $6$Rp.sVGo.zbHnQds.$I/mOIzdGE8g53MGbCe8gPcOdUMX.BiGz8Nx9HMa0UDKacGscGIAu.H75iG5U0d/niZk76y/LLHtHKZL9VdEZY0 $6$Rp.sVGo.zbHnQds.$I/mOIzdGE8g53MGbCe8gPcOdUMX.BiGz8Nx9HMa0UDKacGscGIAu.H75iG5U0d/niZk76y/LLHtHKZL9VdEZY0 _6C/.jjzcoAyXu0Z0XlM _6T7pAW9oacXQ _6C/.jjzcoAyXu0Z0XlM -- Edit this bug report at https://bugs.php.net/bug.php?id=64688&edit=1
Bug #64684 [Opn->Fbk]: FILEINFO_MIME_ENCODING fail
Edit report at https://bugs.php.net/bug.php?id=64684&edit=1 ID: 64684 Updated by: a...@php.net Reported by:rg at mejoramos dot com Summary:FILEINFO_MIME_ENCODING fail -Status: Open +Status: Feedback Type: Bug Package:*Directory/Filesystem functions Operating System: Windoqs and Linux PHP Version:5.3.24 Block user comment: N Private report: N New Comment: I can't reproduce this using your snippet, I get us-ascii and that will be it in any case. For that I've created a file containing just 0. And, you might anyway be interested on the next 5.4 release as libmagic was upgraded, or already test the latest windows snapshot from http://windows.php.net/downloads/snaps/php-5.4/ . To reproduce this issue a reliable snippet in required. Previous Comments: [2013-04-20 14:28:05] rg at mejoramos dot com Description: If FILE have contain exactly the string: "0" without quotes, then: in Windows output: Warning: finfo_file(): Failed identify data 0:(null) in ... in Linux output: Warning: finfo_file() [function.finfo-file]: Failed identify data 0:(null) in ... Why file have a "0" ? becouse I need read a integer in range 0-25 to take some decisions... Why I run finfo_file() ? Becouse I need know if last edition create UTF8 or ISO-8859-1 Test script: --- echo 'Encoding: '.finfo_file($finfo,$_FILES['name_in_FORM']['tmp_name'],FILEINFO_MIME_ENCODING); Remember: target file contain only the string: "0" without quotes. -- Edit this bug report at https://bugs.php.net/bug.php?id=64684&edit=1
[PHP-BUG] Req #64687 [NEW]: Implements __empty() and __equals()
From: lpu8er at gmail dot com Operating system: PHP version: 5.5.0beta3 Package: *General Issues Bug Type: Feature/Change Request Bug description:Implements __empty() and __equals() Description: For convenience, we should be able to use objects at any time, including into the language constructs. Java implements .equals() in order to compare objects. Such a request already exists, but in a single comment: http://www.php.net/manual/en/language.oop5.object-comparison.php#85769 The basic/default behavior (fallback) for such a method would be same as actual. The proto would be: public function __equals(stdOject $comparisonObject) and couldn't be called statically. In the same way, having some __empty() method would be fine, which would act as empty() for the basic/default behavior. -- Edit bug report at https://bugs.php.net/bug.php?id=64687&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64687&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64687&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64687&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64687&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64687&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64687&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64687&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64687&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64687&r=support Expected behavior: https://bugs.php.net/fix.php?id=64687&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64687&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64687&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64687&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64687&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64687&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64687&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64687&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64687&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64687&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64687&r=mysqlcfg
Bug #64395 [Com]: Wrong result
Edit report at https://bugs.php.net/bug.php?id=64395&edit=1
ID: 64395
Comment by: sjon at hortensius dot net
Reported by:abc905 at mail dot ru
Summary:Wrong result
Status: Open
Type: Bug
Package:Network related
Operating System: Windows 7 x64
PHP Version:5.4.13
Block user comment: N
Private report: N
New Comment:
Php interprets numbers with leading zeros as octal [1]. Octal 011 = Decimal 9.
Also, I think this is not a valid IP address notation.
This is fixed in newer PHP versions, where this format is rejected and false is
returned; see http://3v4l.org/EBD9k
1. http://php.net/manual/en/language.types.integer.php
Previous Comments:
[2013-03-28 15:48:28] abc905 at mail dot ru
PHP. Ver. 5.4.13 (Open Server Win7 x64)
Output:
1.1.011.011 -> 1.1.9.9
1.1.071.071 -> 1.1.57.57
1.1.081.081 -> 0.0.0.0
Looks like long2ip() converts segments with leading zero as octal.
[2013-03-21 16:11:01] abc905 at mail dot ru
Unfortunatly my output is wrong
PHP. Ver. 5.4.11 (Open Server Win7 x64) and 5.4.9 (Windows Installer install)
Output:
1.1.011.011 -> 1.1.9.9
1.1.071.071 -> 1.1.57.57
1.1.081.081 -> 0.0.0.0
Looks like long2ip() converts segments with leading zero as octal.
[2013-03-17 02:39:34] pete at petermcdonald dot co dot uk
I have tried to reproduce on php 5.4.11 (zend server install) using code
specified
but output is expected 1.1.11.11.
[2013-03-08 19:54:51] abc905 at mail dot ru
Description:
Hello,
It seems ip2long function returns wrong result
1.1.9.9 instead of 1.1.11.11 when convert ip address like '1.1.011.011'
Thank you,
Alexander
---
>From manual page: http://www.php.net/function.long2ip
---
Test script:
---
$ip = '1.1.011.011';
$ip_long = sprintf("%u", ip2long($ip));
print long2ip($ip_long);
--
Edit this bug report at https://bugs.php.net/bug.php?id=64395&edit=1
Bug #39493 [Com]: simplexml_load_file does not obey default stream context
Edit report at https://bugs.php.net/bug.php?id=39493&edit=1
ID: 39493
Comment by: hanskrentel at yahoo dot de
Reported by:RQuadling at GMail dot com
Summary:simplexml_load_file does not obey default stream
context
Status: Not a bug
Type: Bug
Package:SimpleXML related
Operating System: Windows XP SP2
PHP Version:5CVS-2006-11-13 (snap)
Block user comment: N
Private report: N
New Comment:
I know this feedback is later, to whom it may concern: Setting the stream
context
in libxml is possible via:
libxml_set_streams_context()
See http://php.net/libxml_set_streams_context for more information. This is
probably still worth to have this documented here in the issue tracker.
Previous Comments:
[2006-11-13 14:09:35] RQuadling at GMail dot com
What about open_basedir, and other file access restrictions?
Is it possible that all the security used within PHP can be bypassed using this
library?
A potential security risk surely!
But, as you mentioned libxml, this can be solved by using
libxml_set_streams_context.
So, whereas I've got ...
$r_default_context = stream_context_get_default
(
array
(
'http' => array
(
'proxy' => 'tcp://127.0.0.1:8080',
'request_fulluri' => True,
),
)
);
I can add ...
libxml_set_streams_context($r_default_context);
I think.
Testing ...
Yep!
I'll be adding a user notes relating to this as it stumped me!
Thanks for the help.
Maybe, with windows being used more and more for PHP, this should be a
documentation issue?
[2006-11-13 10:29:27] tony2...@php.net
simplexml_load_file() is just a wrapper for libxml2 functions, which apparently
know nothing about stream context etc.
[2006-11-13 10:14:54] RQuadling at GMail dot com
Description:
I'm behind a MS ISA server using NTLM Authentication which is unsupported by
PHP.
To allow PHP through, I use Python and the NTLM Authentication Proxy Server
(further details for this at http://rquadling.php1h.com).
I then use an auto_prepend_file entry to include a default context assignment
to route http traffic to my the proxy.
This works fine for both CLI and ISAPI operations.
The simplexml_load_file() function does not have a context facility. It also
does not use the same mechanism to get data OR it is ignoring the default
context setup.
The example code is just to show the error.
If you are NOT using contexts or you are have direct access to the outside
world, then you will not see the problem.
My NTLM APS logs do not show 2 requests to the external data. Only 1 - the
file_get_contents() call.
Reproduce code:
---
array
( // All HTTP requests are passed through the local
NTLM proxy server on port 8080.
'proxy' => 'tcp://127.0.0.1:8080',
'request_fulluri' => True,
),
)
);
echo file_get_contents('http://www.people.com.cn/rss/politics.xml');
$xml = simplexml_load_file('http://www.people.com.cn/rss/politics.xml');
?>
Expected result:
╣·─┌ð┬╬┼
http://politics.people.com.cn
zh_CN
Copyright ? 1997-2006 by www.people.com.cn. all rights
reserved
2006-11-13 16:40:00
[SNIP]
2006-11-13 16:43:03
Actual result:
--
╣·─┌ð┬╬┼
http://politics.people.com.cn
zh_CN
Copyright ? 1997-2006 by www.people.com.cn. all rights
reserved
2006-11-13 16:40:00
[SNIP]
2006-11-13 16:43:03
Warning: simplexml_load_file(http://www.people.com.cn/rss/politics.xml): failed
to open stream: HTTP request failed! HTTP/1.1 403 Forbidden ( The ISA Server
denies the specified Uniform Resource Locator (URL). )
in C:\noCX.php on line 16
Warning: simplexml_load_file(): I/O warning : failed to load external entity
"http://www.people.com.cn/rss/politics.xml"; in C:\noCX.php on line 16
--
Edit this bug report at https://bugs.php.net/bug.php?id=39493&edit=1
Bug #55544 [Com]: ob_gzhandler always conflicts with zlib.output_compression
Edit report at https://bugs.php.net/bug.php?id=55544&edit=1 ID: 55544 Comment by: sweet_philippe at hotmail dot com Reported by:diogin at gmail dot com Summary:ob_gzhandler always conflicts with zlib.output_compression Status: Closed Type: Bug Package:Output Control Operating System: Windows XP SP3 x86 PHP Version:5.4.0alpha3 Assigned To:laruence Block user comment: N Private report: N New Comment: Problems occurs for me on : php-5.4.13-1.fc18.x86_64 + httpd-2.4.4-2.fc18.x86_64 and php-5.4.11-1.fc18.x86_64 + httpd-2.4.3-15.fc18.x86_64 zlib.output_compression = Off in php.ini With apache mod_deflate on or off it is the same. Any advise to fix it please ? Previous Comments: [2012-07-29 11:36:22] knorge at gmx dot de I want to test the mentioned snapshot but none of the links are working on this page: http://windows.php.net/snapshots/ Where have they gone? I am using Win7 x64 and this bug is driving me crazy for some time. Will it be finally fixed in PHP 5.4.6? [2012-07-24 23:39:52] ras...@php.net Automatic comment on behalf of mike Revision: http://git.php.net/?p=php-src.git;a=commit;h=8f857603b462c123c7b10191c691c0d0f2a6acbc Log: Fixed bug #55544 ob_gzhandler always conflicts with zlib.output_compression [2012-07-24 12:22:45] bugs dot php at mohiva dot com Now, it works for me. [2012-07-24 06:55:04] larue...@php.net re-fixed agian... [2012-07-24 06:44:41] larue...@php.net Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=4c1e2bbd6f744b4048d4e0540ecc5dbe005494fe Log: Re-fix bug #55544 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=55544 -- Edit this bug report at https://bugs.php.net/bug.php?id=55544&edit=1
Bug #40837 [Com]: static and non-static functions can't have the same name
Edit report at https://bugs.php.net/bug.php?id=40837&edit=1
ID: 40837
Comment by: ni...@php.net
Reported by:nick dot telford at gmail dot com
Summary:static and non-static functions can't have the same
name
Status: Not a bug
Type: Bug
Package:Class/Object related
Operating System: Irrelevant
PHP Version:5.2.1
Block user comment: N
Private report: N
New Comment:
We *can not* have static and non-static methods with the same name. This is
*not* just a backwards compatibility concern.
I think the issue here is that you got the meaning of the :: operator wrong. ::
is not a "static access operator", it's a "scope resolution operator". It calls
a method (or accesses a property) in a certain scope.
E.g. Foo::bar() calls the method bar() in the scope of class Foo. bar() here
can be any method.
A "static" method just means that the method does not need $this. The
Foo::bar() call will only work if
a) the method is static or
b) the method is non-static and we have a $this.
The distinction between "static access operator" and "scope resolution
operator" is important and helps you understand why some things are as they
are. For example, if you want to access a parent method, then what do you write?
parent::foo(). This means that you call foo() in the parent scope.
I get that people might argue whether "calling non-static methods with ::" is
useful in the general case, but calling parent methods is something everybody
should understand and find useful. And using that example it's also easy to see
why you couldn't have the same static and non-static method. Consider this
small example:
class A {
public function foo() { echo 'non-static'; }
public static function foo() { echo 'static'; }
}
class B {
public function bar() { echo parent::foo(); }
}
(new B)->bar(); // What do you get?
Allowing static and non-static methods of the same name would require us to
completely change the concept of scope-resolution and find a different way to
call parent methods etc.
So, just to say it again: Removing "::"-calls to non-static methods is *not*
just a backwards compatibility issue, it would also cause problems with other,
currently used and encouraged language features.
Another thing that might help the understanding (apart from interpreting :: as
scope-resolution) is not seeing static and non-static methods as distinct
method types. Rather they are the same and "static" is just another method
modifier like "public" or "final":
You probably wouldn't ask to have "an abstract method and a final method of the
same name", right? Asking for a non-static and static method of the same name
makes similarly little sense. "static" just means "doesn't need $this" and
nothing more.
On a related note, this "static" modifier is also available for closures (i.e.
you can write "$foo = static function() { ... }") and also means the same
there, that the closure does not need $this. Prefixing a closure with "static"
does not make it some kind of wholly different function type, it's just a
modifier. Same for the static methods ;)
I hope things are a bit clearer now.
Previous Comments:
[2013-04-21 05:30:23] dmittner at llnw dot com
I've got to add my vote to this feature.
My use case consists of data validation methods. If called statically the
validation tests are limited to things like string length, contents, etc. If
called on an object it would include those tests (probably calling the static
form of itself) and also comparative tests to other object conditions.
I sympathize with backwards compatibility but sometimes you have to push
forward. Case and point, some people I know are working with a Java-based
system
that doesn't support Java 7, so when building new servers they have to
explicitly install an older version. Cutting a line between major PHP versions
seems similarly viable.
I'd also cite Magic Quotes which are completely removed in 5.4, which could
similarly break older PHP4 compatibility. The precedent is set.
Failing all that, how about a configuration option?
[2012-11-20 02:13:10] capitaine dot gloumi at gmail dot com
The "backward compatibility" should set to deprecated any static call of object
method, and use it IF NO static method with the same name exist.
I use static method and object method with same name in lot of paterns, it's
useful in lot of case.
[2012-11-19 03:27:35] ahar...@php.net
If a class is namespaced, by definition it isn't PHP 4 compatible.
[2012-11-15 23:23:31] jpmarois at hotmail dot com
ahar..
