Asked  7 Months ago    Answers:  5   Viewed   93 times

PHP 5 introduced DirectoryIterator, and PHP 5.3 introduced FileSystemIterator.

FileSystemIterator extends DirectoryIterator, but the documentation fails to say what extra features it brings.

Can you tell the difference between DirectoryIterator and FileSystemIterator?



This goes out of the top of my head, where I sort of got caught in the changes prior to PHP 5.3 that were going to change in 5.3 and later, concerning the SPL (StandardPHPLibrary) and stuff that were going to be moved to the (horrible) PECL extensions.

The major thing that changed since 5.3, was that the SPL became an extension that could not be disabled anymore, see the changelog of 5.3 noting that

  • Added SPL to list of standard extensions that cannot be disabled. (Marcus)

so all the fancy classes like DirectoryIterator or SPLDoublyLinkedList were now a fix suite of classes that came with PHP 5.3.

There were a lot of discussions going on that the DirectoryIterator was still very clumsy in iterating over files/directories and from behaviour not anonymous enough to the filesystem being used. Because depending on the filesystem (Windows NTFS / *nix EXTx) the results the iterator would return were different from another, where *nix environments per default always resulted the dot and double dot directories (. and ..) as valid directories. These dot directories could then be filtered in the loop by using the isDot() method.

$it = new DirectoryIterator(__DIR__);
foreach ($it as $fileinfo) {
  if (!$fileinfo->isDot())

So FilesystemIterator became the new parent class in PHP 5.3, which prior to its release was the DirectoryIterator (where FilesystemIterator extends DirectoryIterator to implement this interchangeable behaviour by default). The behaviour, or result the FilesystemIterator produced, would then be equal to all different filesystems and interchangeable without the need of any overhead in the loop

$it = new FilesystemIterator(__DIR__);
foreach ($it as $fileinfo) {
  echo $fileinfo->getFilename() . "n";

It's a good question why they didn't update the documentation for noticing the user on the fact that actually the FilesystemIterator preceded the DirectoryIterator.

Wednesday, March 31, 2021
answered 7 Months ago

There is a documented bug which sounds very "close" to the bug you've found!
In order to work-around it, you can do as follows:

$array = array('koala', 'kangaroo', 'wombat', 'wallaby', 'emu', 'kiwi', 'kookaburra', 'platypus');
$object = new ArrayIterator($array);
for ( $object->rewind(); $object->valid(); $object->next() )
    if($object->current() === 'kiwi')
        $object->offsetUnset( $object->key() );
    echo $object->key().' - '.$object->offsetGet($object->key())."n";


0 - koala
1 - kangaroo
2 - wombat
3 - wallaby
4 - emu
0 - koala  (this time it starts over from the first element!)
1 - kangaroo
2 - wombat
3 - wallaby
4 - emu
6 - kookaburra
7 - platypus

If you want, you can submit a bug, but according to the other threads I saw about bugs in ArrayIterator - I find it hard to believe it will be fixed any time soon...

Wednesday, March 31, 2021
answered 7 Months ago

If you implement that interface, then the object acts like an array. e.g., if $foo is an instance of a class that implements ArrayAccess:

$foo['bar'] = 42 calls offsetSet('bar', 42).

echo $foo['bar'] calls offsetGet('bar').

unset($foo['bar']) calls offsetUnset('bar').

isset($foo['bar']) calls offsetExists('bar').

You never explicitly call the functions offset* yourself. It happens implicitly when you access the object as an array.

Wednesday, March 31, 2021
answered 7 Months ago

Intention of ConstraintLayout is to optimize and flatten the view hierarchy of your layouts by applying some rules to each view to avoid nesting.

Rules remind you of RelativeLayout, for example setting the left to the left of some other view.


Unlike RelativeLayout, ConstraintLayout offers bias value that is used to position a view in terms of 0% and 100% horizontal and vertical offset relative to the handles (marked with circle). These percentages (and fractions) offer seamless positioning of the view across different screen densities and sizes.

app:layout_constraintHorizontal_bias="0.33" <!-- from 0.0 to 1.0 -->
app:layout_constraintVertical_bias="0.53" <!-- from 0.0 to 1.0 -->

Baseline handle (long pipe with rounded corners, below the circle handle) is used to align content of the view with another view reference.

Square handles (on each corner of the view) are used to resize the view in dps.

enter image description here

This is totally opinion based and my impression of ConstraintLayout

Monday, June 7, 2021
answered 5 Months ago

All the support libraries are dropping the v4 v7 v12 v13 etc tags and everything is refactored into the androidx packages.

They are essentially the same but for future reference androidx will be the library that we should use in our apps.

Android studio 3.2 canary that comes out this week (week of May 14, 2018) should have the tool that allows automatic refactoring to the androidx packages. There was an announcement about this at google i/o 2018.

Sunday, July 18, 2021
answered 3 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :