@ruslite, ваша программа хранит данные в памяти, если ей нужно только 20 метров, то смысл тащить туда больше данных? быстрее она от этого не станет. Единственная причина по которой программа может работать быстрее при увеличении использования оперативки - уменьшение количества операций доступа к файловой системе. Тут да.
@ushim, в смысле? вы сохраняете из php html страницу, запускаете через exec скрипт, который эту страницу конвертит в pdf, удаляете если нужно html и отдаете его пользователю.
@Yuxus, мне кажется в каждом холиваре указывают что это не совсем асинхронность. У вас не могут выполняться две задачи в паралели, только что-то одно. Это скорее мультиплексирование, когда пока мы ждем чего-то можно что-то еще поделать.
@krll-k, раньше люди писали на великом и могучем ассемблере, а потом пришли всякие хипстеры со своими B/С/С++ и т.д. Не от хорошей жизни IDE появились.
По поводу автокомплита для саблайма - честно, не использовал, но знаю что какой никакой а автокомплит туда прикрутить можно. Ссылку я дал.
phpDocumentor несколько для другого предназначен все же.
@SamDark, ну да, согласен. Лет 5 назад я сам занимался такой фигней как написание своего фреймворка, скорее для саморазвития, и архитектура у меня была очень схожа с той, что в yii. Потому я и использовал его после этого еще два года.
@amir73911, можете попробовать сначала реализовать на html5 и обратить внимание как это дело будет работать на андроидах (по идее с версии 4,4 все будет не так плохо), ибо на iOS в силу некоторых особенностей меньше проблем с плавностью UI.
И там уже думать, переносить на unity или нет. В любом случае этот вариант довольно затратный по началу.
есть разница, использовать PhpDoc в коде, и генерировать документацию по проекту на основе PhpDoc. Регламентировать там типа аргументов и что возвращает функция - это одно. А поддерживать документацию в актуальном состоянии - совсем другое.
@raycheel, свой MVC - врятли. Википедия разве что. Вообще MVC это такая абстрактная вещь... Лучше реализуйте пока фреймворк, позволяющий вам делать то, что собственно ему придется делать - обрабатывать запросы и возвращать ответы. Посмотрите на symfony/httpkernel, в частности на интерфейс HttpKernelInterface. Как довод к тому, что стоит его использовать в своих реализациях, можно привести возможность использовать готовые мидлвары.
А как именно идет обработка запросов - там уже можно применить и MVC, и SOA и что только угодно.
@raycheel, yii не очень хороший пример хороших практик в плане архитектуры приложения. Он нарушает все принципы SOLID, реализация некоторых моментов в нем уж сильно спорная (вторую версию я видел мельком, расстроился и не стал глубоко всматриваться), у него не предсказуемый цикл релизов и т.д.
По поводу Dependency Injection Container, пожалуй лучшая в мире php реализация, это PHP-DI. В частности автоконфигурирование на основе рефлексий.
По сути профит от таких штук в этом: ваш фреймвор разделен на много небольших компонентов, каждый из которых реализует какой-то интерфейс (RendererIterface, LoggerInterface и т.д.). То есть компоненты системы знают только то, что им должны передать какой-то компонент, имплементящий такой-то интерфейс.
В конфиге у вас задано, что для такого интерфейса нужно использовать такую-то реализацию, и DIC, когда у него затребуют какой-то компонент, сам создаст инстанс класса, передсат ему интансы сервисов, от которых зависит наш, и нам не нужно писать всякие new MyFooService, все за нас делает dependency injection.
Так как компоненты системы ничего не знаю о реализации, мы можем их подменять. То есть если нам вдруг понадобится заменить реализацию RendererInterface на другую (например, другой шаблонизатор), то мы просто в конфиге прописываем соответствие этого интерфейса нашей нужной реализации, и все. DIC уже сам будет инджектить то, что нам нужно.
Так же дополнительные плюшки мы получаем, если покрываем код юнит-тестами. Скажем, вместо того, что бы в тестируемый класс засовывать другие классы, мы можем заинджектить мок какого-то интерфейса, проследить что все было выполнено, и наш тест одного класса не будет зависить от других реализаций.
Словом, слабосвязанные системы - это наше все. А yii относится к сильно-связанным, что налагает определенные ограничения и уменьшает расширяемость.
@Blumfontein, тогда уж почитать цикла статей об устройстве symfony и концепции request/response. Сделать еще один фреймворк на базе HttpKernelInterface.
приятнее взять какой-нибудь silex c доктриной/пропелом/любая другая ОРМ по вкусу, и делать дела, а не страдать фигней. Писать свой фреймвор выгодно в плане обучения, но использовать его в продакшене... это было модно лет так 5-6 назад.
По поводу почитать - почитайте про ООП, про SOLID, поищите ответ на вопрос "почему декораторы лучше наследования" и т.д.
