Итераторы, коллекции и PHP

dark-demon

d(^-^)b
ну-ка поподробнее. На таком примере:
что произойдёт, если я передам этой функции не экземпляр myObject, а экземляр наследника от myObject?

Как думаешь, SPL'евский RecursiveDirectoryIterator при создании объекта сразу все директории сканирует?
сдаюсь :) впрочем,
если возникает необходимость подобного поиска, то с высокой степенью уверености можно утверждать, что система нуждается в рефакторинге ;)
 

Wicked

Новичок
dark-demon
что произойдёт, если я передам этой функции не экземпляр myObject, а экземляр наследника от myObject?
Я просто не стал описывать класс myObject, иначе я бы его тоже сделал final, как и myCollection. Другой вариант: можно ужесточить тайп хинтинг до get_class() == myObject. Но это технические детали, факт остается фактом: на такую гарантию рассчитывать можно.

если возникает необходимость подобного поиска, то с высокой степенью уверености можно утверждать, что система нуждается в рефакторинге
ну да, RecursiveDirectoryIterator я не использую (но если он существует, наверное он кому-нибудь нужен? :)). Это хороший пример демонстрации того, что на итераторы можно возложить отложенные вычисления.
Кстати, у итераторов есть еще одно приемущество: возможность минимизации памяти. Напрашивается аналогия с DOM vs SAX.
 

dark-demon

d(^-^)b
Я просто не стал описывать класс myObject, иначе я бы его тоже сделал final, как и myCollection. Другой вариант: можно ужесточить тайп хинтинг до get_class() == myObject. Но это технические детали, факт остается фактом: на такую гарантию рассчитывать можно.
замечательно :) пока остальные пытаются сделать свой код менее монилитым - ты сделал совершенно не пробиваемый код.
это уже мания какая-то... "дорожные рабочие учат пешеходов ходить". если я пытаюсь создать наследника - уж наверно не от нечего делать...
 

Wicked

Новичок
Вот последнее твое сообщение совсем не в тему получилось. Ты себя противопоставляешь наличию final и type hinting, что уже за рамками спора "массивы vs. коллекции/итераторы".

К тому же, я не говорил, что такой жестко типизированный код мне нужен всегда. Иногда - да, и я посредством коллекций умею такой делать. И считаю, что уметь так делать - хорошо. Именно в том случае, когда я пришел к выводу, что мне нужен конкретно такой класс объектов в коллекции.

Чтобы сразу расставить точки над i: да, я использую массивы. Если они удовлетворяют условиям конкретной задачи. Если требуется большего, что покрывается итераторами/коллекциями - использую итераторы/коллекции.
 

T. Anre

Новичок
Автор оригинала: Wicked
PHP:
final class myCollection ... {
  public function add(myObject $object) {...}
}
function doSmthWithACollection (myCollection $collection) {
  foreach($collection as $object) {...}
}
Немного неудачный пример использования коллекций.
з.ы. неудачный из-за того, что все монолитно.
 

Wicked

Новичок
Отвечаю обоим.

Потому что в данном примере целью была именно монолитность. Вот пример "зачем": http://phpclub.ru/talk/showthread.php?postid=625883#post625883
Но это, как я и говорил, крайний случай.

Естественно, чаще мне нужна просто гарантия, что у меня в коллекции будут нужные мне объекты. Вот пример коллекции из реального проекта:
PHP:
class apList implements Iterator, Countable {
  public function attach(AccessPoint $ap) {
    if (!$this->contains($ap)) {
      $this->storage[$ap->getMacAddress()] = $ap;
    }
  }
  public function next() {
    next($this->storage);
  }
  ...
}
Такая коллекция далее используется так:
PHP:
class ... {
  public function doSomeWorkWithTheApList(apList $apList) {
    /* @var $ap AccessPoint */
    foreach($apList as $ap) {
      ... $ap->getMacAddress() ...;
      ... $ap->getRssi() ...;
    }
  }
  ...
}
В случае с массивом мне пришлось бы делать лишние проверки на is_array($apList), $ap instanceof AccessPoint, и так далее. К тому же, это было бы полумерой: я хочу, чтобы ошибки возникали при попытке добавить неправильные данные в $apList, а не тогда, когда я попытаюсь эти данные использовать.

-~{}~ 06.06.07 13:39:

Автор оригинала: T. Anre
Немного неудачный пример использования коллекций.
з.ы. неудачный из-за того, что все монолитно.
И ответь мне: что плохого в монолитности если оказалось, что ОНА ДЕЙСТВИТЕЛЬНО НУЖНА.
 

atv

Новичок
...я хочу, чтобы ошибки возникали при попытке добавить неправильные данные в $apList, а не тогда, когда я попытаюсь эти данные использовать.
+1

P.S. Не забывайте, также, и про ArrayAccess
 

dark-demon

d(^-^)b
И ответь мне: что плохого в монолитности если оказалось, что ОНА ДЕЙСТВИТЕЛЬНО НУЖНА.
вот я и просил пример случая, КОГДА ОНА ДЕЙСТВИТЕЛЬНО НУЖНА. варианты типа, запретить пользователю настраивать поведение библиотеки под себя / запретить использовать правую кнопку мышы / не давать сохранять страницу / сделать ещё какую-нибудь гадость прыгающую по экрану - меня не трогают совершенно.
 

Wicked

Новичок
значит монолитность не для тебя, только и всего. Так же, как и эксепшены .-)

вернемся, наконец, к коллекциям/итераторам? еще вопросы?
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
dark-demon, софистика в стиле "докажите что объекты нужны", с последующим оспариванием каждой отдельно взятой фразы - это очень простая, непробиваемая, но абсолютно неэффективная логика.

Нельзя доказать необходимость удобства.
 
Сверху