mechanic 45

По совместимости — как быть со сторонними библиотеками? Там все классы.

Главное не мутировать их, а так, использовать. Почему нет? Да, это не чистое ФП, но упростить разработку если классные библиотеки стоит того. В целом, мы же не на haskell кодим в конце концов. Но, я именно не против классов, а против парадигмы ООП и принципов SOLID в ООП. Но, судя по вашим ответам, в коммерческой разработке всё как было 7−8 лет назад.

Для интерпрайз такой подход невыгоден (и еще по многим причинам)

Я думал в ентерпрайзе всегда самописы. Laravel — для 80% проектов избыточен. Покажите мне хотя бы один проект, где Лара уместна. В крайнем случае CI4.

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

Данные все в БД, будь-то Редис, Мускул, или Постгрес.

Но тогда как мы отличим массив с данными пользователя от какого-либо другого? Возрастает вероятность ошибки

Честно, немного не понимаю по поводу данных. Делаем запрос через функцию к БД. Получаем массив данных. Присваиваем его переменной. Всё. В переменной данные пользователя либо пустой массив. Далее через функцию структурируем или сортируем, разделяем. Зачем данным пользователя или приложения кочевать по приложению? Получили, обработали, вернули. Основной принцип ФП это получить данные, обработать, вернуть данные, без побочек. Строгую типизацию задаем в файле declare(strict_types=1); функции явные без побочек, например function getSessionValue(array $session, string $key, $default = null) { return array_key_exists($key, $session) ? $session[$key] : $default; }

По автозагрузчику функций тоже нет ясности, где писать require, который загружает необходимую функцию для другой функции? В этом же файле? Тогда это будет require_once во избежание конфликтов, который не особо хорош для производительности. Да и вообще разделение на большее количество файлов проблемно для производительности в целом.

require_once и require особо не заметите разницу при подключении, даже десятка файлов. Но, если подключите 2 одинаковых файла через require, то получите ошибку redeclare по функциям, что прямо укажет на ужеподключенный файл. Так же через spl_autoload_register можете подключать группу файлов с namespace к примеру. определили логически функции в директории src/users/notify, message, profile к примеру и через автозагрузчик коннектите группу файлов с namespace Users; Всё. Используете методы. Но опять же, прелесть в тонкости. При автолоадере классов вы тяните все, даже те, которые не используете. Например класс сессий или коннекта к БД, хотя страницы статичны. Зачем? Это как на странице без интерактива использовать vuejs.

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

Это добивается путем согласованности. Например все публичные функции пишем в snake_case или camelCase, а вспомогательные с __ или другим префиксом. Согласовать со всеми командами более чем легко, написав небольшой readme.md, тем более во многих языках написание определяет многое, как CONSTANT, $_SERVER и прочие синтаксические конструкции. Ну и следовательно такую функцию можно вызвать только преднамеренно. И логично, если разработчик подключает файл группы функций, то он осознано будет использовать его, что прямо не гарантировано при автозагрузчике классов

+ Если есть наглядный пример из прода, напишите его, где классы решают проблему, которую не решают функции.

Я просто наоборот, не вижу преимущества классов. Всё сообщество разработчиков вроде за строгую типизацию, но в тоже время используют мутабельность. Как такое возможно? Типа метод должен возвращать всегда int, но создав экземпляр класса можно его переиспользовать не для dogs, а для cats? Конечно, пример так чебе, но смысл его ясен вероятно

+ Если функции в одном пространстве имен, то с аналогичным названием функции, будут в другом пространстве имен. Если же функции по сути своей совпадают, то их можно использовать в новом файле пространства имен без переопределения класса или абстракций. Мне кажется это более прозрачно. Так же тесты легче проводить в виду изолированности групп функций. т.е. 1 файл — 1 тест. без зависимостей, без вложенности и мутабельности. Всё явно и просто для отладки. А как с тестами в дочерних классах? Что бы оттестить класс, надо размотать всю цепочку? И даже размотав нельзя поправить, т.к. базовый класс может похерить все наследования, абстракции и экземпляры, которые отличаются от базового(что логично).

Предлагается выше, что один файл — одна функция

Где предполагается? 1 файл — набор функций определенной группы с указанным namespace.

Ввиду отсутствия мутабельности и наследования нет мондража при оптимизации или обновлении файла под условно новую версию PHP. В случае с ООП придется проверить всех наследников, либо экстраполировать, создавая новые наследования и в них вносить изменения, что может привести к пропорциональному росту проекта, где первыце классы будут устаревать без изменений, но не смогут выбыть ввиду зависимостей наследователей. Так же, кто мешает создать автозагрузчик файлов определенных групп через spl_autoload_register и далее использовать config\database();?

Я на LibArea начал изучать PHP т.к. мне надо было сделать проект этот именно на PHP.

Так она так же написана в парадигме ООП). Ну, по большей части. Я пытался написать небольшой проект, который в процедурном стиле занял бы 5мб кода, в ООП занимает более 15 + проект не завершен. Отладка, тесты, инкапсуляция, абстракции и прочие паттерны приводят к тому, что казалось бы простой код разрастается на 20 файлов и где именно происходит падение становится сложно отследить. В то время когда при процедурном подходе всё четко и ясно. Есть строка, есть ошибка. Код выпролняется сверху вниз. Тестами покрыл и наслаждаешься. Посмотрел все более менее популярные движки, по типу DLE, InstantCMS, Magenta, Wordpress там в целом смешанный подход. Используют процедурку с элементами ООП. Вот мне и стало интересно, сообщество разработчиков усложняет написание кода, т.к. кодовая база увеличивается в несколько раз, а следовательно и оплата растет пропорционально, или действительно такая проблема? Я не беру сейчас в пример энтерпрайз проекты с сотнями разработчиков и десятками микросервисов. Там каждый сервис на своем языке могут писать. Я в целом про 80% веба и систем на PHP

+ Подытожу. Я считаю преднамеренными действиями сообщества программистов для увеличения кодовой базы и, соответсвенно стоимости оплаты. Всё это подано под соусом удобства разработки командами, повторным переиспользованием и вот этим вот всем, но что мешает набор функций распределять по разным файлам с четким названием? Да и мультиинструмент всегда хуже узкоспециализированного. переиспользовать код, а после внесения правок в класс, при необходимости, обрушить систему, т.к. забыл где и когда переиспользовал метод класса или сам класс, или команда других разработчиков наследовала твой класс и написала своего динозавра — такое себе. По мне есть четкая функция и она выполняет только определенные действия. Меняя её четко понимаешь, что везде логика срабатывания едина и изменения её не принесут неожиданного результата

Последние прочитанные статьи подтверждают обратное. Даже этот проект придерживается ООП, хотя его можно уместить в сотню функций. Те же codecanyon сплошь и рядом завалены Laravel проектами, хотя по сути возможности фреймворка избыточны для них.

Сделал небольшое обновление.

Добавил немного визуальных улучшений: фон теперь с градиентом, модули тоже получили скругления и плавные переходы. Появились дополнительные SVG-элементы. Теперь можно выбрать размер экспортируемого кода — до 4000 пикселей.

Также улучшил скорость работы и генерации. Обновил сканер — фон больше не мешает распознаванию.

Если будет время, попробуйте сервис и напишите, что думаете. Любая обратная связь для меня очень важна.

На сервере еще редирект настроить надо с http:##bc_1####bc_1## Постоянно попадаю на 401 ошибку при авторизации)

Я не понимаю, в угоду чему редизайнят? Ну, в смысле на, что ориентируются? К примеру при разработке использую сервисы анализаторы скорости запросов и их выполнения. Даже условный lighthouse в панели разработчика может определить первые звоночки. Без оптимизиации скорости выполнения и UI удобств, такие редизайны выглядят редизайном ради редизайна

Возможно чуть не в тему, но в тему системы. Периодически форма авторизации выдает 401 ошибку если ввести неверный пароль. такое только с ПК. Заходя с телефона — проблем нет, появляется сообщение о неверных данных.

Доделал сайт и переехал на новый домен.

Теперь размещаюсь на https://radiola.pro — как старые радиолы))

Вопрос к пользователям:

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

Спасибо пользователям. Исправил замечания, добавил PWA приложение, оптимизировал загрузку DOM элементов. Установил на ПК PWA в качестве плеера. Если есть у кого возможность, посмотрите еще, есть ли какие замечания. Критика любая очень приветсвуется

Спасибо еще раз. Нашел причину. Вся проблема в эквалайзере была. Перезапускал поток, что приводило к сбрасыванию установленной громкости.

Спасибо. Были замечания по плавности работы UI. Поправил. Сейчас должен работать быстрее и анимация плавнее

Спасибо. Это баг, поправлю.

В хроме мобильном и десктоптном такого эффекта нет.

Попробовал повторить:

Выставил громкость на 60, включил эффект и переключил станцию следующую, предыдущую. Так с тремя эффектами проделал. Попробовал в firefox 115 версии. Всё нормально переключается. Единственное скролл надо привести в порядок, он по дефолту. Можете подробнее описать последовательность действий? Спасибо

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