Сравнивать можно различные сортировки друг с другом. Думаю, на эту тему много кто писал более серьезные исследования. Я просто взял две сортировки (нативную на PHP и свою реализацию) и сравнил их.
Посмотрел таки в Википедию :) Для реализации полноценной пузырьковой сортировки надо ввести отдельную переменную, которая будет проверять, если ли перемещения элементов в текущем цикле. Если их нет — то сортировка завершена, выход из цикла.
$j зависит $iterations. А $iterations постоянно уменьшается. Т.е. все о чем вы пишите — реализовано.
Спасибо за замечание. Оптимизацию можно провести эвристически :) — реализовать более продвинутые алгоритмы сортировки.
Спасибо всем за критику, замечания и предложения.
Со «своей колокольни» не все видно (или видно недалеко), а так все накидали комментариев по чуть-чуть — понятно что с этим всем делать и что есть в сухом остатке на данный момент.
Чтобы разрешить такие коллизии нужно:
1) Иметь в фреймвопке возможность задавать неогр. количество конфигов к БД.
2) Иметь возможность передавать в скрипт коннекта к БД один из выбранных конфигов.
Тогда будет универсальность и многовариантность применения.
Если требуется из CLI коннектиться к другой базе — то в конфиге CLI прописывается эта база.
В общем конфиге коннекта к этой базе нет, конфиги разделены.
Есть очень много способов решить указанную задачу. Я привел лишь один из них.
что за прикол с двумя конфигами которым нужно ещё и array_merge делать?
Это сделано для того, чтобы указывать уникальные настройки (например коннект к БД) только в одном месте, а потом — объединять настройки из разных файлов для запуска текущей конфигурации приложения.
Например: у нас есть фронтэнд, бекэнд и консоль. Коннект к БД хранится в одном файле.
В каждом приложении мы подключаем конфиг самого приложения и конфиг с настройками коннекта к БД.
Получается просто и универсально (ка на мой взгляд).
Спасибо за идеи куда «расти», как специалист. Я тоже подумывал о чем-то подобном.
Хочется интегрировать программную составляющую (что писать: структуры, сложная логика, объекты и т.п.) и общественно-полезную составляющую (для кого для чего писать, суть самой разработки, её полезность для людей).
Присоединяюсь, к пред. высказыванию.
Как на мой взгляд, расширяя базовый класс исключений, удобно писать сои обработчики на исключения и строить сою логику действий в этом случае.
После какого-то этапа разработки фреймворка его можно применять «в жизни», на реальных проектах.
Мне кажется, что для текущей конструкции этот этап уже наступил — т.е. фукнциоанл перевалил за какую-то граничную точку, когда это уже не учебный проект, а нечто самостоятельное и жизнеспособное.
Если поэксплуатировать этот фреймворк на продакшне в течении 6-9 месяцев (с постоянной доработкой и сопровождением реального проекта) — то после этого срока можно будет сделать програмный редизайн и рефакторинг кода ядра и всего приложения в целом.
Может получиться следующий релиз, качественно отличающийся в лучшую сторону от предыдущего, с более богатым функционалом, протестированный и т.п.
Вот для этого и пишу о поиске реальных проектов.
Добавлял и пересобирал (пробовал разные способы).
На досуге попробую ещё. Спасибо, что подсказали, что так можно сделать. Конечно, подобная конструкция не очень красива.
Получается, что всегда.
«Узких» мест много.
На своем опыте я понял, что чем больше пишешь — тем больше разрастается код, тем больше надо думать об архитектуре и общей схеме вызова компонентов.
Список «К исправлению» увеличивается и увеличивается, а для каждого исправления — надо много читать и думать об оптимальных решениях.
И тесты писать и прогонять их после каждого изменения в ядре.
Положительным моментом всей этой затеи является то, что квалификация и опыт программирования растет так же с исправлением каждой ошибки. Но цена этого опыта — перебор горы пустой породы в поисках того алмаза.
Хотя другого пути нет, никто за человека это не сделает, кроме него самого.
А как?
Я пробовал отключать этот код — но тогда ничего не работает.
Добавлял такие конструкции: "psr-4": {
"Frm\\": "/system/",
"App\\": "/application/"
}
Я писал весь код исключительно для повышения своей квалификации как программиста.
Так как просто читать «о программировании» — это не то.
Надо ручками, ручками — кодить, думать, анализировать.
Спасибо за замечание. Оптимизацию можно провести эвристически :) — реализовать более продвинутые алгоритмы сортировки.
Для Глушкова и его современников началась Великая Отечественная война.
Со «своей колокольни» не все видно (или видно недалеко), а так все накидали комментариев по чуть-чуть — понятно что с этим всем делать и что есть в сухом остатке на данный момент.
1) Иметь в фреймвопке возможность задавать неогр. количество конфигов к БД.
2) Иметь возможность передавать в скрипт коннекта к БД один из выбранных конфигов.
Тогда будет универсальность и многовариантность применения.
В общем конфиге коннекта к этой базе нет, конфиги разделены.
Есть очень много способов решить указанную задачу. Я привел лишь один из них.
Это сделано для того, чтобы указывать уникальные настройки (например коннект к БД) только в одном месте, а потом — объединять настройки из разных файлов для запуска текущей конфигурации приложения.
Например: у нас есть фронтэнд, бекэнд и консоль. Коннект к БД хранится в одном файле.
В каждом приложении мы подключаем конфиг самого приложения и конфиг с настройками коннекта к БД.
Получается просто и универсально (ка на мой взгляд).
Хочется интегрировать программную составляющую (что писать: структуры, сложная логика, объекты и т.п.) и общественно-полезную составляющую (для кого для чего писать, суть самой разработки, её полезность для людей).
Как на мой взгляд, расширяя базовый класс исключений, удобно писать сои обработчики на исключения и строить сою логику действий в этом случае.
Ага, пришел так же к этому (вообще узнал о такой возможности недавно).
Да, буду переучиваться себя на такой стиль.
Одно время были споры по поводу коротких тегов.
Рад что сообщество вернулось к <?=… ?>
Мне кажется, что для текущей конструкции этот этап уже наступил — т.е. фукнциоанл перевалил за какую-то граничную точку, когда это уже не учебный проект, а нечто самостоятельное и жизнеспособное.
Если поэксплуатировать этот фреймворк на продакшне в течении 6-9 месяцев (с постоянной доработкой и сопровождением реального проекта) — то после этого срока можно будет сделать програмный редизайн и рефакторинг кода ядра и всего приложения в целом.
Может получиться следующий релиз, качественно отличающийся в лучшую сторону от предыдущего, с более богатым функционалом, протестированный и т.п.
Вот для этого и пишу о поиске реальных проектов.
На досуге попробую ещё. Спасибо, что подсказали, что так можно сделать. Конечно, подобная конструкция не очень красива.
«Узких» мест много.
На своем опыте я понял, что чем больше пишешь — тем больше разрастается код, тем больше надо думать об архитектуре и общей схеме вызова компонентов.
Список «К исправлению» увеличивается и увеличивается, а для каждого исправления — надо много читать и думать об оптимальных решениях.
И тесты писать и прогонять их после каждого изменения в ядре.
Положительным моментом всей этой затеи является то, что квалификация и опыт программирования растет так же с исправлением каждой ошибки. Но цена этого опыта — перебор горы пустой породы в поисках того алмаза.
Хотя другого пути нет, никто за человека это не сделает, кроме него самого.
С него структуру и копировал (но не только из этого фреймворка, источников кода было много).
Я пробовал отключать этот код — но тогда ничего не работает.
Добавлял такие конструкции:
"psr-4": {
"Frm\\": "/system/",
"App\\": "/application/"
}
Но не дошел до работающей конструкции.
:(
Так как просто читать «о программировании» — это не то.
Надо ручками, ручками — кодить, думать, анализировать.