а как конструктор использовать? ?

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

криво

Да, в пхп впринципе можно многое сделать из нормальных языков, только криво ?

IDE много чего не поддерживают или поддерживают через костыли phpdoc анонимные классы умеют в интерфейсы

конечно криво, я о том же. главное что это можно сделать

а что, никаких rfc на область видимости классов в неймспейсах еще не создали? ?

я тебе показал poc для "модуля" в пхп, не более. победила другая парадигма

а что, никаких rfc на область видимости классов в неймспейсах еще не создали? ?

френдли были классы насколько я помню

ZF официально похоронили ;)

кому нужна модульность в php?

кому нужна модульность в php?

прочитал "кому нужна мощность в php"

кому нужна модульность в php?

Тем кто пишет много бизнес-логики, полагаю, нужна довольно сильно.

Модуль это вообще слишком абстрактное понятие. Что конкретно подразумеваете под модулем?

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

Но с концепцией неймспейсов и приватных классов пересекается, и она возможно более мощная.

Ну, это крайне корявое определение, если вдуматься :)

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

> A namespace is a set of some code, like variables, functions and procedures, which can be used in other code. > A file is a set of some code, like variables, functions and procedures, which can be used in other code. > A git repository is a set of some code, like variables, functions and procedures, which can be used in other code. так себе определение

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

В общем чем больше определений читаю тем больше кажется что модули это какая-то притянутая за уши фигня

В общем чем больше определений читаю тем больше кажется что модули это какая-то притянутая за уши фигня

?

Неймспейсы это по факту целое дерево модулей - ты можешь импортировать сразу кучу классов используя более глобальный неймспейс use My\Namespace; , а можешь импортировать подмножество use My\Namespace\Utils

Вот только не хватает inner/private модификаторов для классов, действительно

В общем чем больше определений читаю тем больше кажется что модули это какая-то притянутая за уши фигня

концепция 80х, вот и методы реализации оттуда же

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

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

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

+

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

Второе ты и так можешь сделать

а первое... вполне себе можно решить соглашениями... вон живет питон на соглашениях...

А для первого - представь что ты используешь функцию kek() в своем коде, и импортируешь все из какого-нибудь неймспейса \Spacex\*. Потом кто-то добавил в этот неймспейс функцию kek(), ты обновил у себя модуль, и вуаля, твоя функция kek() модменилась функцией kek() из неймспейса а ты даже и не заметил.

вопрос стат анализа, решается тоже

Так что лучше уж импортировать неймспейс в какой-то локальный неймспейс типа use My\Very\Long\Name\Space\Utils as Utils и в коде обращаться по Utils\kek()

И вроде бы в typescript так же сделано

интерпретатор не нужно, стат анализа достаточно

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

Брать перл это некрофилия

А какая разница как называть если эффект одинаковый?

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

ERROR: S client not available

Так что нет, не смущает.

Брать перл это некрофилия

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

проще ныть про несовершенство пхп

не нужно нафиг... только от совсем идиотов, а им закон не писан

чего ж ты нам их скидываешь?!

Как это не делает ничего? Если ты напишешь use function \My\Cool\func то у тебя func импортируется в текущую область видимости, просто эта область - только файл/неймспейс, мельче нельзя.

можешь указать его руками

автолоад - это автоматический импорт не хочешь автоматическийимпорт - можешь писать руками require профит

не нужно нафиг... только от совсем идиотов, а им закон не писан

ты недооцениваешь людей

смысл сего набора слов мне не понятен

зачем мне это делать?

Ты демагогствуешь. Если после выполнения `use function \My\Cool\func` я могу в файле обратиться к функции `func` используя 4 символа, то это и есть по определению импорт в текущий скоуп. А как это под капотом сделано уже вопрос десятый.

А, ну ты смешал с автолоадингом. Ну так все давно уже композер автолоадит, а мейнтейнеры пакета в "autoload" приписывают какой файл с функциями прогрузить.

Я тебе могу привести аналогию с исходниками в c# - там если файл "MyLib.cs" не прописан в xml конфиге специальном то сборщик этот файл вообще не увидит. То же самое.

Ну в пхп область видимости одна на весь файл, ну и что.

С его привычкой иметь много маленьких файлов это не проблема.

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

На неймспейс в рамках файла, конечно ;) Но в 99% случаев в файле не более одного неймспейса.

область видимости класса не забыл?