Req #46506 [Opn]: readonly attribute for (public) class variables
Edit report at https://bugs.php.net/bug.php?id=46506&edit=1
ID: 46506
User updated by:glideraerobatics at hotmail dot com
Reported by:glideraerobatics at hotmail dot com
Summary:readonly attribute for (public) class variables
Status: Open
Type: Feature/Change Request
Package:*General Issues
PHP Version:5.4
Block user comment: N
Private report: N
New Comment:
@stian dot pedersen at gmail dot com
A "property" keyword isn't good enough because you still need the scope
keywords
public and protected at least. That's why I used the C# convention in the 1st
post.
Previous Comments:
[2013-03-30 18:40:43] stian dot pedersen at gmail dot com
This feature is seconded. Basically it would be useful to have a modifier which
allows internal modification but disallows public reassignment. By an example,
letting "property" be the new key word,
class Order
{
property $customer;
}
class Order
{
private $customer;
public getCustomer(){return $this->customer;}
}
$order->customer and $order->getCustomer() could have the same semantics in
that
a "copy of the pointer" in C terms is returned and you cannot call $order-
>customer = null any more than you could call $order->getCustomer() = null.
However, $customer itself should be modifyable, for instance, $order->customer-
>id = 1000, if id is declared as public. This would be more in tune of mat dot
barrie at gmail dot com and very useful in OOP.
Inside the class, I would prefer to be able to reassign customer at will (even
after constructor).
Syntactically it would be nice to chose a syntax that would allow support for
setters also, but for now, I would be happy with this. It sorta does the same
thing as the __get() trick but does not mess up IDE support and will probably
execute faster.
[2012-11-27 15:55:04] info at strictcoding dot co dot uk
+1 for this awesome feature. Any reviews from the PHP team?
[2012-09-18 21:53:20] mat dot barrie at gmail dot com
As a point of interest, the C# readonly keyword mentioned actually does not
protect exposed classes from being modified, it prevents assignment. So from
your example if you duplicate the C# behaviour, this is what it actually would
work like this, which I don't think is what you're asking for:
--
$count = count($parent->children); // You can do this
$name = $parent->children[0]; // You can even do this
$parent->children[0] = "BILLY"; // You can still do this
$parent->children[] = "BOB"; // And you can still even do this
$parent->children = NULL; // But not this
unset($parent->children); // Or this
--
A readonly attribute probably isn't what's needed here (after all, you're not
actually asking for a property that can be made readonly) but instead if the
protection level could be defined on the getter and setter independently, so
that set could be defined as private and get as public. __get and __set sort
of
do this, but they're useless if you're serialising, hurt performance, and
unless
I'm missing something you can't add phpDoc comments to the exposed pseudo-
properties.
[2012-01-25 08:11:40] glideraerobatics at hotmail dot com
Changed affected PHP version.
[2012-01-24 23:12:32] luke at cywh dot com
I just want the "readonly" keyword to protect a property from being written to
from the outside. I still want to write to the property from within the class.
Here's a simple example of how it could be used:
class Parent
{
readonly public $children = array();
public function addChild($childName)
{
$this->children[] = ucwords(strtolower($childName));
}
}
$parent = new Parent;
$parent->addChild("billy");
$count = count($parent->children); // You can do this
print "Parent has $count children\n";
$name = $parent->children[0]; // You can even do this
print "Parent's first child's name is $name\n";
$parent->children[0] = "BILLY"; // But you can't do this
$parent->children[] = "BOB"; // Or this
$parent->children = NULL; // Or this
unset($parent->children); // Or this
The above example frees you from having to do this:
class Parent
{
protected $children = array();
public function addChild($childName)
{
$this->children[] = ucwords(strtolower($childName));
}
public function hasChild($index)
{
return is
Req #46506 [Opn]: readonly attribute for (public) class variables
Edit report at https://bugs.php.net/bug.php?id=46506&edit=1
ID: 46506
User updated by:glideraerobatics at hotmail dot com
Reported by:glideraerobatics at hotmail dot com
Summary:readonly attribute for (public) class variables
Status: Open
Type: Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
-PHP Version:5.3.0alpha2
+PHP Version:5.4
Block user comment: N
Private report: N
New Comment:
Changed affected PHP version.
Previous Comments:
[2012-01-24 23:12:32] luke at cywh dot com
I just want the "readonly" keyword to protect a property from being written to
from the outside. I still want to write to the property from within the class.
Here's a simple example of how it could be used:
class Parent
{
readonly public $children = array();
public function addChild($childName)
{
$this->children[] = ucwords(strtolower($childName));
}
}
$parent = new Parent;
$parent->addChild("billy");
$count = count($parent->children); // You can do this
print "Parent has $count children\n";
$name = $parent->children[0]; // You can even do this
print "Parent's first child's name is $name\n";
$parent->children[0] = "BILLY"; // But you can't do this
$parent->children[] = "BOB"; // Or this
$parent->children = NULL; // Or this
unset($parent->children); // Or this
The above example frees you from having to do this:
class Parent
{
protected $children = array();
public function addChild($childName)
{
$this->children[] = ucwords(strtolower($childName));
}
public function hasChild($index)
{
return isset($this->children[$index]);
}
public function getChild($index)
{
return $this->children[$index];
}
public function childCount()
{
return count($this->children);
}
}
I've had to write MANY classes like this. The has/isset, get, and count
functions are virtually all the same.
Some people have even resorted to using __get and __set:
http://stackoverflow.com/questions/402215/php-readonly-properties
The __get and __set magic functions are slow, so much so you're better off
making your own getters and setters, which is multiplied by the number of
properties you need like this in the class.
I would recommend the following definitions:
readonly public = read for public, write for protected
readonly protected = read for protected, write for private
I think this should satisfy most cases.
[2009-07-12 13:27:08] mickael at lupusmic dot org
I guess the readonly keyword in C# is wrong. It hasn't to disallow variance of
the attribute, but the setting from outside the object. Readonly is opposite to
constness of a variable. For example, DOMDocument::doctype isn't constant.
What you think about, it's a dynamic const attribute, in opposite to static one.
So said, a readonly is like a const attribute, but isn't. And it doesn't
deserve a scope qualifier, it can only be public.
For example :
class thing
{
readonly$status = 'instantiation' ;
public function __construct()
{
// do init stuff
$this->status = 'instantiate' ;
}
public function invalidate()
{
// do stuf
$this->status = 'invalid' ;
}
}
// Usage
$o = new thing ;
echo $o->status ; // display 'instantiation'
$o->status = 'forced' ; // throw an error E_FATAL
$o->invalidate() ; // do stuff then set readonly status attribute
[2008-11-06 14:11:42] glideraerobatics at hotmail dot com
Description:
Here is a description of this feature in C#:
http://blog.paranoidferret.com/index.php/2007/09/12/csharp-tutorial-the-readonly-keyword/
In a nutshell it allows you to create classes with public variables that are
readonly and can only be written to / initialized by the contructor of the
class itself.
This allows the creation of simple objects without having using accessor
methods to protect the internal data that was validated and initialized during
construction from corruption.
Note: bug http://bugs.php.net/bug.php?id=39467 is about a similar problem but
the proposed solution is not quite right.
Reproduce code:
---
class Person
{
public readonly $name = null;
public readonly $age = null;
public readonly $weight = null;
public function __construct($name, $age, $weight) {
{
if (!isAgeToWeightRatioSan
#46260 [Com]: __FILE__ should not resolve symlink paths
ID: 46260 Comment by: glideraerobatics at hotmail dot com Reported By: bugs dot php dot net at callum-macdonald dot com Status: Open Bug Type: Feature/Change Request Operating System: Linux PHP Version: 5.2.6 New Comment: I have the same problem with PHP. I have a slave site that shares most (but not all!) code with a master site using symlinks. The code consists of CLI scripts, web pages, and includes (one of which is a common include for setting up the include_path and error handling). It is critical that this include_path refers to paths in the slave site even though the real common include resides in the master site. I can't achieve this using __FILE__ unfortunately due to the symlink resolution problem. It would be nice to have an alternative to __FILE__, perhaps __LINK__, with unresolved symlinks. Please PHP developers add this!!! PHP needs it so much and it must be a very simple thing to add. In the mean time, I've created a function in the common include that jumps though hoops in order to set the include_path correctly by using argv[0] in CLI scripts (and traversing up until a htdocs dir is found) or else $_SERVER['DOCUMENT_ROOT'] in web scripts. It's horrible, but the only solution I've found so far. Previous Comments: [2009-07-02 16:43:32] raphael dot roulet at univ-st-etienne dot fr If there is no security issue, Why don't PHP make life easier ? [2009-01-31 23:12:49] bugs dot php dot net at callum-macdonald dot com $_SERVER['PHP_SELF'] only relates to the main script, not the currently included file. It's useful, but a completely separate issue. There is, as far as I can see, no way to get the non symlink resolved path of the currently included file. [2009-01-31 22:54:44] luke_phpbugs at dashjr dot org $_SERVER["PHP_SELF"] helps a little. [2008-10-09 01:32:07] bugs dot php dot net at callum-macdonald dot com Description: See these bugs: http://bugs.php.net/bug.php?id=38790 http://bugs.php.net/bug.php?id=42516 http://bugs.php.net/bug.php?id=37603 The __FILE__ constant should not, in my opinion, resolve symbolic links on *nix operating systems. At the very least, there should be an option to control this behaviour. Because __FILE__ returns only the symlink resolved path, there is no way to get the symlink path of the currently included file. If __FILE__ returned the symlinkpath, the resolved path could be retrieved with realpath(__FILE__). The opposite is not true. There is no way to go from the resolved path to the original link path. I realise this is a feature not a bug, but I believe it is a serious shortcoming and limits the ability of PHP in symlinked situations. Reproduce code: --- See http://bugs.php.net/bug.php?id=37603 Expected result: __FILE__ should return the symlink path Actual result: -- __FILE__ returns the resolved path -- Edit this bug report at http://bugs.php.net/?id=46260&edit=1
#47347 [NEW]: Feature request: add 3rd optional argument - the character encoding
From: glideraerobatics at hotmail dot com Operating system: PHP version: 5.2.9RC1 PHP Bug Type: JSON related Bug description: Feature request: add 3rd optional argument - the character encoding Description: Feature request As you can see here: http://nl3.php.net/manual/en/function.json-encode.php people are jumping through hoops to encode variables of non-utf8 encodings into JSON format. Why not just centralize that magic into the function itself as a new 3rd optional argument $encoding that defaults to UTF-8? Reproduce code: --- n/a Expected result: n/a Actual result: -- n/a -- Edit bug report at http://bugs.php.net/?id=47347&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47347&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47347&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47347&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47347&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47347&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47347&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47347&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47347&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47347&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47347&r=support Expected behavior: http://bugs.php.net/fix.php?id=47347&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47347&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47347&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47347&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47347&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47347&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47347&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47347&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47347&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47347&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47347&r=mysqlcfg
#46506 [NEW]: readonly attribute for (public) class variables
From: glideraerobatics at hotmail dot com
Operating system:
PHP version: 5.3.0alpha2
PHP Bug Type: Feature/Change Request
Bug description: readonly attribute for (public) class variables
Description:
Here is a description of this feature in C#:
http://blog.paranoidferret.com/index.php/2007/09/12/csharp-tutorial-the-readonly-keyword/
In a nutshell it allows you to create classes with public variables that
are readonly and can only be written to / initialized by the contructor of
the class itself.
This allows the creation of simple objects without having using accessor
methods to protect the internal data that was validated and initialized
during construction from corruption.
Note: bug http://bugs.php.net/bug.php?id=39467 is about a similar problem
but the proposed solution is not quite right.
Reproduce code:
---
class Person
{
public readonly $name = null;
public readonly $age = null;
public readonly $weight = null;
public function __construct($name, $age, $weight) {
{
if (!isAgeToWeightRatioSane($age, $weight)) {
throw new InvalidArgumentException("Invalid age to weight ratio:
$age : $weight");
}
// TODO: other sanity checks here.
$this->name = $name;
$this->age = $age;
$this->weight = $weight;
}
}
$person = new Person('Joe', 22, 100);
$person->age = 33; // throws a yet to be named exception
--
Edit bug report at http://bugs.php.net/?id=46506&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46506&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46506&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46506&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46506&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46506&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46506&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46506&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46506&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46506&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46506&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46506&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46506&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46506&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46506&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46506&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46506&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46506&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46506&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46506&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46506&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46506&r=mysqlcfg
#46504 [NEW]: Lexical variable scope
From: glideraerobatics at hotmail dot com
Operating system:
PHP version: 5.3.0alpha2
PHP Bug Type: Feature/Change Request
Bug description: Lexical variable scope
Description:
Many languages such as Perl, Java, C++ support lexically scoped variables.
Lexical scope allows a variable to exist only within its containing
closure. Using lexically scoped (and therefore also declared) variables
prevents a whole lot of accidental bugs, memory waste, and poor code
design.
Perl has the "my" declaration to achieve this:
http://www.developer.com/lang/perl/article.phpr/3323421
There will have to be some kind of pragma to turn on this feature only in
functions or files where it's wanted.
Reproduce code:
---
my $person = new Person("Joe");
if ($person->isHomeless()) {
my $house = new House();
while (!$house->isComplete()) {
$house->addBricks();
}
$person->assignHome($house);
}
// $house no longer exists here.
if ($person->isHungry()) {
my $food = array('bannanas', 'chocolate');
$person->eat($food);
}
// $food no longer exists here.
--
Edit bug report at http://bugs.php.net/?id=46504&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46504&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46504&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46504&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46504&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46504&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46504&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46504&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46504&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46504&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46504&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46504&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46504&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46504&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46504&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46504&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46504&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46504&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46504&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46504&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46504&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46504&r=mysqlcfg
#46503 [NEW]: PCRE objects in addition to the existing functions
From: glideraerobatics at hotmail dot com Operating system: PHP version: 5.2.6 PHP Bug Type: Feature/Change Request Bug description: PCRE objects in addition to the existing functions Description: Most (if not all) other languages (such as javascript, Perl using the qr// operator) that support PCRE regular expressions have some means of creating pre-compiled PCRE objects. These are very useful in that these objects can be passed around inside an application into functions that require a valid regular expression as argument. Using a PCRE object, these functions just have use the 'instance of' operator in order to make sure that the arguments are of the correct type. Pre-compiled PCRE objects can also boost performance in the sense that the expression is compiled once where needed, used one or more times and then disposed of. Sounds similar to how SQL statements are or should be used. I assume that PHP currently compiles and caches string type regular expressions internally so in that case the only performance advantage will be the disposing of the unused regexp. -- Edit bug report at http://bugs.php.net/?id=46503&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46503&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46503&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46503&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46503&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46503&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46503&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46503&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46503&r=needscript Try newer version: http://bugs.php.net/fix.php?id=46503&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46503&r=support Expected behavior: http://bugs.php.net/fix.php?id=46503&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46503&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46503&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46503&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46503&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46503&r=dst IIS Stability: http://bugs.php.net/fix.php?id=46503&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46503&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46503&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46503&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46503&r=mysqlcfg
#43342 [NEW]: Add PDO constant MYSQL_ATTR_CLIENT_FOUND_ROWS in order to influence rowCount()
From: glideraerobatics at hotmail dot com Operating system: all PHP version: 5.2.5 PHP Bug Type: Feature/Change Request Bug description: Add PDO constant MYSQL_ATTR_CLIENT_FOUND_ROWS in order to influence rowCount() Description: PDO is very similar in design to Perl's DBI which does allow you to set driver specific attributes such as mysql_client_found_rows=1 as part of the DSN. Setting the attribute mysql_client_found_rows=1 is Perl's DBD::mysql will make the rows() method (equivalent of PDO's rowCount()) return the number of rows matched for the update and not just those that were actually updated. This is a very useful/efficient feature as it prevents the need for doing 'SELECT COUNT(*)' queries before doing the updates and it prevents the need for locking too (since 2 statements are no longer atomic). PDO has a setAttribute() method, but there is as yet no MYSQL_ATTR_CLIENT_FOUND_ROWS constant. My request is that this be built into the PDO mysql driver. The information rowCount() will need can be retrieved from mysql_info(). -- Edit bug report at http://bugs.php.net/?id=43342&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43342&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43342&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43342&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43342&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43342&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43342&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43342&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43342&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43342&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43342&r=support Expected behavior:http://bugs.php.net/fix.php?id=43342&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43342&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43342&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43342&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43342&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43342&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43342&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43342&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43342&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43342&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43342&r=mysqlcfg
#37746 [WFx]: Incorrect encoding of PHP associative arrays in XML-RPC response.
ID: 37746
User updated by: glideraerobatics at hotmail dot com
Reported By: glideraerobatics at hotmail dot com
Status: Wont fix
Bug Type: XMLRPC-EPI related
Operating System: FreeBSD 6.1
PHP Version: 5.1.4
New Comment:
Ok, but then the question:
Could a 'mixed' array be of any use in xmlrpc communication if the
numeric keys are being lost? I can't (yet) see how anybody could be
relying on that because the xmlrpc response is useless/invalid in such
cases.
Previous Comments:
[2006-06-21 08:19:02] [EMAIL PROTECTED]
Well, 4 years with an unknown amount of people relying on it.
[EMAIL PROTECTED]:~$ cli -r 'var_dump(xmlrpc_get_type(array(123=>123)),
xmlrpc_get_type(array("a"=>123)),
xmlrpc_get_type(array(123=>123,"a"=>123)));'
string(5) "array"
string(6) "struct"
string(5) "mixed"
----------------
[2006-06-21 01:36:19] glideraerobatics at hotmail dot com
I'm confused. Is "It's been that way since the very first release" the
reason why it won't be fixed?
I'm glad Microsoft didn't think that way otherwise I'ld still be seeing
multiple BSOD's every day.
[2006-06-19 08:20:56] [EMAIL PROTECTED]
It's been that way since the very first release, if the array contains
numeric indices only.
[2006-06-08 15:02:04] lars dot maes at gmail dot com
I confirm this bug on Debian 3.1a sarge with php4 version 4.3.10
The chr(0x00) solution also works
[2006-06-08 14:16:45] glideraerobatics at hotmail dot com
By the way, a quick workaround to the problem is to append a NULL byte
to the keys:
$key1 = '666' . chr(0x00);
This way the hash is returned as a correct xml-rpc response without the
NULL bytes.
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
http://bugs.php.net/37746
--
Edit this bug report at http://bugs.php.net/?id=37746&edit=1
#37746 [WFx]: Incorrect encoding of PHP associative arrays in XML-RPC response.
ID: 37746
User updated by: glideraerobatics at hotmail dot com
Reported By: glideraerobatics at hotmail dot com
Status: Wont fix
Bug Type: XMLRPC-EPI related
Operating System: FreeBSD 6.1
PHP Version: 5.1.4
New Comment:
I'm confused. Is "It's been that way since the very first release" the
reason why it won't be fixed?
I'm glad Microsoft didn't think that way otherwise I'ld still be seeing
multiple BSOD's every day.
Previous Comments:
[2006-06-19 08:20:56] [EMAIL PROTECTED]
It's been that way since the very first release, if the array contains
numeric indices only.
[2006-06-08 15:02:04] lars dot maes at gmail dot com
I confirm this bug on Debian 3.1a sarge with php4 version 4.3.10
The chr(0x00) solution also works
--------
[2006-06-08 14:16:45] glideraerobatics at hotmail dot com
By the way, a quick workaround to the problem is to append a NULL byte
to the keys:
$key1 = '666' . chr(0x00);
This way the hash is returned as a correct xml-rpc response without the
NULL bytes.
----------------
[2006-06-08 14:02:55] glideraerobatics at hotmail dot com
Description:
I've noticed that when a key of a hash begins with a digit between 1
and 9 that the resulting XML-RPC response will contain an empty key.
This array:
$result = array('666' => 'me', '007' => 'Bond');
will be returned as this which is obviously wrong:
me
007
bond
Clearly the xmlrpc module has correctly detected that the result is a
hash and has therefore made a 'struct'. What it didn't do correctly for
some strange reason is treat all keys of the hash as strings (they even
really are strings - ask gettype()).
Reproduce code:
---
function debug_getHash($method_name, $params, $app_data) {
$key1 = '666';
$key2 = '007';
$result = array(
$key1 => 'key1 is a ' . gettype($key1),
$key2 => 'key2 is a ' . gettype($key2),
);
return $result;
}
xmlrpc_server_register_method($xmlrpc_server, 'debug.getHash',
'debug_getHash');
Expected result:
666
key1 is a string
007
key2 is a string
Actual result:
--
key1 is a string
007
key2 is a string
--
Edit this bug report at http://bugs.php.net/?id=37746&edit=1
#37746 [Opn]: Incorrect encoding of PHP associative arrays in XML-RPC response.
ID: 37746
User updated by: glideraerobatics at hotmail dot com
Reported By: glideraerobatics at hotmail dot com
Status: Open
Bug Type: XMLRPC-EPI related
Operating System: FreeBSD 6.1
PHP Version: 5.1.4
New Comment:
By the way, a quick workaround to the problem is to append a NULL byte
to the keys:
$key1 = '666' . chr(0x00);
This way the hash is returned as a correct xml-rpc response without the
NULL bytes.
Previous Comments:
[2006-06-08 14:02:55] glideraerobatics at hotmail dot com
Description:
I've noticed that when a key of a hash begins with a digit between 1
and 9 that the resulting XML-RPC response will contain an empty key.
This array:
$result = array('666' => 'me', '007' => 'Bond');
will be returned as this which is obviously wrong:
me
007
bond
Clearly the xmlrpc module has correctly detected that the result is a
hash and has therefore made a 'struct'. What it didn't do correctly for
some strange reason is treat all keys of the hash as strings (they even
really are strings - ask gettype()).
Reproduce code:
---
function debug_getHash($method_name, $params, $app_data) {
$key1 = '666';
$key2 = '007';
$result = array(
$key1 => 'key1 is a ' . gettype($key1),
$key2 => 'key2 is a ' . gettype($key2),
);
return $result;
}
xmlrpc_server_register_method($xmlrpc_server, 'debug.getHash',
'debug_getHash');
Expected result:
666
key1 is a string
007
key2 is a string
Actual result:
--
key1 is a string
007
key2 is a string
--
Edit this bug report at http://bugs.php.net/?id=37746&edit=1
#37746 [NEW]: Incorrect encoding of PHP associative arrays in XML-RPC response.
From: glideraerobatics at hotmail dot com
Operating system: FreeBSD 6.1
PHP version: 5.1.4
PHP Bug Type: XMLRPC-EPI related
Bug description: Incorrect encoding of PHP associative arrays in XML-RPC
response.
Description:
I've noticed that when a key of a hash begins with a digit between 1 and 9
that the resulting XML-RPC response will contain an empty key.
This array:
$result = array('666' => 'me', '007' => 'Bond');
will be returned as this which is obviously wrong:
me
007
bond
Clearly the xmlrpc module has correctly detected that the result is a hash
and has therefore made a 'struct'. What it didn't do correctly for some
strange reason is treat all keys of the hash as strings (they even really
are strings - ask gettype()).
Reproduce code:
---
function debug_getHash($method_name, $params, $app_data) {
$key1 = '666';
$key2 = '007';
$result = array(
$key1 => 'key1 is a ' . gettype($key1),
$key2 => 'key2 is a ' . gettype($key2),
);
return $result;
}
xmlrpc_server_register_method($xmlrpc_server, 'debug.getHash',
'debug_getHash');
Expected result:
666
key1 is a string
007
key2 is a string
Actual result:
--
key1 is a string
007
key2 is a string
--
Edit bug report at http://bugs.php.net/?id=37746&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=37746&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=37746&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=37746&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37746&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=37746&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=37746&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37746&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37746&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=37746&r=support
Expected behavior:http://bugs.php.net/fix.php?id=37746&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=37746&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=37746&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=37746&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37746&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=37746&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=37746&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=37746&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=37746&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=37746&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=37746&r=mysqlcfg
#31445 [Opn]: shmop_read() doesn't stop reading at NULL byte.
ID: 31445 User updated by: glideraerobatics at hotmail dot com Reported By: glideraerobatics at hotmail dot com Status: Open Bug Type: Unknown/Other Function Operating System: Linux PHP Version: 5.0.3 New Comment: I made a work around for shmop_read() and shmop_write() to handle strings correctly. shmop_write() doesn't terminate written data with a null byte, and shmop_read() reads the whole memory segment. This is ok if your dealing with binary data so perhaps these functions shouldn't be considered bugged. Perhaps 2 similar functions should be introduced specially for handling strings (that's what most php programmers work with). Here's the work around with 2 new custom functions for making a string null terminated and extracting a null terminated string from memory: Previous Comments: [2005-01-07 22:46:19] glideraerobatics at hotmail dot com Description: Either shmop_read() doesn't stop reading when it encouters a NULL byte, or shmop_write() doesn't write a NULL byte at the end of a string in the shared memory segment. Reproduce code: --- Expected result: I expected the 1st shmop_read() call to return: 'This is a kind of very long string.' which it does, but I expected the 2nd shmop_read() call to return: 'This is short.' ...which it doesn't. Actual result: -- The 1st shmop_read() call returns: 'This is a kind of very long string.' The 2nd shmop_read() call returns: 'This is short. of very long string.' ...which includes the trailing part of the first and longer string written with shmop_write(). -- Edit this bug report at http://bugs.php.net/?id=31445&edit=1
#31445 [NEW]: shmop_read() doesn't stop reading at NULL byte.
From: glideraerobatics at hotmail dot com Operating system: Linux PHP version: 5.0.3 PHP Bug Type: Unknown/Other Function Bug description: shmop_read() doesn't stop reading at NULL byte. Description: Either shmop_read() doesn't stop reading when it encouters a NULL byte, or shmop_write() doesn't write a NULL byte at the end of a string in the shared memory segment. Reproduce code: --- Expected result: I expected the 1st shmop_read() call to return: 'This is a kind of very long string.' which it does, but I expected the 2nd shmop_read() call to return: 'This is short.' ...which it doesn't. Actual result: -- The 1st shmop_read() call returns: 'This is a kind of very long string.' The 2nd shmop_read() call returns: 'This is short. of very long string.' ...which includes the trailing part of the first and longer string written with shmop_write(). -- Edit bug report at http://bugs.php.net/?id=31445&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31445&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31445&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31445&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31445&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31445&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31445&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31445&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31445&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31445&r=support Expected behavior: http://bugs.php.net/fix.php?id=31445&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31445&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31445&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31445&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31445&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31445&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31445&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31445&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31445&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31445&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31445&r=mysqlcfg
#31096 [NEW]: mysqli_stmt_bind_param drawbacks
From: glideraerobatics at hotmail dot com Operating system: PHP version: 5.0.2 PHP Bug Type: Feature/Change Request Bug description: mysqli_stmt_bind_param drawbacks Description: The function mysqli_stmt_bind_param() is a huge leap forward for PHP but still has a terrible drawback: I use DAO (not the Micro$oft kind) classes that create their own SQL statements. These statements have varying numbers of fields and bind markers (the ? marks). If one could pass an array of values to mysqli_stmt_bind_param(), then this problem could be solved, but it's not possible (yet). Currently mysqli_stmt_bind_param() expects the programmer to just type in a list of variable names as parameters. To make things worse, you sometimes can't even use function calls as parameters because mysqli_stmt_bind_param() complains about non-referenced variables (or something). Hopefully somebody bring PHP up to the level of other programming languages in this area. -- Edit bug report at http://bugs.php.net/?id=31096&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31096&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31096&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31096&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31096&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31096&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31096&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31096&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31096&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31096&r=support Expected behavior: http://bugs.php.net/fix.php?id=31096&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31096&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31096&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31096&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31096&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31096&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31096&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31096&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31096&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=31096&r=mysqlcfg
#31065 [Fbk->Opn]: HTTP "302" status header contains no description causing failure on clients.
ID: 31065
User updated by: glideraerobatics at hotmail dot com
Reported By: glideraerobatics at hotmail dot com
-Status: Feedback
+Status: Open
Bug Type: HTTP related
Operating System: Linux
PHP Version: 5.0.2
New Comment:
I'm using php-cgi called from mod_suphp in Apache 2.
Previous Comments:
[2004-12-12 16:35:29] [EMAIL PROTECTED]
What SAPI are you using?
[2004-12-12 16:35:29] [EMAIL PROTECTED]
What SAPI are you using?
[2004-12-12 15:46:06] glideraerobatics at hotmail dot com
Description:
I've noticed that the browsers in many mobile handsets fail to
understand HTTP responses that don't contain a description after the
status code.
This is often a problem when using the header('Location:
http://somewhere/') function in PHP scripts. This function sets the
HTTP status code to 302 so that the client can redirect to the given
location. Unfortunately the description "Found" is missing behind that
status header so many mobile clients just croak when they recieve the
response.
Adding a status description. Just rip them from here:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6
When it comes to what is not following the HTTP standards exactly in
this case, then I think it's PHP as I can't see anywhere that the
status description is something optional:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6
Reproduce code:
---
header('Location: http://www.php.net');
Expected result:
HTTP/1.1 302 Found
Location: http://www.php.net/
Actual result:
--
HTTP/1.1 302
Location: http://www.php.net/
--
Edit this bug report at http://bugs.php.net/?id=31065&edit=1
#31065 [NEW]: HTTP "302" status header contains no description causing failure on clients.
From: glideraerobatics at hotmail dot com
Operating system: Linux
PHP version: 5.0.2
PHP Bug Type: HTTP related
Bug description: HTTP "302" status header contains no description causing
failure on clients.
Description:
I've noticed that the browsers in many mobile handsets fail to understand
HTTP responses that don't contain a description after the status code.
This is often a problem when using the header('Location:
http://somewhere/') function in PHP scripts. This function sets the HTTP
status code to 302 so that the client can redirect to the given location.
Unfortunately the description "Found" is missing behind that status header
so many mobile clients just croak when they recieve the response.
Adding a status description. Just rip them from here:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6
When it comes to what is not following the HTTP standards exactly in this
case, then I think it's PHP as I can't see anywhere that the status
description is something optional:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6
Reproduce code:
---
header('Location: http://www.php.net');
Expected result:
HTTP/1.1 302 Found
Location: http://www.php.net/
Actual result:
--
HTTP/1.1 302
Location: http://www.php.net/
--
Edit bug report at http://bugs.php.net/?id=31065&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31065&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31065&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31065&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31065&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31065&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31065&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31065&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31065&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31065&r=support
Expected behavior: http://bugs.php.net/fix.php?id=31065&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31065&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31065&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31065&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31065&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31065&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31065&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31065&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31065&r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31065&r=mysqlcfg
#30502 [NEW]: Duplicated headers + missing headers in response
From: glideraerobatics at hotmail dot com
Operating system: Linux
PHP version: 5.0.2
PHP Bug Type: HTTP related
Bug description: Duplicated headers + missing headers in response
Description:
I've noticed numerous times that certain headers produced by PHP scripts
are duplicated. Another problem is that the Content-Length header is set
in code, but is missing in the output.
See below the expected and actual responses. Actual response discards the
Content-Length header and duplicates the Content-Disposition header.
I sent this request to the PHP script to test it:
HEAD /download.php/458/Cats_in_the_Cradle.mid HTTP/1.1
Host: wapxtc.nl
accept-language: nl
user-agent: SonyEricssonT230/R101
cache-control: no-cache
accept: text/vnd.wap.wml,text/vnd.wap.wmlscript,*/*;q=0.001
accept-charset: us-ascii,iso-8859-1,utf-8,iso-10646-ucs-2,*;q=0.001
accept-encoding: *;q=0.001
FYI: I'm running Apache 2 (stable) on PHP5.02 (stable) on Linux.
Reproduce code:
---
// $data contains blob
header('Content-Length: ' . strlen($data));
header('Content-Type: ' . $item['MIMETYPE']);
header('Content-Disposition: inline; filename="' . $filename . '"');
// This outputs the 3 lines above in the error_log as expected:
error_log(implode("\n",headers_list()));
if ($_SERVER['REQUEST_METHOD'] != 'HEAD') {
print $data;
}
exit;
Expected result:
HTTP/1.1 200 OK
Content-Disposition: inline; filename="Cats_in_the_Cradle.mid"
Last-Modified: Mon, 18 Oct 2004 13:23:52 GMT
Content-Type: audio/midi
Content-Length: 6331
Actual result:
--
HTTP/1.1 200 OK
Content-Disposition: inline; filename="Cats_in_the_Cradle.mid"
Last-Modified: Mon, 18 Oct 2004 13:23:52 GMT
Content-Type: audio/midi
Content-Disposition: inline; filename="Cats_in_the_Cradle.mid"
--
Edit bug report at http://bugs.php.net/?id=30502&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30502&r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30502&r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30502&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30502&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30502&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30502&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30502&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30502&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30502&r=support
Expected behavior: http://bugs.php.net/fix.php?id=30502&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=30502&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=30502&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30502&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30502&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30502&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30502&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30502&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30502&r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30502&r=mysqlcfg
