Ответ на сообщение Re: Программист. пользователя tolstopuz
> хотя, думаю что он так поступил по простой причине: в ПХП типовые граф. функции работают с этой структурой данных.
Не зная ПХП и приложение, мне конечно сложно говорить как оно лучше, но сдается мне что это не может быть объективной причиной использования массива. Гораздо лучше сконвертировать структуру в массив непосредственно во время работы с граф. функциями, чем гонять данные в массиве по коду. Оверхед на конвертацию настолько ничтожен, что абсолютно незаметен на остальном фоне. А вред от снижения читабельности реален и заметен, хотя может я что-то не понимаю в логике которая behind the scenes.
> Константа потому и была ИМЕНОВАННОЙ. Я писал про втыкание константных значений непосредственно в код проверок...
Скажите пожалуйста, вот есть у меня некий Map (надеюсь в пхп есть такая структура данных), в котором может передаваться по строковому ключу, пусть "price", вещественное значение цены. Этот Map может передаваться параметром в разные модули в качестве ну пусть будет контекста. Означает ли это, что по Вашей религии я должен определить именованную константу PRICE_KEY = "price", которую мне нужно использовать в качестве ключа для вытаскивания значения из Map'а ? Где ее нужно определить? Не имеет ли такое именование каких-то побочных эффектов?
> Вот именно! Он покупает РЕШЕНИЕ, а не предложения по апгрейду...
Речь же всегда идет о разумных рамках, для начала надо определить критерии оптимальности, который всегда подразумевают под собой вполне конкретные требования к железу, а уж потом кидаться оптимизировать, иначе получится оптимизация ради оптимизации, бесмысленная и беспощадная.
Опять же разумные рамки подразумевают, что программист не пишет конструкции в которых нет необходимости, есть разумные правила кодирования - вынесение инвариантного условия за рамки цикла и т.п.
Не зная ПХП и приложение, мне конечно сложно говорить как оно лучше, но сдается мне что это не может быть объективной причиной использования массива. Гораздо лучше сконвертировать структуру в массив непосредственно во время работы с граф. функциями, чем гонять данные в массиве по коду. Оверхед на конвертацию настолько ничтожен, что абсолютно незаметен на остальном фоне. А вред от снижения читабельности реален и заметен, хотя может я что-то не понимаю в логике которая behind the scenes.
> Константа потому и была ИМЕНОВАННОЙ. Я писал про втыкание константных значений непосредственно в код проверок...
Скажите пожалуйста, вот есть у меня некий Map (надеюсь в пхп есть такая структура данных), в котором может передаваться по строковому ключу, пусть "price", вещественное значение цены. Этот Map может передаваться параметром в разные модули в качестве ну пусть будет контекста. Означает ли это, что по Вашей религии я должен определить именованную константу PRICE_KEY = "price", которую мне нужно использовать в качестве ключа для вытаскивания значения из Map'а ? Где ее нужно определить? Не имеет ли такое именование каких-то побочных эффектов?
> Вот именно! Он покупает РЕШЕНИЕ, а не предложения по апгрейду...
Речь же всегда идет о разумных рамках, для начала надо определить критерии оптимальности, который всегда подразумевают под собой вполне конкретные требования к железу, а уж потом кидаться оптимизировать, иначе получится оптимизация ради оптимизации, бесмысленная и беспощадная.
Опять же разумные рамки подразумевают, что программист не пишет конструкции в которых нет необходимости, есть разумные правила кодирования - вынесение инвариантного условия за рамки цикла и т.п.
