Я так понял это стиль написание кода?

Жутко интересна разница между

Router::run();

и

(new App('App'))->boot()->dispatch(Request::fromUrl());

_____________
Трус не играет в хокей

Ricco381
Нет. Значит рановато тебе сюда. Или начинай с азов.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

twin

stump
Разница проста. Я могу переписать один только роутер на чистую процедурку, а он нет. У меня класс, это просто обертка. У него другая сущность. Объект. Объект действует сам, а в императиве я определяю последовательность выполнения команд по цепочке.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Почему это так важно знать?
Может я это умею делать но не понимаю расшифровку этого слова....(

twin речь же идет о ООП против Имперетив. Зачем же ООП где реализуется действительно объект и все потом от него зависит переписывать на процедурку? Подумал о функциональном сравнении например:

(new App('App'))->boot()->dispatch(Request::fromUrl());

можно записать как

(new App('Debug'))->boot()->dispatch(Request::fromUrl());

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

Roter::run()

такого не позволяет.

Если сравнивать что можно переписать на процедурку тогда может и сравнить можно ли переписать на ООП? Например как

Roter::run()

переписать на ООП?

По поводу методу сравнения можно подождать немного. Может быть кто-то да и согласиться прийти на помощь в решении спора.

_____________
Трус не играет в хокей

 
$dream = new Vasyuki(); // инициализация и присваивание объекта переменной
$dream->method(); // вызов метода из объекта

Vasyuki::method(); // вызов статического метода из области видимости

Ricco381
Потому, что это и есть предмет эксперемента. Нужно сначала разобраться с парадигмой, потом будет все просто.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

OleKh

OleKh
Если рассуждать логически, у каждого объекта свой стек. А у класса тоже свой, но стаические методы ссылаются именно на класс, а не на объект. Другими словами объект, это копия класса, клон, самостоятельная единица. Потому и ООП, что оперировать нужно этими копиями, против того, что использовать методы, как обычные нативные функции.


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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Если исходить из определения объекта в программировании:
Объект в программировании — некоторая сущность в виртуальном пространстве, обладающая определённым состоянием и поведением, имеющая заданные значения свойств и операций над ними, - то можно предположить что статический класс есть также объектом потому что попадает под это определение. Т.о. статический класс после инстациируется вызовом статических функций, членов класса, т.о. становится статическим объектом. А если рассматривать с другой стороны, то половина определений описаний объекта не может быть применима к статическим классам что может поставить под сомнение их принадлежность к объектам.

Есть ли инстациированный статический класс статическим объектом?

_____________
Трус не играет в хокей

stump
Сейчас опять запутаемся. Парадигма, это это совокупность идей и понятий, определяющих стиль написания компьютерных программ (подход к программированию). Из википедии. К ней не имеет отношение, как устроен PHP, и как там организованы стеки. Важно другое, именно принцип построения программы.

Еще раз повторю.

Вася копает яму - ООП
Выкопать яму - императив.

При ООП мы должны сначала определить сущность и наделить её свойствами. Потом заставлять эту сущность что то делать. Во в примере volter9 :

new App('App')

Создали сущность - приложение. Потом заставляем его действовать.

(new App('App'))->boot()->dispatch(Request::fromUrl());

У меня не создается сущности. Я просто вызываю метод, который находится в классе Router. volter9 может условно создать два приложения и заставить их действовать самостоятельно. Я не могу, я должен сохранять последовательность. Ибо если у меня в классе есть свойство, то оно будет неизменным при любом обращении к классу. А volter9 в одном экземпляре может задать одно свойство, в другом - другое. Вроде круто, но порождает кучу проблем, которые приходится решать паттернами. Вот совокупность этих правил и шаблонов и есть на сегодня ООП. Я от них свободен, но у меня есть другие проблемы. Они тоже решаются своими паттернами и правилами. Которые сильно отличаются от ООП.

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

Быть может я ошибаюсь, вот и хотелось бы поставить... ну не жирную, ну хоть маленькую точечку в извечном холиваре ООП vs императив.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.