ESAPI for PHP news

AccessReferenceMap, RandomAccessReferenceMap and IntegerReferenceMap, and enough of the other classes (FileBasedAuthenticator, StringUtilties, etc) are present and working:

ESAPI for PHP tests passing

This is very good news as although some of the other classes in Milestone 1 are complicated, these two classes were actually going to be some of the hardest to port as PHP does not have the equivalent of J2EE Set, List, HashMap, and many other basic data structures. What PHP does have is native associative arrays (somewhat like HashMaps), ArrayObject, and ArrayIterator from the SPL. The problem is that PHP doesn’t like sparse arrays with very long indexes:

$foo[“THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX. THIS IS A VERY LONG INDEX.”] = $value

So I had to make up a workable hash function and hope for zero collisions. I tried using spl_object_hash(), but that actually is too good. It uses the object’s value AND pointer position, such that:

$foo = “123”;

$bar = “123”;

spl_object_hash($foo) != spl_object_hash($bar)

I think I still need to add a few more test cases as my hash function WILL collide when there are two direct object references of the same value, and thus will not be safe for some uses.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *