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

[nerezus]

dimagolov

<?

class someClass { 
    public $msg;
    public static function create() { 
        return new self(); 
    } 
    public function __construct() {
        $this->msg = 1;
    } 
}
class someClass2 extends someClass {
    public function __construct() {
        $this->msg = 2;
    }
}
echo someClass2::create()->msg;

?>

Вот я его наследую...

 

[Dovg]

Dovg А если я ООП использую?
Тогда способ уже не покатит.

ООП - это не только наследование.

 

[demongloom]

Ну вы и нагородили. Тем более что ООП решение применимо только для самому написанного кода, а вот скажем пхп функции которые возвращают массив и нужно значение только 1 ключа. func()[''] - синтаксический сахар, который очень удобен. Простое решение написать просто функцию с коротким названием типа aget( funct_ret_arr(), "key" ); Можно даже сделать через func_get_args() вытаскивание не только первого ключа массива, но и глубже, типа aget( func_ret_arr(), "key1", "key2", "key3" ), что равно func_ret_arr()['key1']['key2']['key3'];

 

[whirlwind]

А можно написать еще короче

a(fra(),"key1", "key2", "key3");

и потом долго втыкать - а что же это значит? Конечно, если был бы сахар, то можно было бы заменить fra на a. Стало бы еще круче

a()["key1"]["key2"]["key3"];

Главное - сэкономить на мускульном усилии пальцев.

 

[С.]

От большого количества синтаксического сахара случается синтаксический диабет. Оптимальность в программе нарушается и бывает одышка при увеличении нагрузки. Мне в аналогичной дискуссии привели пример как было бы хорошо писать:

getAll()['id']

А если окажется, что в getAll() чтение из базы? Нет уж! get All(), get('id') и никаких кремовых розочек!

 

[nerezus]

> А если окажется, что в getAll() чтение из базы?
Приведу аналогию: в целях борьбы с тероризмом запретить стеклянную посуду, чтобы кто-то не смог ранить осколками других людей. Такой же нелепый глобальный запрет.

 

[С.]

getAll()['id'] -- это терроризм всегда, независимо от того, есть там чтение из базы или нет. Это не оптимально, это не читабельно, это не отлаживаемо, это не расширяемо. Без "не" к такому подходят только эпитеты "быстро и грязно".

 

[nerezus]

> Это не оптимально
Почему?

> это не читабельно,
Это твое крайне субъективное мнение. По мне гораздо нечитабельнее придумывать новую переменную только для того, чтобы взять с нее индекс.

С остальным согласен насчет "быстро"

Да и вообще напрягает, что есть такие искусственные ограничения. В других языках нет такого, естественно.

 

[serglt]

nerezus
Твое наследование нифига работать не будет new self будет ВСЕГДА создавать класс
someClass и ты хоть занаследуйся у него будeт ток методы и свойства твоего базового класса.


По поводу getAll()['id'] - тоже за, и раздражает. В 4 - й ветке нельзя было obj -> getObj2 () -> run () делать, в 5 - й можно, дык почему нельзя было еще и эту фичу добавить вместе с (new obj ()) -> run ().

 

[nerezus]

serglt
так я про это и говорил, про наследование, поэтому такой пример и привел. Это мне на прошлой странице так посоветовали Код был опровержением.

 

[serglt]

nerezus
А, ясно, затупил, мои извинения

 

[x-yuri]

А если окажется, что в getAll() чтение из базы?

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

 

[advocat]

nerezus
небольшое замечание по приведенным тобой примерам

$ext = pathinfo($file)['extension'];

если посмотреть ман [m]pathinfo[/m]

$ext = pathinfo($path, PATHINFO_EXTENSION);

так же и со многими другими вещами ... хочется делать
$a = (new ClassName())->anyFnc();
напиши простой врапер типа

function newClass($className, $args = array()){
    return new $className($args);
}
// и используй на здоровье
newClass('myClassName')->myFncFromClass();

 

[С.]

(new ClassName())->anyFnc()

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

ClassName::anyFnc()

 

[x-yuri]

думаю может пригодится, но редко

 

[Иван 76]

Автор оригинала: С.
От большого количества синтаксического сахара случается синтаксический диабет. Оптимальность в программе нарушается и бывает одышка при увеличении нагрузки. Мне в аналогичной дискуссии привели пример как было бы хорошо писать:

getAll()['id']

А если окажется, что в getAll() чтение из базы? Нет уж! get All(), get('id') и никаких кремовых розочек!

Разделяю мнение, но только с точки зрения ортогональности, и не больше.

С другой стороны, очень хочется написать что-то типа:
$model->fetch($primary)['email'];

И таких случаев в последнее время становится все больше и больше. Хотя не проблема писать $model->fetch($primary)->email, но все же.

Что ни говори, а это серьезное конкурентное упущение разработчиков.
Поскольку PHP - задумывался как ортогональный язык, то такой подход соответствует его философии.

Меня долгое время бесило в PHP отсутствие замыканий, анонимных функций. Ничего, к версии 5.3 - пофиксили.
PHP развивается, и недостатков становится все меньше и меньше. Из простого языка он превращается в полноценный язык.
Помните, как когда-то нельзя было вызывать функцию до ее объявления? Давно пофиксили. И этот момент, я думаю, тоже пофиксят.

PHP задумывался как простой и понятный Си-подобный язык. Вышло так, что он стал практически стандартом в Вебе. Он стал популярный, но резко критикуемый за его ограниченность. Разработчикам пришлось, так сказать, - держать марку, и оправдать популярность "подтягиванием" возможностей. Особенно после бума Ruby on Rails. После такого "пинка под зад" оказалось, что можно и ООП нормально поставить, и замыкания, и анонимные функции, и юникод в ядре 6-ки. И, с перепугу, даже Zend Framework разработали, что не может не радовать.

Многих бесит запись типа $text = trim(strtolower($text)), хотя читабельнее $text.lc().trim(). Это позволяет выстраивать понятные, читабельные конструкции.

Вот что интересно. Хотя Питон, в отличии от PHP - это более ярко выраженный ортогональный язык, в некоторых случаях, он предлагает разработчику больше возможностей реализовать одно и тоже различными путями.

P.S.: в какой-то мере, вопрос решается использованием классов Iterator interface, ArrayIterator, SeekableIterator, Countable, ArrayAccess как это делается, например в Zend_Db_Table_Rowset_Abstract

 

[x-yuri]

Разделяю точку зрения.

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

 

[Иван 76]

Кстати да, только сейчас подумал. С точки зрения философии ортогонального языка (каким сегодня РНР назвать уже тяжело), - создателям легче "приучить" программистов к использованию класса ArrayIterator вместо прямого использования массива.

Поэтому не факт, что этот недостаток разработчики будут пытаться пофиксить, учитывая объектно-ориентированный вектор современного программирования.

РНР, как я уже говорил, часто ругают за то, что в нем строка не объект с методами, как в Питоне, Парсере и пр.
value.replace('\\', '\\\\').replace('"', '\\"').replace("'", "\\'")

Так что, я дамаю, РНР пойдет в сторону объектизации строк, а не в сторону расширения возможностей обработки массива.

 

[С.]

Да и вообще напрягает, что есть такие искусственные ограничения. В других языках нет такого, естественно.

Чтобы не убеждать каждого новичка, что register_globals это плохо, вводят ИСКУССТВЕННОЕ ограничение. Правда все равно находятся баобабы, которые начинают эмулировать этот register_globals, потому что им так удобнее (см. пример на форуме за прошлую неделю).

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

 

[nerezus]

С. Почему ты думаешь, что это плохо?
Потому что многие не смогут использовать правильно?
А если я могу, но мне это запрещают, мотивируя тем, что мол, вот есть балбесы, и они могут ошибиться?

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

Тогда почему должны страдать все?

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