roskoshinsky

Коллеги, я ошибся в приведённом примере кода, ясно что вместо this там должен был быть oObject. Но самое главное, я не уточнил, что речь идёт о Google Script и в нём метод виден при перечислении свойств. Однако, решение NaN помогло. Единственное, что первы аргумент не Object a Object.prototype. Спасибо, NaN!)

Никто не привёл ни одного сколько-нибудь весомого аргумента в пользу ООП на PHP. Всё упирается «дружище, эх, попробуй и поймёшь, как это круто»

Если мы создаём GUI-приложение, которое работает пока пользователь его не остановит, то там ООП действительно целесообразен, как минимум в процессе программирования интерфейса. Но в случае с PHP программа работает доли секунды (пока обрабатывает запрос) и тот же интерфейс программировать не нужно. Задачи программы на PHP: быть понятной, быть быстрой. И оба эти случая не об ООП.

Чтобы быть понятной, программе нужна простая дружелюбная логика (это самый важный уровень абстракции, о котором забывают), код без дублей и документация. Чтобы быть быстрой ей как минимум не нужен лишний синтаксис.

Анализируя тот же Laravel я вижу пару хороших вещей, которые логичнее реализовать в функциях и кучу кода ради кода.

Вот пример https://laravel.ru/docs/v3/database/fluent
$users = DB::table('users')->get();

Но ничто нам не мешает написать полиморфную по логике функцию q():

$users = q("users");

Эта же функция может принимать SQL-запрос или более сложную над-SQL конструкцию, но при этом более понятную, чем цепь методов. Кто-то может возразить, что функция будет привязана к одному виду базы данных, но тем я напомню, что в зависимости от типа используемой базы ничто нам не мешает загружать нужный файл с соответствующей реализацией функции, к примеру, mysql.db.php postgresql.db.php

Если логика процедурного кода сбалансирована, если нет дублей кода, если есть документация, то процедурный код будет лучше любого ООП кода по двум критериям: доступность для понимания, скорость работы. Учитывая, что ООП-код тоже требует балансировки и документации, преимущества процедурного становятся абсолютными.

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

foo(a, b);

Если определён аргумент а, но b не определён, то функция возвращает квадрат a. Если определены a и b, то возвращается b в степени a, то есть в некотором смысле аргументы меняются смысловой нагрузкой.

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