но это известная трабла и не пыховская https://stackoverflow.com/questions/48469534/sdl-window-not-displayed-in-windowed-mode-in-macos

ну да, если ты дурачек и вызываешь unserialize

но вообще сама по себе десерализация не делает обьект мутабельным

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

ну так ты же не можешь заставить пых юзать новый обьект при десериализации. Он себе тихонечко создал обьект без конструктора, а deserialize считай оверлоалом конструктора.

С таким же успехом можно конструктор вызвать и сказать, что обьект мутабельный.

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

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

ну да, это просто неприспособленность пхп к таким вещам)

Вот только какая связь между десериализацией объекта и методом "unserialize"

прямая?

это обычный метод Serializable интерфейса

который пыхом используется под капотом

Ну и что, что часть интерфейса... методом то остается. Не, понятно что можно $obj->__construct вызвать, но это уже извращением попахивает, и, к слову, тем и хорош именованный конструктор

всем привет. пишу либу для хранения файлов, есть 3 класса: Manager, Storage и File.
Manager является, по сути, основным классом, внутри которого реализованы методы store, get, delete. Он же работает с базой.
Storage - класс чисто для работы с файлами и директориями. в нём есть upload, отдающий объект File после загрузки файла. этот метод дёргается из Manager::store перед тем, как записать файл в базу.
File, если по-простому, то модель файла.

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

плюс хочу организовать очистку пустых директорий.
название файла при загрузке генерится из md5+timestamp. после этого из этого имени нарезаются названия подпапок (не помню названия этого способа, но до определённого уровня вложенности с начала названия файла отщипываются куски и с их названиями создаются папки). например, файл b4bfcf6443db07298095fd21bf58479b_1584557369.jpg будет лежать в uploads/b4/bf/. после удаления файла папки b4/bf останутся, а хотелось бы их подчищать, убедившись, что они пустые. есть ли смысл закладывать такой функционал в тот же File::delete()? или лучше вынести это в Storage и там уже сканировать uploads и удалять всё, что пустое?
спасибо

если запутанно описал суть, могу на пастбин вылить либу

Почему бы league/flysystem не использовать?

так захотели выше)
но всё же у меня вопрос больше не по поиску инструмента, а по проектированию

Т.е. тебе прямо сказали «ничего готового не юзать, плить с нуля»?

Ответь честно — тестовое задание?

Посмотри как спроектирована либа ;)