Req #61182 [Com]: Assume Opening PHP Tag
Edit report at https://bugs.php.net/bug.php?id=61182&edit=1
ID: 61182
Comment by: dmittner at llnw dot com
Reported by:tom at tomwardrop dot com
Summary:Assume Opening PHP Tag
Status: Wont fix
Type: Feature/Change Request
Package:*Configuration Issues
PHP Version:5.4.0RC8
Block user comment: N
Private report: N
New Comment:
I have to agree with the sentiment.
Standard convention seems to be to exclude the close tag on PHP-only files, but
I find it fundamentally flawed and improper syntax to have an unclosed tag. I
just can't look at a PHP file with it excluded and see it as "clean".
That said, I'd support an initiative to change the nature of the open tag--
either through its removal or changing it to something else identifiable as a
PHP "starter" that's clearly not an opening tag.
I also find it completely viable for this to be a server-level option, or
something that can be toggled through Apache on a per-vhost basis.
There's a few logical paths I can think of:
1. If the file's extension is .php then ASSUME it's pure PHP, but if there's a "
" (or something else) as a first-line identifier of a pure
PHP file
There are plenty of ways to evolve " tag (which
thankfully is optional), any white-space or otherwise non-printable characters
before the opening tag can cause "headers sent" issues. You could solve that
problem by implementing the ignore white-space rule I've already mentioned,
where any white-space before the opening tag is ignored.
The more I think about this and talk to the others, the more it becomes
apparent
that what I'm actually asking for, is a distinction to made between PHP
templates, and PHP scripts/applications. If PHP were to define these two
distinct concepts, then you could do more than just make the opening tag
optional. For example, you could have a template() or render() method to act as
an include() for php templates. Unlike include() however, this render() method
would return the output of the file, instead of sending it straight to the
browser. This would negate the need to capture template output using the output
buffer functions (something that I believe most frameworks end up using).
Making such a distinction would also allow web servers like Apache to treat PHP
files differently. You may create a rule in Apache to render all .phpt files as
PHP templates, rendering everything else as PHP script or application files. We
may then see mod_php implement an application mode, where one can define a
single-point of entry into their application. This could have flow-on
performance benefits, where mod_php could cache the parsed PHP, then either
fork
it on each request, or instantiate a new application class. Such a feature
would
mean frameworks wouldn't have to stuff around with .htaccess files, and would
mean that programmers don't need to add the following to the top of all their
files: if (defined('SOME_CONSTANT')) exit;
While there's momentum among the PHP developers to move forward with
modernising
the language, I think now would be a good idea to consider some of these more
fundamental changes. PHP's built-in template engine, ease of deployment, and
it's dynamic, traditional OO constructs would still remain PHP's strengths.
With all this said, I'd be happy to save such changes to a major release
intended to break legacy code, like PHP 6. I'd like to keep in mind too that
code portability isn't relevant to most people who don't intend to release
their
code as open source. Typically, those people using PHP in a business context
have control of their server. It's only shared hosting environments where
portability becomes a potential issue. All I'm saying is don't rule out ideas
based on the lowest common denominator.
[2012-02-25 14:12:03] phpmpan at mpan dot pl
After a bit of thinking I came to a conclusion that PHARs can, in theory, have
such thing implemented. Some metadata may be included in PHAR to tell PHP that
every source file in the archive assumes "https://bugs.php.net/bug.php?id=61182
--
Edit this bug report at https://bugs.php.net/bug.php?id=61182&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: 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 d
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 b
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: 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? Previous Comments: [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...@php.net: Sure, go Microsoft's way and move forward by staying behind for the sake of "compatibility". Please explain why, "As of PHP 5.3.3, methods with the same name as the last element of a namespaced class name will no longer be treated as constructor.". If PHP wont even initialize a "compatible" PHP 4 class anymore, how is it relevant to preserve instance methods being called statically? [2012-09-11 01:59:54] ahar...@php.net It breaks compatibility with any PHP 4 compatible code that uses static method calls. That's (obviously) less important than it once was, but there's still plenty of legacy code out there. [2012-09-10 15:29:23] mac at macnewbold dot com ahar...@php.net : What would the impacts be of deprecating static calls to non-static methods? They would seem to not make much sense, since any uses of $this inside the method (which would be pretty typical since it is a non-static method) would fail with "Fatal error: Using $this when not in object context". What is the value of being able to attempt a static call on a non-static method? 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=40837 -- Edit this bug report at https://bugs.php.net/bug.php?id=40837&edit=1
Bug #51126 [Com]: class_exists + namespaces
Edit report at https://bugs.php.net/bug.php?id=51126&edit=1
ID: 51126
Comment by: dmittner at llnw dot com
Reported by:richard at rjharrison dot org
Summary:class_exists + namespaces
Status: Bogus
Type: Bug
Package:SPL related
Operating System: linux
PHP Version:5.3.1
Block user comment: N
Private report: N
New Comment:
I agree that this behavior is counter-intuitive. I seem to have just run into
the same problem, myself, where my autoload works just fine where
class_exists() returns false.
In short... class_exists() should really infer the given namespace of the
current file, just like it's inferred in all other uses.
Previous Comments:
[2010-02-23 19:02:17] richard at rjharrison dot org
Hi Johannes,
I double-checked the documentation and found no mention that the string passed
to class_exists() must be fully qualified. Perhaps this is a documentation bug.
It is certainly seems inconsistent/counter-intuitive:-
class_exists('Things\Car'); // FALSE, class does not exist
$car = new Things\Car(); // HUH? Class does exist after all
So PHP is able to figure out there is a "use Foo/Things" namespace in effect on
one line, but not on the other? Lame.
[2010-02-23 18:46:01] johan...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
When used as a string we need the fully qualified name as we don't know where
the parameter is coming from.
[2010-02-23 18:41:57] richard at rjharrison dot org
Description:
class_exists() is not calling my spl_autoload_register'ed function with a fully
qualified (namespaced) class name.
Because the input to my autoload function is not fully qualified, it cannot
load the class and class_exists return false; however, if I try to instantiate
the class that "does not exist" then the correct, fully qualified class now
passed to the autoloader: it correctly loads the class and my code works.
Reproduce code:
---
// register my autoloader
use Foo\Things;
// This fails: my autoload function is called with $class = 'Things\Car'
if(class_exists('Things\Car')){
echo "class exists!";
}else{
echo "Weird?";
}
// This works: my autoload function is called with $class = 'Foo\Things\Car'
$x = new Things\Car();
Expected result:
"class exists!"
Actual result:
--
"Weird?"
--
Edit this bug report at https://bugs.php.net/bug.php?id=51126&edit=1
#44686 [Opn]: SOAP-ERROR: Parsing WSDL
ID: 44686
User updated by: dmittner at llnw dot com
Reported By: dmittner at llnw dot com
Status: Open
Bug Type: SOAP related
Operating System: Gentoo
PHP Version: 5.2.5
New Comment:
I've narrowed it down, I think.
Relevant excerpts from the WSDL:
...
...
No "name" is specified in the upper block of XML, for the line with the
"ref=". If I specify a name the WSDL parses. I believe the correct
behavior would be for PHP to acquire the name from the complexType
declaration. I don't know if this should always be the case for
references, or only when no name is provided - if providing a name is
even valid for them.
This is just a guess, though. I've dealt very little with references so
do not know the standards surrounding them; only what digging into the
XML has revealed.
Previous Comments:
----
[2008-04-11 05:54:01] dmittner at llnw dot com
I have also found this to occur on PHP 5.0.5, also on Gentoo.
----
[2008-04-10 23:52:37] dmittner at llnw dot com
Description:
Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
Schema: unresolved element 'ref' attribute.
C# generated WSDL. I saw an older bug with similar characteristics, but
that was 4 years old, supposedly resolved, and on a different OS.
Several validators I tried are able to consume the WSDL.
Reproduce code:
---
http://gpn.webservice.gomez.com/GpnProvisioningService/ProvisioningWS.asmx?wsdl";;
$soap = new
SoapClient($wsdl,array("trace"=>true,"features"=>SOAP_SINGLE_ELEMENT_ARRAYS));
?>
Expected result:
No explicit output.
Actual result:
--
Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
Schema: unresolved element 'ref' attribute in /home/dmittner/temp.php:3
Stack trace:
#0 /home/dmittner/temp.php(3):
SoapClient->SoapClient('http://gpn.webs...', Array)
#1 {main}
thrown in /home/dmittner/temp.php on line 3
--
Edit this bug report at http://bugs.php.net/?id=44686&edit=1
#44686 [Opn]: SOAP-ERROR: Parsing WSDL
ID: 44686
User updated by: dmittner at llnw dot com
Reported By: dmittner at llnw dot com
Status: Open
Bug Type: SOAP related
Operating System: Gentoo
PHP Version: 5.2.5
New Comment:
I have also found this to occur on PHP 5.0.5, also on Gentoo.
Previous Comments:
[2008-04-10 23:52:37] dmittner at llnw dot com
Description:
Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
Schema: unresolved element 'ref' attribute.
C# generated WSDL. I saw an older bug with similar characteristics, but
that was 4 years old, supposedly resolved, and on a different OS.
Several validators I tried are able to consume the WSDL.
Reproduce code:
---
http://gpn.webservice.gomez.com/GpnProvisioningService/ProvisioningWS.asmx?wsdl";;
$soap = new
SoapClient($wsdl,array("trace"=>true,"features"=>SOAP_SINGLE_ELEMENT_ARRAYS));
?>
Expected result:
No explicit output.
Actual result:
--
Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
Schema: unresolved element 'ref' attribute in /home/dmittner/temp.php:3
Stack trace:
#0 /home/dmittner/temp.php(3):
SoapClient->SoapClient('http://gpn.webs...', Array)
#1 {main}
thrown in /home/dmittner/temp.php on line 3
--
Edit this bug report at http://bugs.php.net/?id=44686&edit=1
#44686 [NEW]: SOAP-ERROR: Parsing WSDL
From: dmittner at llnw dot com
Operating system: Gentoo
PHP version: 5.2.5
PHP Bug Type: SOAP related
Bug description: SOAP-ERROR: Parsing WSDL
Description:
Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
Schema: unresolved element 'ref' attribute.
C# generated WSDL. I saw an older bug with similar characteristics, but
that was 4 years old, supposedly resolved, and on a different OS. Several
validators I tried are able to consume the WSDL.
Reproduce code:
---
http://gpn.webservice.gomez.com/GpnProvisioningService/ProvisioningWS.asmx?wsdl";;
$soap = new
SoapClient($wsdl,array("trace"=>true,"features"=>SOAP_SINGLE_ELEMENT_ARRAYS));
?>
Expected result:
No explicit output.
Actual result:
--
Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
Schema: unresolved element 'ref' attribute in /home/dmittner/temp.php:3
Stack trace:
#0 /home/dmittner/temp.php(3):
SoapClient->SoapClient('http://gpn.webs...', Array)
#1 {main}
thrown in /home/dmittner/temp.php on line 3
--
Edit bug report at http://bugs.php.net/?id=44686&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44686&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44686&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44686&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44686&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44686&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44686&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44686&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44686&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44686&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44686&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44686&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44686&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44686&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44686&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44686&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44686&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44686&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44686&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44686&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44686&r=mysqlcfg
