Re: [PHP-DEV] Bogus Error Message?
On Thu, 26 Feb 2004, John Coggeshall wrote:
>
> $reflect = new Reflection_Class("Object");
>
> $docs = $reflect->getDocComment();
> if(!empty($docs)) {
> echo "Has Docs.\n";
> }
>
> if(!empty($reflect->getDocComment())) {
> echo "Has Docs.\n";
> }
>
> ?>
>
> [EMAIL PROTECTED] ]$ php test.php
>
> Fatal error: Can't use method return value in write context in test.php
> on line 10
>
> Since when is empty() writing anything? Or is there something else here
> that I'm not seeing?
empty() can only be used on variables, RTFM: http://nl.php.net/empty
but I do agree that the message is bogus...
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Declaration of Bar::__construct() must be compatible
Hey, I'd like to come to some conclusion about the latest changes which break BC (trying to keep it short because some people here wrote long essays and it took me too much time to catch up :) : a) I agree that it doesn't make much sense for constructors, because one always creates concrete classes. b) I think we pretty much all agree that the change is correct but it might be a bit too aggressive for certain people (such as people using var_args) and definitely too aggressive for existing code. c) Concerning the differentiating between interfaces and inheritance, in general, I believe these are exactly the same thing and should behave equally. However, we do have a luxury of doing whatever we want when it comes to interfaces and abstract classes because they didn't exist in PHP 4, though treating them differently than inheritance will be a bit inconsistent. d) Last problem is that using E_STRICT is not a good idea because we find this problem at compile-time and the error_reporting might not be set yet. What I suggest is the following: a) Don't check signature for constructors. b) By default, don't check signature for inheritance *if* we're not inheriting from an abstract class. If it is an abstract class we should check the signature because it's a PHP 5 feature. c) Add a new INI option (zend.strict_inheritance_checks) which does check signature for methods (except for constructor). I don't like new INI options but I don't think there's any way out. Comments? (Please try to keep them short :) Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Declaration of Bar::__construct() must be compatible
On 27 Feb 2004 at 11:12, Andi Gutmans wrote: > Comments? (Please try to keep them short :) I think we should just drop the signature check. Interfaces may include a signature for better readability but the engine should ignore them. PHP4 class trees work fine even without strict inheritance checks. Because of PHP's loose character, we cannot force the user to use the strict signature anyway. And since we have no overloading support, but var_args, strict checks make not much sense to me. -- Ferdinand Beyer <[EMAIL PROTECTED]> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Declaration of Bar::__construct() must be compatible
AG>> c) Add a new INI option (zend.strict_inheritance_checks) which AG>> does check signature for methods (except for constructor). I AG>> don't like new INI options but I don't think there's any way AG>> out. There's a dilemma about this option. On one hand, it should be on by default. Otherwise, people would code for default configuration, it would work for default, but misteriously fail on some setups. If it's default, one would have to code so that signatures are OK and it would work on both default and non-default. But this way it makes the option a bit of pointless except as a way to preserve old code running. On the other hand, most big shops would have to set it to off when they move to PHP5 otherwise everybody would cry "PHP5 broke my code". Tricky. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Declaration of Bar::__construct() must be compatible
On Friday 27 February 2004 10:41, Ferdinand Beyer wrote: > On 27 Feb 2004 at 11:12, Andi Gutmans wrote: > > Comments? (Please try to keep them short :) > > I think we should just drop the signature check. Interfaces may > include a signature for better readability but the engine should ignore > them. PHP4 class trees work fine even without strict inheritance > checks. Mhm. Does a signature make sense if the engine ignores it anyway? For better readability one can use phpdoc/doxygen like comment blocks. > Because of PHP's loose character, we cannot force the user to use > the strict signature anyway. And since we have no overloading > support, but var_args, strict checks make not much sense to me. Agree. > -- > Ferdinand Beyer > <[EMAIL PROTECTED]> cheers, Pat -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Declaration of Bar::__construct() must be compatible
On 27 Feb 2004 at 10:58, Patrick Schnorbus wrote: > Mhm. Does a signature make sense if the engine ignores it anyway? > For better readability one can use phpdoc/doxygen like comment blocks. That's right. But I don't see a reason why we should disallow to use a signature in an interface declaration even if it is ignored. -- Ferdinand Beyer <[EMAIL PROTECTED]> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Declaration of Bar::__construct() must be compatible
== Quote from Andi Gutmans ([EMAIL PROTECTED])'s article > a) Don't check signature for constructors. Constructors are definitely not virtual methods. So no reason to check signature. Moreover, this is a non sense to declare constructors in interfaces or abstract constructors in abstract classes. > b) By default, don't check signature for inheritance *if* we're not > inheriting from an abstract class. If it is an abstract class we should > check the signature because it's a PHP 5 feature. I assume "abstract class" includes interfaces. > c) Add a new INI option (zend.strict_inheritance_checks) which does check > signature for methods (except for constructor). I don't like new INI > options but I don't think there's any way out. Because we could discover some other compatibility problems when moving to PHP5, what about an INI option using flags, same as error_reporting. For exemple zend.php5_compat and one of it's flag NO_STRICT_INHERITANCE. Another flag could be SET_CLONE to have "$obj2 = $obj;" or "foo($obj);" compatible with PHP4 (a clone rather than a reference). Indeed I think there will be some side effects when executing some PHP4 code under PHP5. Regards, Stephane -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Declaration of Bar::__construct() must be
Andi Gutmans wrote:
b) By default, don't check signature for inheritance *if* we're not
inheriting from an abstract class. If it is an abstract class we should
check the signature because it's a PHP 5 feature.
Do you mean :
- check the signature only for methods which were in the abstract class
(I hope it is this solution)
or
- check the signature for all methods if a class is inheriting from an
abstract (assuming that if it uses an abstract somewhere then we are not
in compatibility and we can use the strict checks for all the class
methods except constructor)
Exemple of what I mean is below :
abstract class myAbstract {
public function fromAbstract() ;
}
interface myInterface {
public function fromInterface() ;
}
class myClass extends myAbstract implements myInterface {
public function fromAbstract() {
// ... ** If I understand correctly we check signature for this one
}
public function fromInterface() {
// ... ** If I understand correctly we check signature for this one
}
public function otherMethod() {
// ...
}
}
class myInheritedCLass extends myClass {
public function otherMethod() {
// ... ** Do web check signature of this one ?
}
public function fromAbstract() {
// ... ** If I understand correctly we check signature for this one
}
public function fromInterface() {
// ... ** If I understand correctly we check signature for this one
}
}
> c) Add a new INI option (zend.strict_inheritance_checks)
Will it be possible to override it at runtime with ini_set() ? (even if
it will not be necessary if it is disable per default)
--
Eric
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Declaration of Bar::__construct() must be compatible
On Friday 27 February 2004 10:12, Andi Gutmans wrote: > What I suggest is the following: > a) Don't check signature for constructors. Okie ;) > b) By default, don't check signature for inheritance *if* we're not > inheriting from an abstract class. > If it is an abstract class we should > check the signature because it's a PHP 5 feature. Yeah, for abstract classes the checks are fine and there won't be any compliance problems. > c) Add a new INI option (zend.strict_inheritance_checks) which does check > signature for methods (except for constructor). I don't like new INI > options but I don't think there's any way out. Me neither, worse luck. But we should name the option something like zend.legacy_compat for other potential compliance problems like cloning. (At the time of writing i see Stephane Drouard made a similalar suggestion). This option needs to be set by default, but we should make clear that it won't be default for ever. > > Comments? (Please try to keep them short :) > > Andi cheers, Pat -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Declaration of Bar::__construct() must be compatible
On Friday 27 February 2004 11:12, Ferdinand Beyer wrote: > On 27 Feb 2004 at 10:58, Patrick Schnorbus wrote: > > Mhm. Does a signature make sense if the engine ignores it > > anyway? > > > For better readability one can use phpdoc/doxygen like comment > > blocks. > > That's right. But I don't see a reason why we should disallow to use a > signature in an interface declaration even if it is ignored. Well, since signature checks a PHP5 feature, i don't see a way to drop them. With PHP5, PHP becomes much less loose (e.g. class type hints). If we allow "dummy" signatures now, we will have the same problem again in the future. We have to decide _now_ where we want to go (well, i think we have already decided). Perl currently drops some legacy, too - perhaps the time is not that bad to do this as well... > -- > Ferdinand Beyer > <[EMAIL PROTECTED]> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: PATCH: operator precedence test and some wordsize stuff]
Jan Lehnardt wrote: your patch contains more than just the new testcase. That's probably the reason, why it wasn't committed yet. That's why it says '... and some wordsize stuff' in the subject line. -- Ard -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Declaration of Bar::__construct() must be compatible
On Fri, 27 Feb 2004, Andi Gutmans wrote: > d) Last problem is that using E_STRICT is not a good idea because we find > this problem at compile-time and the error_reporting might not be set yet. The INI system is 'booted' before the script is compiled, so I doubt that this is a problem. > What I suggest is the following: > a) Don't check signature for constructors. > b) By default, don't check signature for inheritance *if* we're not > inheriting from an abstract class. If it is an abstract class we should > check the signature because it's a PHP 5 feature. ack and ack > c) Add a new INI option (zend.strict_inheritance_checks) which does check > signature for methods (except for constructor). I don't like new INI > options but I don't think there's any way out. I'm against adding another INI setting. I don't see why we need to force this OO purist thing on all long time users at all. What is wrong by showing an e_notice/e_warning for it in non-compat mode, and e_strict in compat mode (or just e_strict in both cases)? Then PHP still tells you that you do something wrong, but it won't break any code. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] stdClass
Please can some explain to me what the stdClass is used for in PHP 5. I've tried to use the reflection API to reverse engineer it but it does not give you much on the stdClass What methods can be inherited from this class? Does it work the same was as the java base class - Object?
Re: [PHP-DEV] Declaration of Bar::__construct() must be compatible
On Feb 27, 2004, at 4:12 AM, Andi Gutmans wrote: Hey, I'd like to come to some conclusion about the latest changes which break BC (trying to keep it short because some people here wrote long essays and it took me too much time to catch up :) : a) I agree that it doesn't make much sense for constructors, because one always creates concrete classes. To play devil's advocate, If I'm creating objects through a factory, the unified constructor signature is very helpful. d) Last problem is that using E_STRICT is not a good idea because we find this problem at compile-time and the error_reporting might not be set yet. PHP is plagued with this problem though (if you consider it a problem, I think it's a feature). This is not the only warning in PHP that is suppressed at compile time if your error settings aren't set correctly. What I suggest is the following: a) Don't check signature for constructors. I like that. b) By default, don't check signature for inheritance *if* we're not inheriting from an abstract class. If it is an abstract class we should check the signature because it's a PHP 5 feature. I'm iffy on that, but it's certainly better than the current situation. c) Add a new INI option (zend.strict_inheritance_checks) which does check signature for methods (except for constructor). I don't like new INI options but I don't think there's any way out. I prefer E_STRICT warnings unconditionally. The new ini suffers from all the issues ini settings do (hinders portable code). George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Declaration of Bar::__construct() must be compatible
George Schlossnagle wrote: On Feb 27, 2004, at 4:12 AM, Andi Gutmans wrote: Hey, I'd like to come to some conclusion about the latest changes which break BC (trying to keep it short because some people here wrote long essays and it took me too much time to catch up :) : a) I agree that it doesn't make much sense for constructors, because one always creates concrete classes. To play devil's advocate, If I'm creating objects through a factory, the unified constructor signature is very helpful. So put a constructor declaration into the interface and have that one validated. Cheers, Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Declaration of Bar::__construct() must be compatible
On Fri, 2004-02-27 at 14:13, Derick Rethans wrote: > On Fri, 27 Feb 2004, Andi Gutmans wrote: > > > d) Last problem is that using E_STRICT is not a good idea because we find > > this problem at compile-time and the error_reporting might not be set yet. > > The INI system is 'booted' before the script is compiled, so I doubt > that this is a problem. > > > What I suggest is the following: > > a) Don't check signature for constructors. > > b) By default, don't check signature for inheritance *if* we're not > > inheriting from an abstract class. If it is an abstract class we should > > check the signature because it's a PHP 5 feature. > > ack and ack > > > c) Add a new INI option (zend.strict_inheritance_checks) which does check > > signature for methods (except for constructor). I don't like new INI > > options but I don't think there's any way out. > > I'm against adding another INI setting. I don't see why we need to force > this OO purist thing on all long time users at all. What is wrong by > showing an e_notice/e_warning for it in non-compat mode, and e_strict in > compat mode (or just e_strict in both cases)? Then PHP still tells you > that you do something wrong, but it won't break any code. What is worse is that many PHP 4 APIs need to be completely redesigned for PHP 5, not only the guts of the class. IMHO method overloading the the only clean way out of this. - Stig -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] stdClass
On Fri, 2004-02-27 at 14:15, Jakes wrote: > Please can some explain to me what the stdClass is used for in > PHP 5. I've tried to use the reflection API to reverse engineer it > but it does not give you much on the stdClass > > What methods can be inherited from this class? > > Does it work the same was as the java base class - Object? No. There is no such thing as Java's base class built into PHP. stdClass is just an empty "dummy class" that is used internally, for example if you cast an array to an object. You can also use stdClass if you need an object of no particular class. - Stig -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] stdClass
Hi, > > Please can some explain to me what the stdClass is used for in > > PHP 5. I've tried to use the reflection API to reverse engineer it > > but it does not give you much on the stdClass > No. There is no such thing as Java's base class built into PHP. > stdClass is just an empty "dummy class" that is used internally, for > example if you cast an array to an object. You can also use > stdClass if > you need an object of no particular class. Just one thing to add: It has been also available in PHP4. Stephan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Fw: [PHP-DOC] #27345 [Opn]: Status header with PHP CGI
Can anybody clarify this, please?
Nuno
- Original Message -
> ID: 27345
> Updated by: [EMAIL PROTECTED]
> Reported By: php_bugs at ecora dot de
> Status: Open
> Bug Type:Documentation problem
> PHP Version: Irrelevant
> New Comment:
>
> I couldn't reproduce this in PHP 5.
>
> header("HTTP/1.0 404 Not Found"); print "Status: 404"
>
> and
>
> header("Status: 404 Not Found"); prints "Status: 404 Not Found"
>
>
> Can anybody check this in PHP 4?
>
>
> Previous Comments:
>
>
> [2004-02-22 05:10:36] php_bugs at ecora dot de
>
> Description:
>
> Hi,
>
>
> header("HTTP/1.0 404 Not Found");
> [...]
> Note: In PHP 3, this only works when PHP is compiled as an Apache
> module. You can achieve the same effect using the Status header.
> header("Status: 404 Not Found");
>
>
> IMHO this is not correct. Because the HTTP-status-header (also
> Content-Type- and Location-Header) is always a server parsed header,
> when PHP (PHP3, PHP4, PHP5 or also Perl or Python, ...) runs via CGI.
>
> The official CGI Specification (see http://www.w3.org/CGI/):
> http://hoohoo.ncsa.uiuc.edu/cgi/out.html
>
> That means not only in PHP3 also in PHP4 or PHP5: When PHP runs via
> CGI, then you have to write:
> header("Status: 404 Not Found"); instead of header("HTTP/1.0 404 Not
> Found");
>
>
>
>
> Reproduce code:
> ---
> When i try to send a header("HTTP/1.0 404 Not Found"); on my
> installation (Apache 1.3.29 + PHP 4.2.3 CGI on Linux) then i receive a
> 500 internal server error
>
>
>
>
>
>
> --
> Edit this bug report at http://bugs.php.net/?id=27345&edit=1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] stdClass
It would be nice to have a base class to inherit some special methods as we do in Java. The same as method overloading, one of the most important aspects missing in PHP5 and the new object model. Thanks. - Original Message - From: "Stephan Schmidt" <[EMAIL PROTECTED]> Newsgroups: php.internals To: "'Jakes'" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, February 27, 2004 3:46 PM Subject: RE: [PHP-DEV] stdClass > Hi, > > > > Please can some explain to me what the stdClass is used for in > > > PHP 5. I've tried to use the reflection API to reverse engineer it > > > but it does not give you much on the stdClass > > No. There is no such thing as Java's base class built into PHP. > > stdClass is just an empty "dummy class" that is used internally, for > > example if you cast an array to an object. You can also use > > stdClass if > > you need an object of no particular class. > > Just one thing to add: > It has been also available in PHP4. > > Stephan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] stdClass
Jakes Potgieter wrote: It would be nice to have a base class to inherit some special methods as we do in Java. [...] What would be useful methods contained in the base class? Thanks. - Original Message - From: "Stephan Schmidt" <[EMAIL PROTECTED]> Newsgroups: php.internals To: "'Jakes'" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, February 27, 2004 3:46 PM Subject: RE: [PHP-DEV] stdClass Hi, Please can some explain to me what the stdClass is used for in PHP 5. I've tried to use the reflection API to reverse engineer it but it does not give you much on the stdClass No. There is no such thing as Java's base class built into PHP. stdClass is just an empty "dummy class" that is used internally, for example if you cast an array to an object. You can also use stdClass if you need an object of no particular class. Just one thing to add: It has been also available in PHP4. Stephan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] stdClass
Jakes Potgieter wrote: It would be nice to have a base class to inherit some special methods as we do in Java. could you name which ones you think of? being out of the JAVA camp for several years know i no longer know all java.object methods and properties by heart, but PHP mechanisms like __sleep()/__wakeup(), __toString() and the introspection related functions like get_class() and friends should provide comparable behaviour ... (IMHO the fact that any object in JAVA can be casted down to java.object is not that clever after all, and part of it is only due to the fact that there is no other way to have portable container classes, which is now finally solved with generics) The same as method overloading, one of the most important aspects missing in PHP5 and the new object model. due to the feature of optional parameters you may end up with more than one overloaded function matching a call signature, due to the fact that argument types in a function call are not known at compile time signature matching would have to happen at runtime, and the language syntax would need to be extended to add parameter type specifiers to function parameter declarations (ok, we already have this one for interfaces ...) -- Hartmut Holzgraefe <[EMAIL PROTECTED]> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] stdClass
When Im talking about something like this would come in handy
obviously doesnt work! The paramter null could be added, to get
desired result but to be programmatically correct:
class MyOverload{
function __construct($Foo) {
$this->Foo = $Foo;
}
// overload the constructor
function __construct(String $Foo, String $Bar){
$this->Foo = $Foo;
$this->Bar = $Bar;
}
public function doSomething(){
if($this->Foo != null && $this->Bar == null){
return $this->Foo . " needs a partner";
// do something with Foo
}elseif($this->Foo != null && $this->Bar != null){
return $this->Foo . " and " . $this->Bar . " are partners";//do
something with Foo and Bar
}
}
private $Foo;
private $Bar;
}
$obj = new MyOverload("Mary");
print $obj->doSomething();
- Original Message -
From: "Hartmut Holzgraefe" <[EMAIL PROTECTED]>
To: "Jakes Potgieter" <[EMAIL PROTECTED]>
Cc: "Stephan Schmidt" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, February 27, 2004 4:20 PM
Subject: Re: [PHP-DEV] stdClass
> Jakes Potgieter wrote:
> > It would be nice to have a base class to inherit some special
> > methods as we do in Java.
>
> could you name which ones you think of?
>
> being out of the JAVA camp for several years know i no longer
> know all java.object methods and properties by heart, but
> PHP mechanisms like __sleep()/__wakeup(), __toString() and
> the introspection related functions like get_class() and
> friends should provide comparable behaviour ...
>
> (IMHO the fact that any object in JAVA can be casted down
> to java.object is not that clever after all, and part of it
> is only due to the fact that there is no other way to have
> portable container classes, which is now finally solved
> with generics)
>
> > The same as method overloading,
> > one of the most important aspects missing in PHP5 and the
> > new object model.
>
> due to the feature of optional parameters you may end up with
> more than one overloaded function matching a call signature,
> due to the fact that argument types in a function call
> are not known at compile time signature matching would have
> to happen at runtime,
> and the language syntax would need to be extended to add
> parameter type specifiers to function parameter declarations
> (ok, we already have this one for interfaces ...)
>
> --
> Hartmut Holzgraefe <[EMAIL PROTECTED]>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] stdClass
Oh, yes and special methods that you mentioned would come in handy too
but from a object perspective. Maybe explicitly calling some sort finalize()
method to clean un-referenced objects would also be handy.
- Original Message -
From: "Jakes Potgieter" <[EMAIL PROTECTED]>
Newsgroups: php.internals
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; "Stephan Schmidt" <[EMAIL PROTECTED]>
Sent: Friday, February 27, 2004 4:42 PM
Subject: Re: [PHP-DEV] stdClass
> When Im talking about something like this would come in handy
> obviously doesnt work! The paramter null could be added, to get
> desired result but to be programmatically correct:
>
> class MyOverload{
>function __construct($Foo) {
> $this->Foo = $Foo;
>}
>// overload the constructor
>function __construct(String $Foo, String $Bar){
> $this->Foo = $Foo;
> $this->Bar = $Bar;
>}
>public function doSomething(){
> if($this->Foo != null && $this->Bar == null){
> return $this->Foo . " needs a partner";
> // do something with Foo
> }elseif($this->Foo != null && $this->Bar != null){
> return $this->Foo . " and " . $this->Bar . " are partners";
//do
> something with Foo and Bar
> }
>}
>private $Foo;
>private $Bar;
> }
>
> $obj = new MyOverload("Mary");
> print $obj->doSomething();
>
>
> - Original Message -
> From: "Hartmut Holzgraefe" <[EMAIL PROTECTED]>
> To: "Jakes Potgieter" <[EMAIL PROTECTED]>
> Cc: "Stephan Schmidt" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Friday, February 27, 2004 4:20 PM
> Subject: Re: [PHP-DEV] stdClass
>
>
> > Jakes Potgieter wrote:
> > > It would be nice to have a base class to inherit some special
> > > methods as we do in Java.
> >
> > could you name which ones you think of?
> >
> > being out of the JAVA camp for several years know i no longer
> > know all java.object methods and properties by heart, but
> > PHP mechanisms like __sleep()/__wakeup(), __toString() and
> > the introspection related functions like get_class() and
> > friends should provide comparable behaviour ...
> >
> > (IMHO the fact that any object in JAVA can be casted down
> > to java.object is not that clever after all, and part of it
> > is only due to the fact that there is no other way to have
> > portable container classes, which is now finally solved
> > with generics)
> >
> > > The same as method overloading,
> > > one of the most important aspects missing in PHP5 and the
> > > new object model.
> >
> > due to the feature of optional parameters you may end up with
> > more than one overloaded function matching a call signature,
> > due to the fact that argument types in a function call
> > are not known at compile time signature matching would have
> > to happen at runtime,
> > and the language syntax would need to be extended to add
> > parameter type specifiers to function parameter declarations
> > (ok, we already have this one for interfaces ...)
> >
> > --
> > Hartmut Holzgraefe <[EMAIL PROTECTED]>
> >
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] stdClass
Jakes wrote:
Oh, yes and special methods that you mentioned would come in handy too
but from a object perspective. Maybe explicitly calling some sort finalize()
method to clean un-referenced objects would also be handy.
How does that differ from $x=null; with a reference-counting garbage
collector?
Cheers,
Michael
- Original Message -
From: "Jakes Potgieter" <[EMAIL PROTECTED]>
Newsgroups: php.internals
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; "Stephan Schmidt" <[EMAIL PROTECTED]>
Sent: Friday, February 27, 2004 4:42 PM
Subject: Re: [PHP-DEV] stdClass
When Im talking about something like this would come in handy
obviously doesnt work! The paramter null could be added, to get
desired result but to be programmatically correct:
class MyOverload{
function __construct($Foo) {
$this->Foo = $Foo;
}
// overload the constructor
function __construct(String $Foo, String $Bar){
$this->Foo = $Foo;
$this->Bar = $Bar;
}
public function doSomething(){
if($this->Foo != null && $this->Bar == null){
return $this->Foo . " needs a partner";
// do something with Foo
}elseif($this->Foo != null && $this->Bar != null){
return $this->Foo . " and " . $this->Bar . " are partners";
//do
something with Foo and Bar
}
}
private $Foo;
private $Bar;
}
$obj = new MyOverload("Mary");
print $obj->doSomething();
- Original Message -
From: "Hartmut Holzgraefe" <[EMAIL PROTECTED]>
To: "Jakes Potgieter" <[EMAIL PROTECTED]>
Cc: "Stephan Schmidt" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, February 27, 2004 4:20 PM
Subject: Re: [PHP-DEV] stdClass
Jakes Potgieter wrote:
It would be nice to have a base class to inherit some special
methods as we do in Java.
could you name which ones you think of?
being out of the JAVA camp for several years know i no longer
know all java.object methods and properties by heart, but
PHP mechanisms like __sleep()/__wakeup(), __toString() and
the introspection related functions like get_class() and
friends should provide comparable behaviour ...
(IMHO the fact that any object in JAVA can be casted down
to java.object is not that clever after all, and part of it
is only due to the fact that there is no other way to have
portable container classes, which is now finally solved
with generics)
The same as method overloading,
one of the most important aspects missing in PHP5 and the
new object model.
due to the feature of optional parameters you may end up with
more than one overloaded function matching a call signature,
due to the fact that argument types in a function call
are not known at compile time signature matching would have
to happen at runtime,
and the language syntax would need to be extended to add
parameter type specifiers to function parameter declarations
(ok, we already have this one for interfaces ...)
--
Hartmut Holzgraefe <[EMAIL PROTECTED]>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] stdClass
You calling it from the base so cleaning you be easier than
looking for object referenced variables and setting them to null.
Working in a large class hierarchy it could get painful.
"Michael Walter" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Jakes wrote:
> > Oh, yes and special methods that you mentioned would come in handy too
> > but from a object perspective. Maybe explicitly calling some sort
finalize()
> > method to clean un-referenced objects would also be handy.
> How does that differ from $x=null; with a reference-counting garbage
> collector?
>
> Cheers,
> Michael
>
> >
> > - Original Message -
> > From: "Jakes Potgieter" <[EMAIL PROTECTED]>
> > Newsgroups: php.internals
> > To: <[EMAIL PROTECTED]>
> > Cc: <[EMAIL PROTECTED]>; "Stephan Schmidt" <[EMAIL PROTECTED]>
> > Sent: Friday, February 27, 2004 4:42 PM
> > Subject: Re: [PHP-DEV] stdClass
> >
> >
> >
> >>When Im talking about something like this would come in handy
> >>obviously doesnt work! The paramter null could be added, to get
> >>desired result but to be programmatically correct:
> >>
> >>class MyOverload{
> >> function __construct($Foo) {
> >>$this->Foo = $Foo;
> >> }
> >> // overload the constructor
> >> function __construct(String $Foo, String $Bar){
> >> $this->Foo = $Foo;
> >> $this->Bar = $Bar;
> >> }
> >> public function doSomething(){
> >>if($this->Foo != null && $this->Bar == null){
> >> return $this->Foo . " needs a partner";
> >>// do something with Foo
> >>}elseif($this->Foo != null && $this->Bar != null){
> >> return $this->Foo . " and " . $this->Bar . " are partners";
> >
> > //do
> >
> >>something with Foo and Bar
> >>}
> >> }
> >> private $Foo;
> >> private $Bar;
> >>}
> >>
> >>$obj = new MyOverload("Mary");
> >>print $obj->doSomething();
> >>
> >>
> >>- Original Message -
> >>From: "Hartmut Holzgraefe" <[EMAIL PROTECTED]>
> >>To: "Jakes Potgieter" <[EMAIL PROTECTED]>
> >>Cc: "Stephan Schmidt" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> >>Sent: Friday, February 27, 2004 4:20 PM
> >>Subject: Re: [PHP-DEV] stdClass
> >>
> >>
> >>
> >>>Jakes Potgieter wrote:
> >>>
> It would be nice to have a base class to inherit some special
> methods as we do in Java.
> >>>
> >>>could you name which ones you think of?
> >>>
> >>>being out of the JAVA camp for several years know i no longer
> >>>know all java.object methods and properties by heart, but
> >>>PHP mechanisms like __sleep()/__wakeup(), __toString() and
> >>>the introspection related functions like get_class() and
> >>>friends should provide comparable behaviour ...
> >>>
> >>>(IMHO the fact that any object in JAVA can be casted down
> >>> to java.object is not that clever after all, and part of it
> >>> is only due to the fact that there is no other way to have
> >>> portable container classes, which is now finally solved
> >>> with generics)
> >>>
> >>>
> The same as method overloading,
> one of the most important aspects missing in PHP5 and the
> new object model.
> >>>
> >>>due to the feature of optional parameters you may end up with
> >>>more than one overloaded function matching a call signature,
> >>>due to the fact that argument types in a function call
> >>>are not known at compile time signature matching would have
> >>>to happen at runtime,
> >>>and the language syntax would need to be extended to add
> >>>parameter type specifiers to function parameter declarations
> >>>(ok, we already have this one for interfaces ...)
> >>>
> >>>--
> >>>Hartmut Holzgraefe <[EMAIL PROTECTED]>
> >>>
> >
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fw: [PHP-DOC] #27345 [Opn]: Status header with PHP CGI
Unless of course there is code in there to look for HTTP/ and set the
appropriate status code. This code used to be there, but it may have
gotten dropped along the way.
-Rasmus
On Fri, 27 Feb 2004, Nuno Lopes wrote:
> Can anybody clarify this, please?
> Nuno
>
>
> - Original Message -
>
> > ID: 27345
> > Updated by: [EMAIL PROTECTED]
> > Reported By: php_bugs at ecora dot de
> > Status: Open
> > Bug Type:Documentation problem
> > PHP Version: Irrelevant
> > New Comment:
> >
> > I couldn't reproduce this in PHP 5.
> >
> > header("HTTP/1.0 404 Not Found"); print "Status: 404"
> >
> > and
> >
> > header("Status: 404 Not Found"); prints "Status: 404 Not Found"
> >
> >
> > Can anybody check this in PHP 4?
> >
> >
> > Previous Comments:
> >
> >
> > [2004-02-22 05:10:36] php_bugs at ecora dot de
> >
> > Description:
> >
> > Hi,
> >
> >
> > header("HTTP/1.0 404 Not Found");
> > [...]
> > Note: In PHP 3, this only works when PHP is compiled as an Apache
> > module. You can achieve the same effect using the Status header.
> > header("Status: 404 Not Found");
> >
> >
> > IMHO this is not correct. Because the HTTP-status-header (also
> > Content-Type- and Location-Header) is always a server parsed header,
> > when PHP (PHP3, PHP4, PHP5 or also Perl or Python, ...) runs via CGI.
> >
> > The official CGI Specification (see http://www.w3.org/CGI/):
> > http://hoohoo.ncsa.uiuc.edu/cgi/out.html
> >
> > That means not only in PHP3 also in PHP4 or PHP5: When PHP runs via
> > CGI, then you have to write:
> > header("Status: 404 Not Found"); instead of header("HTTP/1.0 404 Not
> > Found");
> >
> >
> >
> >
> > Reproduce code:
> > ---
> > When i try to send a header("HTTP/1.0 404 Not Found"); on my
> > installation (Apache 1.3.29 + PHP 4.2.3 CGI on Linux) then i receive a
> > 500 internal server error
> >
> >
> >
> >
> >
> >
> > --
> > Edit this bug report at http://bugs.php.net/?id=27345&edit=1
>
> --
> 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] Declaration of Bar::__construct() must be compatible
At 14:13 27/02/2004 +0100, Derick Rethans wrote: On Fri, 27 Feb 2004, Andi Gutmans wrote: > d) Last problem is that using E_STRICT is not a good idea because we find > this problem at compile-time and the error_reporting might not be set yet. The INI system is 'booted' before the script is compiled, so I doubt that this is a problem. Yeah but people are used to setting the error_reporting from prepend's or at the beginning of the script. But you know what, I guess we can live with this because I see a few E_WARNINGS at the compile stage. So I guess we could go with E_STRICT for people who want to get the warning (and the script will still run). The question is if we should ignore constructors from this check. I think we should but one person here thought we shouldn't. > What I suggest is the following: > a) Don't check signature for constructors. > b) By default, don't check signature for inheritance *if* we're not > inheriting from an abstract class. If it is an abstract class we should > check the signature because it's a PHP 5 feature. ack and ack Is everyone OK with peforming this check for abstract classes and interfaces? Or do you think it should only be checked for E_STRICT (before our change it was checked! We only changed inheritance). > c) Add a new INI option (zend.strict_inheritance_checks) which does check > signature for methods (except for constructor). I don't like new INI > options but I don't think there's any way out. I'm against adding another INI setting. I don't see why we need to force this OO purist thing on all long time users at all. What is wrong by showing an e_notice/e_warning for it in non-compat mode, and e_strict in compat mode (or just e_strict in both cases)? Then PHP still tells you that you do something wrong, but it won't break any code. That could work too. So in zend.ze2_compatibility_mode we'd do an E_STRICT and otherwise an E_WARNING? I think it's even OK if we just go with E_STRICT in all cases. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] stdClass
Jakes wrote: Oh, yes and special methods that you mentioned would come in handy too but from a object perspective. Maybe explicitly calling some sort finalize() method to clean un-referenced objects would also be handy. finalize() is one of the worst concepts of JAVA that i can think of: a somehow-destructor called at a non-forseeable time in the future (whenever the garbage collector thread tinks its about time to reclaim the only resource it is able to monitor: memory) there are even recommedations not to use it at all ... -- Hartmut Holzgraefe <[EMAIL PROTECTED]> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Declaration of Bar::__construct() must be compatible
On Feb 27, 2004, at 10:05 AM, Andi Gutmans wrote: Yeah but people are used to setting the error_reporting from prepend's or at the beginning of the script. But you know what, I guess we can live with this because I see a few E_WARNINGS at the compile stage. So I guess we could go with E_STRICT for people who want to get the warning (and the script will still run). The question is if we should ignore constructors from this check. I think we should but one person here thought we shouldn't. Just to be clear - I'm not that person, right? > What I suggest is the following: > a) Don't check signature for constructors. > b) By default, don't check signature for inheritance *if* we're not > inheriting from an abstract class. If it is an abstract class we should > check the signature because it's a PHP 5 feature. ack and ack Is everyone OK with peforming this check for abstract classes and interfaces? Or do you think it should only be checked for E_STRICT (before our change it was checked! We only changed inheritance). > c) Add a new INI option (zend.strict_inheritance_checks) which does check > signature for methods (except for constructor). I don't like new INI > options but I don't think there's any way out. I'm against adding another INI setting. I don't see why we need to force this OO purist thing on all long time users at all. What is wrong by showing an e_notice/e_warning for it in non-compat mode, and e_strict in compat mode (or just e_strict in both cases)? Then PHP still tells you that you do something wrong, but it won't break any code. That could work too. So in zend.ze2_compatibility_mode we'd do an E_STRICT and otherwise an E_WARNING? I think it's even OK if we just go with E_STRICT in all cases. I'd prefer E_STRICT/E_STRICT or E_STRICT/E_NOTICE, but I can live with this as well. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Declaration of Bar::__construct() must be compatible
On Fri, 27 Feb 2004, Andi Gutmans wrote: > At 14:13 27/02/2004 +0100, Derick Rethans wrote: > >On Fri, 27 Feb 2004, Andi Gutmans wrote: > > > > > d) Last problem is that using E_STRICT is not a good idea because we find > > > this problem at compile-time and the error_reporting might not be set yet. > > > >The INI system is 'booted' before the script is compiled, so I doubt > >that this is a problem. > > Yeah but people are used to setting the error_reporting from prepend's or > at the beginning of the script. But you know what, I guess we can live with > this because I see a few E_WARNINGS at the compile stage. So I guess we > could go with E_STRICT for people who want to get the warning (and the > script will still run). > The question is if we should ignore constructors from this check. I think > we should but one person here thought we shouldn't. I think we should too. > That could work too. So in zend.ze2_compatibility_mode we'd do an E_STRICT > and otherwise an E_WARNING? I think it's even OK if we just go with > E_STRICT in all cases. yeah, that sounds better to me too. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] stdClass
Jakes wrote: You calling it from the base so cleaning you be easier than looking for object referenced variables and setting them to null. Working in a large class hierarchy it could get painful. __destruct() and as far as object references in variables are concerned: the engine destructs all instance member variables when an object is destructed, so the reference counts of the referenced objects are already deceremented no need to free them by hand (this is even true for PHP 4) you only have to take care of cleanup yourself when you have circular refence graphs ... -- Hartmut Holzgraefe <[EMAIL PROTECTED]> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] stdClass
cool, Im going to look more into the engine to see the working. I suppose PHP it isn't as memory intensive as JAVA Quick question, does the zend engine have a garbage collector while we are on the topic? "Hartmut Holzgraefe" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Jakes wrote: > > You calling it from the base so cleaning you be easier than > > looking for object referenced variables and setting them to null. > > Working in a large class hierarchy it could get painful. > > __destruct() > > and as far as object references in variables are concerned: > the engine destructs all instance member variables when an > object is destructed, so the reference counts of the > referenced objects are already deceremented > no need to free them by hand (this is even true for PHP 4) > > you only have to take care of cleanup yourself when you > have circular refence graphs ... > > -- > Hartmut Holzgraefe <[EMAIL PROTECTED]> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Declaration of Bar::__construct() must be
Hi - Andi Gutmans wrote: The question is if we should ignore constructors from this check. I think we should but one person here thought we shouldn't. I think constructors should be ignored. Is everyone OK with peforming this check for abstract classes and interfaces? Or do you think it should only be checked for E_STRICT (before our change it was checked! We only changed inheritance). I tend to think that for consistency interfaces should be allowed to override method signatures (i.e. when extending an interface you can change it), but agree that this is technically wrong/bad behavior. Just a though -- would it make sense to have another keywords / method that does a strict isA check? -- i.e. if ($obj strictinstanceof Statement). This would allow developers to make those signature-conforming assumptions that they cannot make in PHP now. > c) Add a new INI option (zend.strict_inheritance_checks) which does check > signature for methods (except for constructor). I don't like new INI > options but I don't think there's any way out. I'm against adding another INI setting. I don't see why we need to force this OO purist thing on all long time users at all. What is wrong by showing an e_notice/e_warning for it in non-compat mode, and e_strict in compat mode (or just e_strict in both cases)? Then PHP still tells you that you do something wrong, but it won't break any code. That could work too. So in zend.ze2_compatibility_mode we'd do an E_STRICT and otherwise an E_WARNING? I think it's even OK if we just go with E_STRICT in all cases. I'd prefer E_STRICT always, if anything, since I want to be able to design PHP5 code that takes advantage of loose inheritance checking w/o requiring users to enable compatibilty mode. Hans -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Declaration of Bar::__construct() must be
At 10:25 27/02/2004 -0500, Hans Lellelid wrote: Hi - Andi Gutmans wrote: The question is if we should ignore constructors from this check. I think we should but one person here thought we shouldn't. I think constructors should be ignored. OK Is everyone OK with peforming this check for abstract classes and interfaces? Or do you think it should only be checked for E_STRICT (before our change it was checked! We only changed inheritance). I tend to think that for consistency interfaces should be allowed to override method signatures (i.e. when extending an interface you can change it), but agree that this is technically wrong/bad behavior. Just a though -- would it make sense to have another keywords / method that does a strict isA check? -- i.e. if ($obj strictinstanceof Statement). This would allow developers to make those signature-conforming assumptions that they cannot make in PHP now. No. I wouldn't want to add yet another keyword. I suggest that whoever wants to be pure uses E_STRICT. > c) Add a new INI option (zend.strict_inheritance_checks) which does check > signature for methods (except for constructor). I don't like new INI > options but I don't think there's any way out. I'm against adding another INI setting. I don't see why we need to force this OO purist thing on all long time users at all. What is wrong by showing an e_notice/e_warning for it in non-compat mode, and e_strict in compat mode (or just e_strict in both cases)? Then PHP still tells you that you do something wrong, but it won't break any code. That could work too. So in zend.ze2_compatibility_mode we'd do an E_STRICT and otherwise an E_WARNING? I think it's even OK if we just go with E_STRICT in all cases. I'd prefer E_STRICT always, if anything, since I want to be able to design PHP5 code that takes advantage of loose inheritance checking w/o requiring users to enable compatibilty mode. Okay. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] linking with VS.NET: executor_globals_id is an unresolved external symbol
Using Visual Studio.NET, I can build PHP fine using the php5ts project/solution. I have a problem, however, with another project I've added to the solution which is a custom extension with no external (to PHP) library dependencies. It was working (compiling, linking, and then being loaded into PHP and run) just fine. However, when I added a call to call_user_function_ex() in the extension, it wouldn't link anymore. I get this error on linking: error LNK2001: unresolved external symbol _executor_globals_id I am calling call_user_function_ex() like this: res = call_user_function_ex(EG(function_table), NULL, callback_func, &callback_retval, 3, callback_params, 0, NULL TSRMLS_CC); so it seems that the executor_globals_id symbol comes from the use of EG(function_table). The file with the call_user_function_ex() call includes "zend_globals.h" which has the "extern int executor_globals_id" statement in the #ifdef ZTS clause. The extension compiles and links and runs just fine on Linux (presumably because ZTS isn't defined.) Is this something anyone else has run into? I can provide my .vcproj file if that's helpful. Thanks, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] stdClass
Jakes wrote: cool, Im going to look more into the engine to see the working. I suppose PHP it isn't as memory intensive as JAVA Quick question, does the zend engine have a garbage collector while we are on the topic? As said, it uses reference counting. Cheers, Michael "Hartmut Holzgraefe" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Jakes wrote: You calling it from the base so cleaning you be easier than looking for object referenced variables and setting them to null. Working in a large class hierarchy it could get painful. __destruct() and as far as object references in variables are concerned: the engine destructs all instance member variables when an object is destructed, so the reference counts of the referenced objects are already deceremented no need to free them by hand (this is even true for PHP 4) you only have to take care of cleanup yourself when you have circular refence graphs ... -- Hartmut Holzgraefe <[EMAIL PROTECTED]> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] stdClass
Hartmut Holzgraefe wrote:
Jakes wrote:
Oh, yes and special methods that you mentioned would come in handy too
but from a object perspective. Maybe explicitly calling some sort
finalize()
method to clean un-referenced objects would also be handy.
finalize() is one of the worst concepts of JAVA that i can think of:
a somehow-destructor called at a non-forseeable time in the future
(whenever the garbage collector thread tinks its about time to reclaim
the only resource it is able to monitor: memory)
there are even recommedations not to use it at all ...
Indeed. UNWIND-PROTECT a.k.a. try { .. } finally { .. } in Java or using
() { .. } in C# are usually a much better choice, I think. Similar
problems apply to PHP __destructors, too, anyway (mainly the
non-derminism of cleanup), probably those should be used with similar
care ;-)
Cheers,
Michael
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fw: [PHP-DOC] #27345 [Opn]: Status header with PHP CGI
So, what shall I do?
Mark this bug as bogus or update the documentation. If yes, what should I
add/remove/modify?
Nuno
- Original Message -
> Unless of course there is code in there to look for HTTP/ and set the
> appropriate status code. This code used to be there, but it may have
> gotten dropped along the way.
>
> -Rasmus
>
> On Fri, 27 Feb 2004, Nuno Lopes wrote:
>
> > Can anybody clarify this, please?
> > Nuno
> >
> >
> > - Original Message -
> >
> > > ID: 27345
> > > Updated by: [EMAIL PROTECTED]
> > > Reported By: php_bugs at ecora dot de
> > > Status: Open
> > > Bug Type:Documentation problem
> > > PHP Version: Irrelevant
> > > New Comment:
> > >
> > > I couldn't reproduce this in PHP 5.
> > >
> > > header("HTTP/1.0 404 Not Found"); print "Status: 404"
> > >
> > > and
> > >
> > > header("Status: 404 Not Found"); prints "Status: 404 Not Found"
> > >
> > >
> > > Can anybody check this in PHP 4?
> > >
> > >
> > > Previous Comments:
> >
>
> > >
> > > [2004-02-22 05:10:36] php_bugs at ecora dot de
> > >
> > > Description:
> > >
> > > Hi,
> > >
> > >
> > > header("HTTP/1.0 404 Not Found");
> > > [...]
> > > Note: In PHP 3, this only works when PHP is compiled as an Apache
> > > module. You can achieve the same effect using the Status header.
> > > header("Status: 404 Not Found");
> > >
> > >
> > > IMHO this is not correct. Because the HTTP-status-header (also
> > > Content-Type- and Location-Header) is always a server parsed header,
> > > when PHP (PHP3, PHP4, PHP5 or also Perl or Python, ...) runs via CGI.
> > >
> > > The official CGI Specification (see http://www.w3.org/CGI/):
> > > http://hoohoo.ncsa.uiuc.edu/cgi/out.html
> > >
> > > That means not only in PHP3 also in PHP4 or PHP5: When PHP runs via
> > > CGI, then you have to write:
> > > header("Status: 404 Not Found"); instead of header("HTTP/1.0 404 Not
> > > Found");
> > >
> > >
> > >
> > >
> > > Reproduce code:
> > > ---
> > > When i try to send a header("HTTP/1.0 404 Not Found"); on my
> > > installation (Apache 1.3.29 + PHP 4.2.3 CGI on Linux) then i receive a
> > > 500 internal server error
> > >
> > >
> > >
> >
>
> > >
> > >
> > > --
> > > Edit this bug report at http://bugs.php.net/?id=27345&edit=1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fw: [PHP-DOC] #27345 [Opn]: Status header with PHP CGI
On Fri, Feb 27, 2004 at 03:56:07PM -, Nuno Lopes wrote:
> So, what shall I do?
> Mark this bug as bogus or update the documentation. If yes, what should I
> add/remove/modify?
>
> Nuno
There's no problem with the documentation, the behaviour is wrong.
when doing header('HTTP/1.1 404 Not Found'); in CGI, just
'Status: 404' is outputted where it should output
'Status: 404 Not Found'
--
Regards,
Stefan Walk
<[EMAIL PROTECTED]>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] SimpleXML & Casting to String
I know we discussed this already, but after seeing a couple of bug
reports about SimpleXML, I'm worried our decision only makes sense to
us and not to regular users. :)
Specifically, since elements and attibutes look like strings, people
expect them to act like strings. But since they're not objects instead
of strings, they're completely buffled as how to handle them.
Here are two examples that have come through the bug report system in
the last day:
$sxe = simplexml_load_string('');
if ($sxe['a'] == '123') {
// do something
}
And:
$xml = simplexml_load_string(/* some valid XML string that I'm not
going to cut and paste here */);
foreach($xml->user as $user){
if (utf8_decode($user->login) == $login &&
utf8_decode($user->password) == $password) {
// valid users
}
}
Both seem like they should work, but neither do.
In the first example, we're comparing an object with a string. Even
though $sxe['a']->__toString() == 'a', the comparison fails. (Well, you
can't actually do that, but you know what I mean.)
In the second example, utf8_decode() expects a string and not an
object and we again we don't autoconvert.
The problems can be solved by explicitly casting the object to a
string, but since you rarely need to cast elsewhere in PHP, I don't
think anyone thinks of it as a necessary step.
Originally, I proposed that PHP autoconvert an object to a string
whenever the object has a __toString() and it's necessary to treat the
variable as a string. In the first example, since we're comparing an
object to a string, we would cast down the object to enable the
comparison. This would work just like 1 == '1'. In the second case,
since the function expects a string, we'd also do the cast.
However, Andi (and others) raised some valid issues about edge cases
and other potential engine problems.
Is there anything we can do to help out people so that SimpleXML works
as they expect, but doesn't have the potential to unleash hell on PHP
and the bug system?
Maybe it makes sense to have SimpleXML leaf nodes return as strings
instead of SimpleXML objects? Or does this merely substitute one set
of problems for another? (E.g. this breaks iteratation, what happens
when there's multiple leaves, etc.)
I don't know what the right answer is, but I feel that the current
solution isn't perfect. It may end up to be the best possible method,
but I'm not yet convinced it is.
-adam
--
[EMAIL PROTECTED]
author of o'reilly's php cookbook
avoid the holiday rush, buy your copy today!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Declaration of Bar::__construct() must be compatible
On Fri, 27 Feb 2004, Andi Gutmans wrote: > What I suggest is the following: > a) Don't check signature for constructors. > b) By default, don't check signature for inheritance *if* we're not > inheriting from an abstract class. If it is an abstract class we should > check the signature because it's a PHP 5 feature. > c) Add a new INI option (zend.strict_inheritance_checks) which does check > signature for methods (except for constructor). I don't like new INI > options but I don't think there's any way out. Sounds good to me. - Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Declaration of Bar::__construct() must be compatible
On Fri, 2004-02-27 at 14:39, Stig S. Bakken wrote: > On Fri, 2004-02-27 at 14:13, Derick Rethans wrote: [...] > What is worse is that many PHP 4 APIs need to be completely redesigned > for PHP 5, not only the guts of the class. > > IMHO method overloading the the only clean way out of this. Agreed, but I can live with the E_STRICT solution (whether or not compat mode is enabled), too. E_NOTICE (or E_WARNING) would be annoying to people who have existing code with E_ALL. - Timm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SimpleXML & Casting to String
Hello Adam,
Friday, February 27, 2004, 7:37:15 PM, you wrote:
> I know we discussed this already, but after seeing a couple of bug
> reports about SimpleXML, I'm worried our decision only makes sense to
> us and not to regular users. :)
> Specifically, since elements and attibutes look like strings, people
> expect them to act like strings. But since they're not objects instead
> of strings, they're completely buffled as how to handle them.
> Here are two examples that have come through the bug report system in
> the last day:
> $sxe = simplexml_load_string('');
> if ($sxe['a'] == '123') {
> // do something
> }
> And:
> $xml = simplexml_load_string(/* some valid XML string that I'm not
> going to cut and paste here */);
> foreach($xml->user as $user){
> if (utf8_decode($user->login) == $login &&
> utf8_decode($user->password) == $password) {
> // valid users
> }
> }
> Both seem like they should work, but neither do.
> In the first example, we're comparing an object with a string. Even
> though $sxe['a']->__toString() == 'a', the comparison fails. (Well, you
> can't actually do that, but you know what I mean.)
> In the second example, utf8_decode() expects a string and not an
> object and we again we don't autoconvert.
> The problems can be solved by explicitly casting the object to a
> string, but since you rarely need to cast elsewhere in PHP, I don't
> think anyone thinks of it as a necessary step.
> Originally, I proposed that PHP autoconvert an object to a string
> whenever the object has a __toString() and it's necessary to treat the
> variable as a string. In the first example, since we're comparing an
> object to a string, we would cast down the object to enable the
> comparison. This would work just like 1 == '1'. In the second case,
> since the function expects a string, we'd also do the cast.
> However, Andi (and others) raised some valid issues about edge cases
> and other potential engine problems.
> Is there anything we can do to help out people so that SimpleXML works
> as they expect, but doesn't have the potential to unleash hell on PHP
> and the bug system?
First of all we need to document that shit very well because it is the
first extensions whose objects make use of all the possibilities of
the new engine. Hence such bug reports are normal. The main problem for
us is differentiating which are real bugs and wich are based on
misunderstanding.
Perhaps here we see that the engine capabilities make things to comples for
the average php user. If that's the case then we have the cooles thing to
handle xml but nobody can handle it right.
> Maybe it makes sense to have SimpleXML leaf nodes return as strings
> instead of SimpleXML objects? Or does this merely substitute one set
> of problems for another? (E.g. this breaks iteratation, what happens
> when there's multiple leaves, etc.)
At least a think for some thoughts.
> I don't know what the right answer is, but I feel that the current
> solution isn't perfect. It may end up to be the best possible method,
> but I'm not yet convinced it is.
sorry me neither.
> -adam
> --
> [EMAIL PROTECTED]
> author of o'reilly's php cookbook
> avoid the holiday rush, buy your copy today!
--
Best regards,
Marcusmailto:[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Declaration of Bar::__construct() must be compatible
Hello Timm, Friday, February 27, 2004, 7:39:26 PM, you wrote: > On Fri, 2004-02-27 at 14:39, Stig S. Bakken wrote: >> On Fri, 2004-02-27 at 14:13, Derick Rethans wrote: > [...] >> What is worse is that many PHP 4 APIs need to be completely redesigned >> for PHP 5, not only the guts of the class. >> >> IMHO method overloading the the only clean way out of this. > Agreed, but I can live with the E_STRICT solution (whether or not compat > mode is enabled), too. E_NOTICE (or E_WARNING) would be annoying to > people who have existing code with E_ALL. That's a good point. So for complete BC you drop E_STRICT and when you're going to convert to rock solid PHP 5 code you switch E_STRICT on. -- Best regards, Marcusmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Memory leak with .=
The following script:
buf.= ($string instanceof StringBuffer
? $string->buf
: $string
);
}
}
$s= new StringBuffer();
$s->append('Hello');
?>
causes:
/usr/home/thekid/devel/php/php/Zend/zend_execute.c(4049) : Freeing
0x083B0310 (6 bytes), script=string.php
/usr/home/thekid/devel/php/php/Zend/zend_variables.c(137) : Actual
location (location was relayed)
=== Total 1 memory leaks detected ===
Changing the line $this->buf.= [...] to $this->buf= $this->buf. makes
the leak disappear.
- Timm
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SimpleXML & Casting to String
Basically SimpleXML should know if the property is being fetched for read
or not (type is passed such as BP_VAR_R or BP_VAR_W). If the case is
BP_VAR_R (read access) then SimpleXML should return the value and not an
object.
There might be some places in the engine which aren't covered but it's best
for the SimpleXML authors to check this out first because in general it
should work.
At 13:37 27/02/2004 -0500, Adam Maccabee Trachtenberg wrote:
I know we discussed this already, but after seeing a couple of bug
reports about SimpleXML, I'm worried our decision only makes sense to
us and not to regular users. :)
Specifically, since elements and attibutes look like strings, people
expect them to act like strings. But since they're not objects instead
of strings, they're completely buffled as how to handle them.
Here are two examples that have come through the bug report system in
the last day:
$sxe = simplexml_load_string('');
if ($sxe['a'] == '123') {
// do something
}
And:
$xml = simplexml_load_string(/* some valid XML string that I'm not
going to cut and paste here */);
foreach($xml->user as $user){
if (utf8_decode($user->login) == $login &&
utf8_decode($user->password) == $password) {
// valid users
}
}
Both seem like they should work, but neither do.
In the first example, we're comparing an object with a string. Even
though $sxe['a']->__toString() == 'a', the comparison fails. (Well, you
can't actually do that, but you know what I mean.)
In the second example, utf8_decode() expects a string and not an
object and we again we don't autoconvert.
The problems can be solved by explicitly casting the object to a
string, but since you rarely need to cast elsewhere in PHP, I don't
think anyone thinks of it as a necessary step.
Originally, I proposed that PHP autoconvert an object to a string
whenever the object has a __toString() and it's necessary to treat the
variable as a string. In the first example, since we're comparing an
object to a string, we would cast down the object to enable the
comparison. This would work just like 1 == '1'. In the second case,
since the function expects a string, we'd also do the cast.
However, Andi (and others) raised some valid issues about edge cases
and other potential engine problems.
Is there anything we can do to help out people so that SimpleXML works
as they expect, but doesn't have the potential to unleash hell on PHP
and the bug system?
Maybe it makes sense to have SimpleXML leaf nodes return as strings
instead of SimpleXML objects? Or does this merely substitute one set
of problems for another? (E.g. this breaks iteratation, what happens
when there's multiple leaves, etc.)
I don't know what the right answer is, but I feel that the current
solution isn't perfect. It may end up to be the best possible method,
but I'm not yet convinced it is.
-adam
--
[EMAIL PROTECTED]
author of o'reilly's php cookbook
avoid the holiday rush, buy your copy today!
--
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] SimpleXML & Casting to String
BP_VAR_R just tells the engine not to through a warning when the
property doesn't exist. The problem is that we need to handle cases
like:
$doc = simplexml_load_string('bar');
echo $doc->name["attr"];
echo $doc->name;
Both would be covered by BP_VAR_R AFAIR. What if the string is empty
and they want a subnode, ie:
foo;
echo $a->john;
?>
-Sterling
On Feb 27, 2004, at 5:33 PM, Andi Gutmans wrote:
Basically SimpleXML should know if the property is being fetched for
read or not (type is passed such as BP_VAR_R or BP_VAR_W). If the case
is BP_VAR_R (read access) then SimpleXML should return the value and
not an object.
There might be some places in the engine which aren't covered but it's
best for the SimpleXML authors to check this out first because in
general it should work.
At 13:37 27/02/2004 -0500, Adam Maccabee Trachtenberg wrote:
I know we discussed this already, but after seeing a couple of bug
reports about SimpleXML, I'm worried our decision only makes sense to
us and not to regular users. :)
Specifically, since elements and attibutes look like strings, people
expect them to act like strings. But since they're not objects instead
of strings, they're completely buffled as how to handle them.
Here are two examples that have come through the bug report system in
the last day:
$sxe = simplexml_load_string('');
if ($sxe['a'] == '123') {
// do something
}
And:
$xml = simplexml_load_string(/* some valid XML string that I'm not
going to cut and paste here */);
foreach($xml->user as $user){
if (utf8_decode($user->login) == $login &&
utf8_decode($user->password) == $password) {
// valid users
}
}
Both seem like they should work, but neither do.
In the first example, we're comparing an object with a string. Even
though $sxe['a']->__toString() == 'a', the comparison fails. (Well,
you
can't actually do that, but you know what I mean.)
In the second example, utf8_decode() expects a string and not an
object and we again we don't autoconvert.
The problems can be solved by explicitly casting the object to a
string, but since you rarely need to cast elsewhere in PHP, I don't
think anyone thinks of it as a necessary step.
Originally, I proposed that PHP autoconvert an object to a string
whenever the object has a __toString() and it's necessary to treat the
variable as a string. In the first example, since we're comparing an
object to a string, we would cast down the object to enable the
comparison. This would work just like 1 == '1'. In the second case,
since the function expects a string, we'd also do the cast.
However, Andi (and others) raised some valid issues about edge cases
and other potential engine problems.
Is there anything we can do to help out people so that SimpleXML works
as they expect, but doesn't have the potential to unleash hell on PHP
and the bug system?
Maybe it makes sense to have SimpleXML leaf nodes return as strings
instead of SimpleXML objects? Or does this merely substitute one set
of problems for another? (E.g. this breaks iteratation, what happens
when there's multiple leaves, etc.)
I don't know what the right answer is, but I feel that the current
solution isn't perfect. It may end up to be the best possible method,
but I'm not yet convinced it is.
-adam
--
[EMAIL PROTECTED]
author of o'reilly's php cookbook
avoid the holiday rush, buy your copy today!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Declaration of Bar::__construct() must be
Zeev Suraski wrote:
If you take into account that [a] in PHP, you cannot have more than one
signature for a method in a given class, and you take into account the
fact that [b] your overriding method must be able to satisfy the same
interface as the method its overriding
The real solution is not to assume that the inheritance contract is in
place, but to make it explicit. Final is used to prevent inheritance
altogether, why not use the implements keyword as an explicit
inheritance contract, and otherwise assume there is none. This
preserves BC 100%
No need to futz with php.ini, this would be a mistake.
class second extends first {
function method() // this is fine
{
parent::method('something');
}
}
class third implements someinterface {
function method($a)
{
}
}
class fourth extends third {
function method() // compile error
{
parent::method('something');
}
}
?>
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
