at 2006-05-14
in RFCs, Homepage
by friebe
(0 comments)
With the implementation of RFC #0057 (see entry #87) the classes of the util.adt package have been deprecated.
Note: The old classes will remain in the codebase for the moment and can still be used, although they may not be used together with the new classes due name clashes resulting from PHP's lack of namespaces.
Continue reading for migration notes.The collections framework RFC comes with a migration script that takes care of rewriting your sourcecode to use the new classes from util.collections.
General migration procedure Use it as follows: $ php rfc57-migration.php [[directory]] (assuming your XP checkout is located in ~/devel/xp/trunk, use $ php rfc57-migration.php ~/devel/xp/trunk). The script will analyze the files below this directory recursively and print a list of matches it has found. By supplying -e (for execute) after the directory's name, the changes will actually be written, too.
Done
The LRUBuffer issue The LRUBuffer class has changed in a way that is backwards-incompatible. As stated above, you may continue to use the old class but should migrate at the first chance since the util.adt version of the LRUBuffer class is deprecated.
The new classes are designed to work only with Objects (for example, the HashTable class supports objects as keys and values). The LRUBuffer class used to accept primitives as arguments for its add() and update() methods, the new version requires Objects.
The migration script will print the following if it finds the LRUBuffer class was used in your sourcecode:---> Processing SearchState.class.php with LRUBufferUsageFinder{} >> Variable $lru points to an LRUBuffer instance at line 200 >> Method add invoked on $lru with ($stamp) at line 206 *** 1 occurence(s) of LRUBuffer usage found (see above for details) *** Automatic migration is not possible!
Please note that the LRUBufferUsageFinder cannot find all occurrences of LRUBuffer usage, it checks for the word LRUBuffer (case-insensitively). Imagine the following situation though:
<?php $lru= &$request->session->getValue('lru'); ?> As HttpSession::getValue() returns "mixed" (basically, anything), we cannot derive the lru variable's type (by a grep, that is, in case we'd actually execute the sourcecode, we could, but we don't want that for good reasons ).
Migrating the add() method- add() now takes Objects instead of primitives
The code at the source position mentioned above is something like:
<?php $lru= &new LRUBuffer(5); $stamp= $record['order_id']; $lru->add($stamp); ?> and could be rewritten using the wrapper types from lang.types, e.g.:
<?php $lru= &new LRUBuffer(5); $stamp= $record['order_id']; $lru->add(new Integer($stamp)); ?> The problem is we cannot guess the correct wrapper type ($record['order_id'] originates from an SQL query).
- The victim object is returned instead of the position
In case you use the return value, careful steps need to be taken to migrate your sourcecode.
<?php $deleted= $lru->add($stamp);
if (NULL !== $deleted) { Console::writeLine('Deleted element #', $deleted); } ?> would need to be rewritten to:
<?php $deleted= &$lru->add(new Integer($stamp));
if ($deleted) { Console::writeLine('Victim was: ', $deleted->toString()); } ?>
Migrating the update() method- add() now takes Objects instead of primitives
Same steps as for add() apply here.
|
Subscribe
You can subscribe to the XP framework's news by using RSS syndication.
CategoriesNews General PHP5 Announcements RFCs Further reading Examples Editorial EASC Experiments Unittests Databases
RelatedFind related articles by a search for «Package».
|