вот добавлю еще пример как может выглядеть именно "ядро" ) минимальный фронт контроллер, может выглядеть так: Код (PHP): <?php require_once '../app/boot.php'; // здесь описываются все инструкции для автозагрузки классов $App = new \My\Framework\Kernel(); $App->run(); ну и сам класс Kernel может выглядеть например так: Код (PHP): <?php namespace My\Framework; use My\Component\Http\Request; use My\Component\Http\Response; use My\Component\Routing\Resolver; use My\Component\Routing\Exception\ResourceNotFoundException; class Kernel { public function run() { $Request = Request::createFromGlobals(); $Resolver = new Resolver('/path/to/routing.yml'); try { $Request->attributes->add($Resolver->match($Request->getPathInfo())); $Response = call_user_func_array($Request->attributes->get('_controller'), $Request); } catch (ResourceNotFoundException $e) { $Response = new Response('Not Found', 404); } catch (\Exception $e) { $Response = new Response('An error occurred', 500); } $Response->send(); } } итого меньше 1 кб ) притом всё прекрасно вписывается а всё остальное реализовывается с помощью обвешивания модулями и т.д.
еще есть вот такой маленький каркасик http://www.slimframework.com/, там ядро Slim.php весит 45кб, если у кого есть время и желание скомрессируйте код, расскажите что получится ) ну мне кажется там око 15кб наберется
Если получится уложиться, я же поставил задачу, теперь пытаюсь ее реализовать. Странное поведение сообщества, такое ощущение, что я навязываю кому-то собственные мысли, но ведь это не так. slim.phar.gz - 7кб Именно об этом я и говорил. То есть Slim FW в данном случае обеспечивает свой уровень абстракции при 7Кб. Если код обфусцировать и убрать лишние символы, то получится раза в полтора меньше, следовательно, можно еще задать некоторые возможности.
о! ) дык тогда вот то, что вы ищите! https://github.com/symfony/symfony/blob/master/src/Symfony/ ... Kernel.php 22кб если подчистить, то вполне будет до 10к ЗЫ: "обфусцировать" - это не "компрессия", это запутывание кода. Добавлено спустя 2 минуты 34 секунды: всё хорошо злых людей очень много, в том числе и среди обитателей форума... давайте продожим просто вести конструктивный разговор! если кто-то перейдет на личности, то могу посоветовать проигнорировать его
Одна из целей обфускации: Оптимизация программы с целью уменьшения размера работающего кода и (если используется некомпилируемый язык) ускорения работы.
YSandro всё верно, но в нашем случае, нам достаточно вырезать только комментарии и возможно некоторые пробелы и преводы строк, хотя каментов будет более чем достаточно, чтобы код сохранялся как можно более оригинальным, это удобнее будет при разработке.
Может, тогда, разбить код на дебаг и релиз? В дебажной все комментарии, в релизной всё ужато максимально.
да, конечно и в частности Symfony2 это делает автоматически, в частности на втором проходе кеширования создаётся вот такой файл https://gist.github.com/3028757, наиболее часто используемых классов. а дебаг и резиз, в сф2 это называется окружения "dev" и "prod", они отличаются разными конфигурациями.
d1gi, интересно, конечно про симфони. Кернел весит 45 кб, кеш по ссылке около 278 кб. Вы считаете, сф2 лучше всего подходит к тому ядру, который можно ужать до 10 кб?
YSandro, в этой теме пока что еще явно не прозвучало, что такое "ядро" а гисту я показал как пример минимизнутых классов, для существующего проекта... там не только "ядро"
Мне показалось, ТС хочет разработать что-то принципально новое, показать главенство идеи, идет путем творческого программирования. Потому тут возможны и гениальные решения. Потому очень любопытно, и хочется посмотреть.
просто когда тебе что-то ясно и само собой разумеется, то другим может быть непонятно, что именно ты имеешь в виду. В чужую голову не залезешь. Для кого-то ядро это всё сразу, кроме плагинов. Для кого-то ядро это базовый функционал это голый I/O. Никто ж не спорит. Просто пытаются понять что именно считать ядром, и от этого плясать в задачу.
угу, подождем ТС вдруг и правда увидим что-то новое ну и разумеется прояснится, что он имел ввиду под "ядром".
Извините, не конкретно к вашим словам было сказано, просто, так сказать, мысли вслух, нужно было отделить, разумеется, от комментария вам. Две идеи: 1) есть мысль по поводу обесечения ядром возможности внесения кода в структуру собственного пакета (т.к. пакет кешируется и используется только копия пакета в памяти кэширующего механизма), т.е. искусственно сделать границу пакета границой между dev и prod-версиями. Все что не пакет ядра - то dev, над которым мы работаем постоянно. 2) мы имеем 4 "образующие" сущности, они почти классические, за исключением того, что тут нет вида и модели, которые я не люблю, но есть сущность композитинга (я немного сместил приоритеты деления на сущности, но от этого суть процессов выборки данных, шаблонизации и своего рода, несколько нетипичных контроллеров не изменилась, просто логика несколько другая): K - kernel C - compositor T - templater R - router задача "сердцевины" (K) (это, хм... как ядрышко к клетке, это не то, что я изначально называю "ядром") обеспечивать сборку и доступ к сущностям: $K->C->... $K->T->... $K->R->... Сущности независимы, они являются конечными в своем роде, то есть последовательность и структура обращений между ними произвольны. Все программирование по идее должно сводится исключительно к декларативному (самому элементарному и очевидному) определению действий, начиная с объекта ядра (всегда и во всем): $K->LOAD('mysql', 'M')-> // подключаем адаптер $K->M->... $K->LOAD('module_1','M1'); // или любую сущность $K->M1->... // Каскадная инструкция шаблонизации произвольного набора шаблонов, с произвольным набором данных, определяемый произвольным обращением к любым сущностям: Код (Text): # Это своего рода инструкция сборки какого-либо сегмента сцены # $K->T->V('set_1', 'tpl_name', array( // шаблонизация с выводом из буфера key_1 => value_1, key_2 => $K->T->B('set_2', 'tpl_name', array( // буферизация вывода key_1 => value_1 ... ), )); $K->C->decode(instruction); // Композитинг сцены # instruction - это абстракция над шаблонизацией сегментов, представленная в виде программируемого уровня, то есть, вместо программирования непосредственно на PHP, хотя сущность композитинга предполагает это тоже (например, нативными наборами сборки сегментов с использованием объекта шаблонизации), мы собираем инструкцию или компилируем сегмент в инструкцию, например, вида: URI: shop/bykes/ ~ Instruct: shop/lng:ru/set:main/tpl:simple/par:1/mod:m1#lng:ru/set:second/tpl:main/par:1/#set:some/tpl:hello?/?/ Первый возникающий вопрос: Что это? о_О Смысл в том, что композитинг предполагает определенный базовый функционал, который лишь упаковывает в разные методы собственного объекта принципы сборки разных данных, что нерационально, на мой взгляд, и гораздо правильнее вынести однотипные вещи на метауровень, то есть в рантайм или, если проще - в момент отработки скрипта. Грубо говоря композитор - это своего рода диспетчер сборки, в то время как обычный раутер - маршрутизатор или то, что я называю "реакцией" (часть механизма поведения = раутер + композитор), и я разделяю эту логику по разным сущностям. Исходя из этого, композитор просто декодирует инструкцию, образуя из нее нативный код сборки вида (или не образуя, просто выполнит сборку): Код (Text): $K->T->V( 'key_a' => $K->T->B( 'key_b' => $K->R->uri(...), // следующий шаг маршрутизации до любой сущности или композитинга 'key_c' => $K->LOAD('mod_1','M1')->func(), ), ); Отсюда, очевидно, следует, что раутер, обрабатывая URI, может вызывать не только сущности или явно существующие конструкции композитинга сцены, но и маршрутизировать на декодер композитора, который преобразует инструкцию, раскрыв вложенные алиасы с инструкциями сборки сегментов сцен, относящихся изначально к другим поведениям. home/par:A/alias_new => lng:ru/set:main/tpl:index/par:A/mod:m1#set:$/...?/, где $ - ссылочный механизм в рамках инструкции, то есть по ходу сборки инструкции мы можем решать какой будет инструкция не только ее формальным определением, но и поведением пользователя (все что в URI, после каскада раутинга - параметры подстановки в инструкцию). Это обеспечивает не просто уровень гибкости, а исключительное множество поведений системы (т.к. можно обращаясь по разным URL менять не просто параметр, или маршрут, а менять инструкцию сборки сегментов произвольного уровня сложности). Иначе говоря, раутер может маршрутизировать на декодер композитора, который преобразует URI в инструкцию, включающую совершенно другие маршруты, включая рекурсивные вызовы сборки одной и той же сцены (или разных сцен, но различных инструкций композитинга) с различными параметрами в рамках одного запроса. Таким образом, во-первых, мы больше не привязаны к логике отработки один запрос - фиксированный ответ, так как мы можем собирать композиции сцен из результата работы любых сущностей, определяя принципы сборки в декларативном виде. А, во-вторых, мы не обязаны программировать сцены, достаточно определения ряда инструкций. В-третьих, мы не рассматриваем результат работы системы как генерированную страницу, так как мы оперируем сегментами сцены, следовательно страница - это композиция, которая меняется в зависимости от генерирования или смены сегментов сцен, как в театре - сцена одна, а декорации постоянно меняют место действий. Но это уже совершенно отдельная тема для разговора. P.S. если обфусцировать весь код, то возможно, что примитивный адаптер к БД и декодер со всеми остальными примитивными сущностями, уместятся в 10Кб. Просто весь нюанс в том, что инструкции программируемые, то есть инструкции могут включать ссылки на части самой себя или на результаты раскрытия alias-команд в инструкции, а это сильно кушает место, так как много кода получается.
После второго прочтения что-то становится понятным. Вопрос такой: если всё же стоит задача на универсальность и гибкость системы, то зачем ограничиваться в объеме кода? Не слишком ли высокие начальные требования? Мне вообще нравится такой подход. Напоминает попытку создания живого самодостаточного организма или программу освоения марса, где нужно всё делать компактным, легким, многофункциональным, используемым многократно и т.п. Но как бы не надорваться. Нужен мозговой штурм группы инженеров, огромные наглядные чертежи, экспериментальные сборки, тестеры. Буду ждать первых опытных образцов
С точки зрения проектирования, наверное, да, но для конечного использования я стремлюсь (у меня пока есть эксперименты и модель) сделать функционал таким, чтобы несколько простых правил, задаваемые ядром, покрывали все возможные варианты путем комбинирования, или правильнее, наверное, сказать так: чтобы заданные базовые принципы формировали при аппроксимации принципов комбинирования все множество возможных вариантов решения различных задач с достаточной эффективностью за счет глубокой гибкости разработки. Ведь мы с вами и мир вокруг нас в том проявлении, который мы наблюдаем состоит из 3 основных стабильных элементарных частиц при первом грубом приближении. Так почему бы не строить свои "миры" из нескольких базовых принципов, заданных ядром? Чтобы постараться избежать ошибок проектирования, не увлечься разработкой лишнего, а сконцентрироваться на самом главном. P.S. Я частично (без декодера, так как его не очень просто реализовать, я постоянно меняю языковые конструкции и логику) применил некоторые положения из вышеизложенного принципа в разработке интернет-магазина (frontend, ERP, CRM). В течение месяца мне нужно протестировать его и запустить. Я скину, кому интересно, линк в ЛС, надеюсь на вашу посильную помощь в тестировании. Хорошая цитата (мне кажется ее ранее уже упоминали): "Все должно быть сделано так просто, как только возможно, но не проще." - Альберт Эйнштейн.
Вот ещё приёмчики сжатия строк. Пригодятся, например, для сжатия длинных диагностических сообщений с форматированием, если они прямо в коде, а не в отдельном файле. Код (PHP): $compressed=gzcompress($msg,9); $original=gzuncompress($compressed); Код (PHP): $compressed=gzdeflate($msg,9); $original=gzinflate($compressed); Код (PHP): $compressed=gzencode($msg,9); $original=gzinflate(substr($compressed,10,-8)); Остаётся примерно 51 процент от оригинала. Gzdeflate из них сжимает лучше. Добавлено спустя 24 минуты 59 секунд: Пардон, плохая идея.
Вчера ясно сформулировал один принцип, мне кажется, темы смежны (парадигма и 10К), поэтому напишу здесь, в любом случае, кому интересно, уже прочитали обе ветки: YSandro, вы спрашивали, почему нужны ограничения жесткие, я ответил вам выше, но сейчас позволю себе еще раз ответить на ваш вопрос, потому что буквально вчера я сформулировал принцип, мысли о котором крутились долго в сознании, но никак не сформировалась идея, чтобы ее рассказать: У каждого человека есть, так сказать, кэш-память - та область сознания, в которой мы оперируем неким объемом информации полностью, не теряя деталей, не вспоминая что-то, иными словами, в кеш-памяти содержиться некий образ всецело со всеми деталями и доступ к этому образу мгновенный. Всякий раз, когда мы моделируем что-то, что в своем объеме выходит за рамки кеш-памяти, мы используем некий аналог оперативной памяти (по аналогии с устройством ПК) - иначе говоря, мы стараемся запомнить что-то, чтобы в нужный момент вспомнить и "подгрузить в кеш", чтобы вспомнив, начать оперировать данными в сознании, пытаться строить мысленно алгоритмы и снова запоминать результаты, делая вывод - использовать ли придуманное (смоделированное) решение или нет. Если система очень крупная, то так или иначе, приходится записывать что-то на бумагу или любой иной носитель, рисовать блок-схемы и т.д. Это своего рода внешняя память (выгрузка страниц памяти на внешний носитель). Но буквально вчера я осознал всецело принцип, я о нем упоминал и ранее, но почему-то не так ясно понимал его смысл: Когда мы совершенно естесственно разделяем большую модель на кусочки, которые помещаются в кеш-памяти, затем запоминаем их и при определенных затруднениях с объемом запоминаемого материала выносим эти сегменты на внешние носители (бумага, какой-то текстовый документ, диаграмма и т.д.), то мы сами того не замечая порождаем еще одну сущность - связи между сегментами, которые тоже требуют места в кеш-памяти, в оперативной памяти и на внешних носителях. Иными словами, становится очевидным принцип - чем на большее количество сегментов, размером с наш объем сознания, мы делим информацию, тем большее количество связей между сегментами возникает. С течением времени, объем связей может увеличиться настолько, что он перестанет помещаться в объеме нашего сознания (в кеш-памяти), что вызовет огромные проблемы в проектировании, так как разработчик начнет понимать, что отслеживание зависимостей между подзадачами (между сегментами) вызывает большие трудности, увеличивая время и сложность разработки в целом. Это своего рода swapping на уровне сознания при недостатке оперативной памяти. Что из этого следует? 1) Существует определенный баланс между количеством сегментов, на которые разбивается задача и количеством связей, возникающих между этими сегментами, как следствие, для комфортной, быстрой и качественной реализации проектов, необходимо (если это возможно) делить задачу так, чтобы в объеме нашего сознания (в кеш-памяти) умещались все взаимосвязи между сегментами - это значительно увеличит скорость и качество разработки из-за предельной ясности модели. 2) Очевидно также, что возможна ситуация, когда сегментация задачи порождает количество связей, превышающие объем сознания. Это напрямую свидетельствует о том, что объема кеша разработчику просто недостаточно для хранения всех взаимосвязей сегментов моделируемой системы - это выражается ощущением запутанности кода, хотя на самом деле, каким бы ни был сложным по своей структуре код, он не является запутанным!, т.к. определение "запутанности" исключительно следствие нашего непонимания всего объема связей. В такой ситуации разработчик начинает сегментировать сами связи, что сильно усложняет разработку кода. 3) Объем сознания (кеш-памяти) увеличивается при частом оперировании сложными структурами кода и уменьшается при отсутствии такой умственной нагрузки (теряется навык). Я это объсняю тем, что мозг - адаптивная система, и когда мы не работаем, он оптимизируется, чтобы перераспределить ресурсы, поэтому программировать, на мой взгляд, необходимо постоянно, причем программирование не обязательно выражается в реализации кода, так как программирование - это определение последовательности действий и структурирования таких последовательностей, поэтому, программировать можно абсолютно все и всегда (мировоззрение - относиться к миру, как к операционной системе, в которой совершенно все сущности - программы, в частности, довольно интересно в таком ключе рассматривать микромир (например, функционирование любой клетки), поведения людей, социальные связи, структрирование материи и т.д.). 4) Чем заведомо на меньший объем "кеша" разработчиков и пользователей расчитана система, тем ниже порог вхождения и тем большее количество пользователей и разработчиков могут ее применить себе во благо.