отпечатка массива в имени вызываемой функции

С. · 25 Дек 2008

Да, действительно register_globals можно использовать по-умному. Но его в РНР6 кажется прикрывают вовсе, если я не ошибаюсь.

А что по поводу индексов неявных массивов? А то, что их никогда их по-умному использовать нельзя. Любое их использование только все портит. Одни недостатки, из преимущество только одно -- сиюминутный выпендреж.

Ну назови хотя бы один реальный пример их полезности, при том, что по-другому будет хуже. Только не надо из каких-то там АПИ. Если АПИ кривое, то это проблема этого АПИ, а не синтаксиса РНР.

А знаю 1 (один) пример использования стандартной РНР функции, где это бы было красиво. И все! Больше ты этого не должен хотеть никогда.

x-yuri · 25 Дек 2008

Любое их использование только все портит.

можно пример с указанием причин почему портит?

nerezus · 25 Дек 2008

> Да, действительно register_globals можно использовать по-умному.
Я не про register_globals, а про func()[item]

> Только не надо из каких-то там АПИ. Если АПИ кривое, то это проблема этого АПИ, а не синтаксиса РНР.
func()[item] мне нужно.
Когда нужно снять 1 элемент с ф-ии.

advocat · 26 Дек 2008

nerezus

func()[item] мне нужно.
Когда нужно снять 1 элемент с ф-ии.

примеры в студию, просто по приведенному выше примеру я привел варианты решения

Иван 76 · 26 Дек 2008

advocat
Да бывают случаи. Море. Возьмите посмотрите Джанго, например.
Другое дело, что в PHP5 можно работать с массивом, как с объектом, и наоборот ( http://www.php.net/manual/en/class.arrayiterator.php )

И ничто не мешает писать func()->item;

Поэтому, не уверен, что эту фитчу начнут внедрять в PHP. Хотя, как знать...

С. · 26 Дек 2008

func()[item] мне нужно.

Да бывают случаи. Море. Возьмите посмотрите Джанго, например.

Ребята, вас же просят конкретные примеры. Сюда. Трудно чтоли?

можно пример с указанием причин почему портит?

• func()[item] мнемонически менее читабильно, чем func(item)
• выражение func()[item] не удобно отлаживать
• изначально закладывается неоптимальность, генерируется больше данных, чем нужно
• "Русский" код преврашается в "индусский". Тот, кто будет модифицировать код после вас думаете добавит переменную? хрена! он сделает:
func()[item]
func()[item2]
func()[item3]

Иван 76 · 26 Дек 2008

С.

Ребята, вас же просят конкретные примеры. Сюда. Трудно чтоли?

Чем не пример Джанго? Или одна строка выдернутая из контекста будет более красноречива? Скачайте дистрибутив, залезьте в ORM.
Примеров будет - море. Выбирай любой.

Не только возврат по индексу, но и возврат по срезу find()[2:5]

Код:

if meta.order_with_respect_to:
                field = meta.order_with_respect_to
                values.append((meta.get_field_by_name('_order')[0], manager.filter(**{field.name: getattr(self, field.attname)}).count()))
            record_exists = False

        try: # Seconds are optional, so try converting seconds first.
            return datetime.datetime(*time.strptime(value, '%Y-%m-%d %H:%M:%S')[:6],
                                     **kwargs)

        except ValueError:
            try: # Try without seconds.
                return datetime.datetime(*time.strptime(value, '%Y-%m-%d %H:%M')[:5],
                                         **kwargs)
            except ValueError: # Try without hour/minutes/seconds.
                try:
                    return datetime.datetime(*time.strptime(value, '%Y-%m-%d')[:3],
                                             **kwargs)
                except ValueError:

x-yuri · 26 Дек 2008

имхо такая конструкция нужна, когда вся информация ни к чему, но класс создавать - лишнее

func()[item] мнемонически менее читабильно, чем func(item)

а если там еще параметры есть func( $param1, $param2, $param3, $item ), то что с читабельностью?

выражение func()[item] не удобно отлаживать

а чем удобнее отлаживать вызов функции в выражении, если отладчик не позволяет узнать возвращаемое функцией значение

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

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

"Русский" код преврашается в "индусский". Тот, кто будет модифицировать код после вас думаете добавит переменную? хрена! он сделает:
func()[item]
func()[item2]
func()[item3]

ты слшком много хочешь имхо, и чтобы индусы хороший код писали, и чтобы отлаживать удобно было, я думаю этот список можно продолжить

мне, на самом деле, если и хотелась такая фича, то очень редко. Может потому, что я один раз узнал, что такое невозможно, и подобные идеи автоматически отсекались :confused:

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

meta.get_field_by_name('_order')[0]

получаем информацию о поле, нам может понадобится как вся информация, так и отдельный пункт. Чтобы быстро получить отдельный пункт в PHP нужно создать класс для информации. Но если класс не нужен пока? Можно создать еще один метод. Но это тоже дополнительное движение
Кроме того, при записи func()[item] лучше видно, что нам все-таки нужно (если индекс строковый)

datetime.datetime(*time.strptime(value, '%Y-%m-%d %H:M:%S')[:6],
**kwargs)

а вот это бы неплохо прокомментировать, мне, например, не очень понятно

-~{}~ 26.12.08 08:06:

т.е. с параметрами func( $param1, $param2, $param3 )['item'] читабельнее, чем func( $param1, $param2, $param3, $item )

advocat · 26 Дек 2008

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

ИМХО, сам подход в корне не верный, простой пример, если мы работает с базой данных, то за получаемые из базы данных филды должна отвечать модель (если берем классический паттерн MVC) да и без разницы нам должно быть откуда взяты эти данные, из DB, кэша или еще откуда

Во-вторых: если мы имеем модель - мы автоматически имеем объект, и соответсвенно гетеры и сетеры еще никто не отменял. Также Есть замечательный паттерн (Property Container)

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

Собственно почему я просил привести конкретные примеры функций, так это по тому, что фактически все ф-ции по умолчанию умеют вернуть 1 параметр вместо множества, или для этого есть отдельные ф-ции

получаем информацию о поле, нам может понадобится как вся информация, так и отдельный пункт. Чтобы быстро получить отдельный пункт в PHP нужно создать класс для информации. Но если класс не нужен пока? Можно создать еще один метод. Но это тоже дополнительное движение
Кроме того, при записи func()[item] лучше видно, что нам все-таки нужно (если индекс строковый)

А вот это и есть не ООП подход к программированию

И повторюсь еще раз, лично например для меня запись например getData('item') более читабельна, чем getData()['item']

Еще одно важное замечание, необходимость использования подобных конструкций типа getData()['item'] отсекается на уровне проектирования

x-yuri · 26 Дек 2008

ИМХО, сам подход в корне не верный, простой пример, если мы работает с базой данных, то за получаемые из базы данных филды должна отвечать модель (если берем классический паттерн MVC) да и без разницы нам должно быть откуда взяты эти данные, из DB, кэша или еще откуда

Во-вторых: если мы имеем модель - мы автоматически имеем объект, и соответсвенно гетеры и сетеры еще никто не отменял. Также Есть замечательный паттерн (Property Container)

есть проекты для которых это излишне

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

не факт, что это будет узким местом проекта. Кроме того, пхп наверняка кеширует информацию о файле

Собственно почему я просил привести конкретные примеры функций, так это по тому, что фактически все ф-ции по умолчанию умеют вернуть 1 параметр вместо множества, или для этого есть отдельные ф-ции

я просто хочу сказать, что иногда такой подход уместен, например, func($param1, $param2, $param3, $i) менее читабельно, чем func($param1, $param2, $param3)[ $i ]. Этот подход можно рассматривать как промежуточный между возвращением одного значения и возвращением класса, когда класс - лишнее

А вот это и есть не ООП подход к программированию
И повторюсь еще раз, лично например для меня запись например getData('item') более читабельна, чем getData()['item']

ООП - не единственный подход к программированию

Еще одно важное замечание, необходимость использования подобных конструкций типа getData()['item'] отсекается на уровне проектирования

либо все, либо ничего? (где-то на форуме видел фразу "догмы мешают программировать?")

fixxxer · 26 Дек 2008

Автор оригинала: С.
Еще одна бессмысленная конструкция. Если вам не нужен экземпляр, то не хрен его создавать:

ClassName::anyFnc()

да ладна

PHP:

$UserList = (new UserSearch)
   ->setSex('female')
   ->setAgeFrom(20)
   ->setWithPhotos(true)
   ->setLocation('Moscow')
   ->find();

x-yuri · 26 Дек 2008

кстати интересный способ задавать именованные параметры))

-~{}~ 26.12.08 14:39:

правда не очень очевидный

Sad Spirit · 26 Дек 2008

Вот что MySQL животворящий с людьми делает, вместо того, чтобы с пеной у рта требовать стандартную функциональность (конструкции (new Whatever)->blah() и getArray()['foo'] во мно-о-о-огих языках работают), они с пеной у рта доказывают, что эти конструкции нахрен никому не нужны.

Что характерно, когда эти конструкции в PHP таки реализуют, те же самые люди будут с пеной у рта доказывать, что Это Сделало Похапэ Ещё Более Хорошим Языком!

Басня "Лиса и виноград", то есть "MySQL и транзакции", часть очередная.

x-yuri · 26 Дек 2008

супер ))))

nerezus · 26 Дек 2008

> они с пеной у рта доказывают, что эти конструкции нахрен никому не нужны.
Да то, что это бред, я уже доказал: они нужны как минимум мне.

Я уж не требую таких вещей, как анонимные классы и т.д.
Просто из-за этого язык кажется игрушечным и теряет удобство, которое от него ожидают.

P.S. интересно кстати услышать, что псевдоаскеты скажут об анонимных классах? Шайтановкий способ для нубов, которые "правильно" писать не хотят, ога?

-~{}~ 26.12.08 15:32:

fixxxer
сейчас начнут возмущаться, что это антипаттерн Blob ))) Уже было такое)

advocat · 26 Дек 2008

кстати интересный способ задавать именованные параметры))

На самом деле - вполне очевидный, тем более в системе с которую я разрабатываю и поддерживаю все делается именно по такому принципу, правда подобный запрос выглядел бы

PHP:

$UserList = Mage::getModel('user/search')
    ->setSex('female')
    ->setAgeFrom(20)
    ->setWithPhotos(true)
    ->setLocation('Moscow')
    ->find();

Вот что MySQL животворящий с людьми делает, вместо того, чтобы с пеной у рта требовать стандартную функциональность (конструкции (new Whatever)->blah() и getArray()['foo'] во мно-о-о-огих языках работают), они с пеной у рта доказывают, что эти конструкции нахрен никому не нужны.

Честно говоря, не совсем понимаю, при чем тут MySQL? Я например не пытаюсь доказать, что подобная функциональность не нужна, я всего лишь говорю, что есть более удобные способы

x-yuri · 26 Дек 2008

На самом деле - вполне очевидный, тем более в системе с которую я разрабатываю и поддерживаю все делается именно по такому принципу

advocat а это касается только бд, или еще чего-то?
fixxxer аналогичный вопрос

С. · 26 Дек 2008

Ну во-первых, следущий код не ахти как отличается от твоего, только без псевдогурманства:

PHP:

$UserList = new UserSearch;
$UserList->setSex('female');
$UserList->setAgeFrom(20);
$UserList->setWithPhotos(true);
$UserList->setLocation('Moscow');
$UserList = $UserList->find();

А во-вторых, думать надо РЕАЛЬНЫМИ примерами, а не абстрактно-красивыми. Ав реальном проекте будет нечто такое:

PHP:

$UserList = new UserSearch;
if (isset($_GET['sex'])) $UserList->setSex($_GET['sex']);
if (isset($_GET['age'])) $UserList->setAgeFrom($_GET['age']);
if (isset($_GET['photos'])) $UserList->setWithPhotos($_GET['photos']);
if (isset($_GET['location'])) $UserList->setLocation($_GET['location']);
$UserList = $UserList->find();

Ну никак это в вашу "вкусную" цепочку не превратить. Я прошу прощения за подрезывание крыльев, но реальность обыденна. Ну сделали РНР5 с его почти настоящим ООП, а после 4 (четырех!) лет его существования, все еще 52% серверов крутятся на РНР4. Потому что настоящий ООП в веб приложениях по большому счету на шиш не нужен. Ну сделали неймспейсы (по просьбам окрыленных товарищей) -- ха-ха (три раза). Будете сдувать с них пыль.

x-yuri · 26 Дек 2008

С. а что мешает эти ifы запихнуть в методы?

advocat · 26 Дек 2008

есть проекты для которых это излишне

тут я позволю не согласиться

не факт, что это будет узким местом проекта. Кроме того, пхп наверняка кеширует информацию о файле

Здесь снова все упирается в проектирование, если нам необходимо использовать больше информации о файле, чем одно свойство, почему изначально не получить все свойства и работать с массивом

Например нам нужно получить размер файла и время создания (а возможно в будущем придется выводить еще какую-то информацию ... В текущем варианте есть минимум 2 классических подхода

PHP:

$fileStat = stat($file);
$fileSize = $fileStat['size'];
$fileTime = $fileStat['ctime'];

и

PHP:

$fileSize = filesize($file);
$fileTime = filectime($fileStat);

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

PHP:

$fileSize = stat($file)['size'];
$fileTime = stat($file)['ctime'];

P.S. Лично я бы предпочел работать с неким адаптером, который умеет представлять всю информацию

ООП - не единственный подход к программированию

Никто не спорит ... все зависит от задачи ... например у меня в одном hight-load проекте на фронте нет ООП по определению ... с целью экономии ресурсов и т.д.

Но для "комфортной разработки", я все же предпочитаю ООП

либо все, либо ничего? (где-то на форуме видел фразу "догмы мешают программировать?")

Это уже ИМХО крайности... Из разряда, Вам шашечки или ехать (с) ?

отпечатка массива в имени вызываемой функции

Продвинутый новичок

Новичок

Вселенский отказник

developer

Новичок

Продвинутый новичок

Новичок

Новичок

developer

Новичок

К.О.

Новичок

мизантроп (Старожил PHPClub)

Новичок

Вселенский отказник

developer

Новичок

Продвинутый новичок

Новичок

developer