Структуры и PHP

[dimagolov]

Так как никто мне не ответил на сколько это будет тормозить в среднем реальном приложении, я застраховался.

Сколько в среднем реально приложении тебе никто не скажет, разве что ты сам сможешь протестировать время генерации с обычными массивами и твоими StructuresFactory через ArrayAccess. Причем сделать это тебе очень легко.

Я понял, что такие прослоики зло, когда переводил RTF парсер из MSDN на PHP и с дуру сделал эмуляцию enum-ов через __set/__get, которые были в оригинальном C-шном коде. Так как создание таких структур происходило на каждом символе в RTF файле, то выкидывание эмуляции (замена просто integer) снизило время исполнение теста примерно с 9 до 7 секунд. Выкидывание из парсера того функционала (структур и состояний) который в реальности не использовались снизило это время до примерно 5 секунд, то есть на столько же.

 

[Lightning]

Сколько в среднем реально приложении тебе никто не скажет, разве что ты сам сможешь протестировать время генерации с обычными массивами и твоими StructuresFactory через ArrayAccess. Причем сделать это тебе очень легко.

Да очень легко. Нужно всего лишь взять какое-нибудь свое старое приложение и заменить массивы на объекты. Но я так гемороится не буду. Все равно у меня в продакшене будут массивы а не объекты, а в дебаг-версии объекты.

Я понял, что такие прослоики зло, когда переводил RTF парсер из MSDN на PHP и с дуру сделал эмуляцию enum-ов через __set/__get

Не нужно делать эмуляцию enum-ов через __set/__get. Нужно делать define, а потом в методе с помощью утверждений (assert) проверять, попадают ли enum-ы в множество значений или нет, а в продакшен версии assert-ы отрубать.

-~{}~ 20.04.09 22:36:

dimagolov
Раз уж ты тут начал писать, можешь ответить на вопросы моего первого поста.

 

[dimagolov]

Я бы использовал всегда в качестве индексов массивов константы и автоматом бы получал нотисы при кривом индексе За одно и от magic numbers бы избавился бы для числових индесков, и спичечную оптимизацию бы получил, так как смог бы использовать не строковые а числовые индексы массивов в итоге.

 

[Lightning]

Я бы использовал всегда в качестве индексов массивов константы и автоматом бы получал нотисы при кривом индексе

Тоже хороший вариант.

-~{}~ 20.04.09 22:49:

Хотя если у разных массивов похожие имена индексов, то можно еще хуже ошибиться.

 

[dimagolov]

Хотя если у разных массивов похожие имена индексов, то можно еще хуже ошибиться.

ничего не мешает делать константы ArrayType_IndexName во избежание путаницы. зато будут использованы простейшие средства языка.

 

[Lightning]

ничего не мешает делать константы ArrayType_IndexName во избежание путаницы

Можно. Но лень каждый раз писать префиксы ArrayType. Но вообще вариант нормальный.

зато будут использованы простейшие средства языка.

Ну и что. Какая разница какие средства будут использованы? Если язык имеет недостатки, их можно компенсировать с помощью различных техник.

 

[Splurov]

Я бы использовал всегда в качестве индексов массивов константы и автоматом бы получал нотисы при кривом индексе

Ради чего? Чтобы вместо ошибки о undefined index было две ошибки undefined constant + undefined index? Или чтобы человеку который после тебя будет разбираться с кодом подпортить жизнь?

 

[Lightning]

Или чтобы человеку который после тебя будет разбираться с кодом подпортить жизнь?

Как раз наоборот.

 

[Духовность™]

Как раз наоборот.

что наоборот? ты предлагаешь под каждый пшик струтуры создавать?

 

[Splurov]

Автор оригинала: Lightning
Как раз наоборот.

А поподробнее?
1) Вместо одной ошибки я получаю две.
2) Я никак не могу узнать создана ли для определённой строки нужная константа или нет (нет, я конечно могу поискать по проекту/по файлу с константами - но это долго и не удобно).
3) Если разработчик констант использовал сокращения моя работа над кодом вообще в ад превращается (типа ARRAY_KEY_DTM для 'datetime' или ARRAY_KEY_USR_ID для 'user_id').
4) Это не распространённый способ кодирования (pear/zf/etc нигде не встречал), т.е. я буду вынужден переучиваться для работы с кодом.
Главное - не понятно какие преимущества от таких замен.

 

[korchasa]

Автор оригинала: Splurov
А поподробнее?
2) Я никак не могу узнать создана ли для определённой строки нужная константа или нет (нет, я конечно могу поискать по проекту/по файлу с константами - но это долго и не удобно).

Ты это увидишь в сообщении об ошибке. Из имени константы обчно можно понять где она лежит (по крайней мере так их надо называть).

3) Если разработчик констант использовал сокращения моя работа над кодом вообще в ад превращается (типа ARRAY_KEY_DTM для 'datetime' или ARRAY_KEY_USR_ID для 'user_id').

Если он использовал сокращения в индексах ассоциативных массивов, то задача проще не будет. Это вообще из другой плоскости.

Автор оригинала: Splurov
4) Это не распространённый способ кодирования (pear/zf/etc нигде не встречал), т.е. я буду вынужден переучиваться для работы с кодом.

Очень прискорбно, ибо это логичный метод избавления от магии чисел.

Автор оригинала: Splurov
Главное - не понятно какие преимущества от таких замен.

В случае опечатке - в рантайме упадет, а не станет скрытой логической ошибкой.

 

[dimagolov]

Splurov, неправильное имя константы это 100% очепятка, а вот отсутствующий индекс может быть как очепяткой, так и ошибкой логики (где-то не прошла инициализация). В этом весь смысл констант перед ассоциативными элементами.