Про меня тут уже наговорили гадостей, и про мое мышление и про качества мои деловые и еще что-то было. Не стесняйтесь, высказывайтесь дальше, вы же в интернете :)
Вы совершенно правильно все пишете. Но совсем бессмысленно спорить с людьми, у которых срабатывает защитная реакция на то, что они (совершенно неправильно) воспринимают как снобизм и попытку вытащить из уютного мирка, где знания не нужны, а неудачи легко объяснить тайным заговором больших компаний.
Все что вы описываете уже примерно так и работает, с поправкой на то, что когда вы редактируете имя переменной вы можете как и просто отредактировать текст в этом месте, так и отредактировать имя того что вы называете «виджетом» (Shift+F6 в популярных ide).
Вокруг неуниверсальных графов и их проекционного представления в виде текста (как наиболее универсального формата сериализации «графа») построены вообще все современные ide, компиляторы и статические анализаторы.
в котором есть инструментальная поддержка, я подавляющее большинство случаев ищу объекта по связям
А инструментальная поддержка легко может учитывать, что сильно связанные компоненты скорее всего лежат где-то рядом и начать искать с текущей, а потом соседних папочек. Собственно, студия так и ищет :)
Вы назвали папки не абы как и человек может выбрать из них нужную.
У меня сомнения в этом месте. У меня не получается придумать такое правило, чтобы хэш-таблицу или преобразование ключа в путь построить не получилось, но при этом можно было построить поисковое дерево (конкретно на примере структуры проекта — папки и файлы с исходниками).
И даже если такое правило можно придумать — в реальном мире он будет нарушаться, а при любом нарушении придется обходить дерево полностью.
Другой вопрос, что семантика узлов в дереве может влиять на вероятность нахождения файла в том или ином месте, поэтому можно получить выгоду варьируя порядок обхода.
Ну и для совсем общего поиска все-таки выгоднее построить нормальный индекс.
UPD Короче, я согласен что поиск в дереве в общем случае имеет меньшую сложность чем линейный поиск по списку (это правда не означает, что он всегда быстрее), но конкретно обсуждаемая задача в реальном мире решается по другому.
Я не осилил дочитать эту ветку до конца, но, проходя мимо, замечу, что некоторые IDE (например, Visual Studio) совершенно точно (и это очень очевидно даже если не лезть в исходники) используют знание о разложении кода по файлам, а файлов по папочкам, а так же семантику папочек, для ускорения некоторых видов поиска, в том числе тех, которые нужны для автоматизированных модификаций-рефакторингов.
UPD. Пожалуйста, раскладывайте код так как принято в приличных домах, сделайте жизнь вашей IDE проще :)
UPD. Ну и да, использовать для поиска по проекту дерево как структуру данных — совершенно дурацкая затея.
Которое вполне может быть обработано кодом выше по стеку (и это нормально). Только вот без finally код после блока не выполнится, и вы можете легко получить неосвобожденный ресурс.
в Исключение надо залогировать ошибку и вызвать оператор ВызватьИсключение. Если без параметров — то прокинется исходное исключение, если с параметром — то будет исключение с текстом, который мы передадим.
И если я например хочу освободить какую-нибудь блокировку при выходе из функции, то мне надо это освобождение написать в нескольких местах и следить за тем, чтобы случайно ее не забыть?
Что будет если «Обработка исключения» тоже бросит исключение? А что делать если я в «Обработка исключения» просто хочу залоггировать исключение и пробросить его выше по стеку?
Поразжигаю. Расскажите, пожалуйста, как решить такую задачу:
1. Создаем фоновое задание, которое запускает еще 1000 фоновых заданий, которые что-то считают. Родительское задание должно дождаться всех дочерних и, скажем, сложить результаты всех и отдать вызвавшему.
2. Запускаем 1000 таких фоновых заданий, дожидаемся выполнения, складываем результаты.
Ага, должны выполниться 1001000 фоновых заданий :)
На .net или java эта задача, строго говоря, решается вообще без async/await и корутин, но с ними гораздо проще и красивее.
С офером, ради которого я ушел получилось совсем интересно: благодаря ему я смог перепрыгнуть в Java-разработку и вот уже два года юзаю IntelliJ IDEA вместо Конфигуратора, о чем не жалею ни секунды.
Если нужно поговорить о низкоуровневой (да и высокоуровневой иногда) многопоточке, то и о CPU неплохо знать.
Вы совершенно правильно все пишете. Но совсем бессмысленно спорить с людьми, у которых срабатывает защитная реакция на то, что они (совершенно неправильно) воспринимают как снобизм и попытку вытащить из уютного мирка, где знания не нужны, а неудачи легко объяснить тайным заговором больших компаний.
Вчера получил очередное письмо из Амазона с предложением релокации в Мадрид. ЧЯДНТ?
Известные мне IDE парсят/индексируют код один раз и потом инкрементально обновляют дерево при изменениях.
И ide построенная вокруг идеи универсального графа есть — www.jetbrains.com/ru-ru/mps/concepts/index.html#projection-editor
Вокруг неуниверсальных графов и их проекционного представления в виде текста (как наиболее универсального формата сериализации «графа») построены вообще все современные ide, компиляторы и статические анализаторы.
А инструментальная поддержка легко может учитывать, что сильно связанные компоненты скорее всего лежат где-то рядом и начать искать с текущей, а потом соседних папочек. Собственно, студия так и ищет :)
У меня сомнения в этом месте. У меня не получается придумать такое правило, чтобы хэш-таблицу или преобразование ключа в путь построить не получилось, но при этом можно было построить поисковое дерево (конкретно на примере структуры проекта — папки и файлы с исходниками).
И даже если такое правило можно придумать — в реальном мире он будет нарушаться, а при любом нарушении придется обходить дерево полностью.
Другой вопрос, что семантика узлов в дереве может влиять на вероятность нахождения файла в том или ином месте, поэтому можно получить выгоду варьируя порядок обхода.
Ну и для совсем общего поиска все-таки выгоднее построить нормальный индекс.
UPD Короче, я согласен что поиск в дереве в общем случае имеет меньшую сложность чем линейный поиск по списку (это правда не означает, что он всегда быстрее), но конкретно обсуждаемая задача в реальном мире решается по другому.
UPD. Пожалуйста, раскладывайте код так как принято в приличных домах, сделайте жизнь вашей IDE проще :)
UPD. Ну и да, использовать для поиска по проекту дерево как структуру данных — совершенно дурацкая затея.
А с чего вы взяли что это не так?
Которое вполне может быть обработано кодом выше по стеку (и это нормально). Только вот без finally код после блока не выполнится, и вы можете легко получить неосвобожденный ресурс.
И если я например хочу освободить какую-нибудь блокировку при выходе из функции, то мне надо это освобождение написать в нескольких местах и следить за тем, чтобы случайно ее не забыть?
Спасибо вам за теплую статью от разработчиков Rider и ReSharper :)
Будем рады, если спросите. Попробуем помочь и сделать лучше :)
Я поспорю. С точки зрения прикладного разработчика многопоточности там нет, там есть многозадачность и некоторый параллелизм.
UPD Примерно в том же смысле, в котором наличие web workers не делает многопоточным javascript.
1. Создаем фоновое задание, которое запускает еще 1000 фоновых заданий, которые что-то считают. Родительское задание должно дождаться всех дочерних и, скажем, сложить результаты всех и отдать вызвавшему.
2. Запускаем 1000 таких фоновых заданий, дожидаемся выполнения, складываем результаты.
Ага, должны выполниться 1001000 фоновых заданий :)
На .net или java эта задача, строго говоря, решается вообще без async/await и корутин, но с ними гораздо проще и красивее.
cc: lair Neikist
Из крупных продуктовых, кажется, все. И некоторые — в очень хороших столовых.
На Java/Kotlin с IDEA проекты и в 1С есть…