Симонов ДенисMikhail Tchervonenko,

я тебе этим оператором такой порядок наведу что мало не покажется. Сделаю какую нибудь тупую процедуру ничего не делающую и прицеплю к ней все объекты метаданных. Мало того. Раз есть оператор создающий зависимость значит должен быть и оператор её удаляющий. Ну тогда можно тупо у процедур не имеющих execute statement отнимать абсолютно легальные зависимости.


Короче в сад.

наличие select в прцедуре создаёт зависимость и не требует оператора удаления зависимости если этот select из процедуры удаляется.
Почему в предложенном выше синтаксисе такой оператор вдруг должен появляться?
убрал из процедуры объявление зависимости, зависимость пропала.
Не оч. понимаю Вашу логику.

afgmMikhail Tchervonenkoпотому и предлагаю создать оператор создания зависимости...
Филиал Ада на Земле. Это как хинты в комментах (докстрингах) в скриптовых языках, иначе среда разработки не знает чего ждать от метода на выходе. Нафиг-нафиг. :)
я бы сказал иначе, плохой мир лучше хорошей войны
так и хоть какая то легальная возможность создать зависимость лучше чем скрытый код который эту зависимость имеет но не создаёт
По сути это просто метка которая говорит зайди сюда если исправил это, что плохого если она есть? Гораздо хуже когда на продакшене вдруг вываливается исключение которое, при наличии такой метки, можно было избежать

DarkMasterМимопроходящийпропущено...

ну вот мы и достигли консенсуса


... а в 2002 году в epsilon.public.interbase NULL`ы и пиво обсуждали... В общем в тему я так и не вьехал
это просто тут много букафф и пива захотелось чтой то ....

afgmMikhail Tchervonenkoпропущено...

я бы сказал иначе, плохой мир лучше хорошей войны
так и хоть какая то легальная возможность создать зависимость лучше чем скрытый код который эту зависимость имеет но не создаёт
По сути это просто метка которая говорит зайди сюда если исправил это, что плохого если она есть? Гораздо хуже когда на продакшене вдруг вываливается исключение которое, при наличии такой метки, можно было избежать
Я не говорю, что это хорошо, но давайте будем посмотреть вокруг.
T-SQL, PHP, Python ... Пока не запустишь - не узнаешь ничего о работоспособнеос

ну да, но FB ж лучшеж всех должен быть :) хотелось бы пораньше узнавать некоторые проблемы.

п.с. кстати, никто не проверял, если определять переменную с type of column но не инициализировать её, зависимость создастся или нет, может компилятор тупо её выкидывает в таком случае? если нет, то по идее, память она должна начинать отжирать только в момент нициализации или это происходит уже при декларировании? (иначе нафига декларирование всегда надо в начале процедуры писать). По идее это определяющий фактор для выбора: использовать не исполняемый кусок кода или пустые переменные. С переменными было бы короче если не надо инициализировать.

afgmafgm,

случайно отправил.

Пока не запустишь - не узнаешь ничего о работоспособности.
Следовательно Тесты!
Я понимаю желание сохранить всепоглощающий контроль зависимостей в FB. Он и польза и зло в одном лице. Но видимо тот случай, когда теги зависимостей это уже перегиб.
С другой стороны если собирать скрипты через linq-flow-подобный интерфейс, то можно делать это поэтапно и проследить зависимости.
Есть у данного подхода много минусов: и не всякий запрос можно написать, и не везде есть такая магия, и ещё всё это вне БД и т.д.
Надеюсь развитие СУБД и технологий распределения-хранения-обработки данных со временем станет прозрачнее, и гонять данные между потоками <-> кластером <-> БД будет относительно просто и прозрачно. Но это вероятно нескоро, уж больно велик уровень слоёв абстракций у этой луковицы технологий. </поток сознания>

эххх, тесты
видели бы Вы глаза начальников которым говориш что тестирование тоже требует написания кода, времени и соотв. денег. Все говорят о тестах а на практике мало ими пользуются. Сколько контор перевидел, одна из десятка пишет тесты. В основном сидят девочки и тупо лазят по программе, в лучшем случае использую какой то план тестирования и ставят отметки что это проверено. И это в Европе, что творится в Азии, индии или СНГ приходится только предполагать. Опыт показывает что 100% покрытие тестами скорее исключение нежели правило.

afgmMikhail TchervonenkoОпыт показывает что 100% покрытие тестами скорее исключение нежели правило.
100%... У меня чуть все кости в теле не треснули от натуги :)
Основной - деньгосчитающий функционал из прикладной, и ядро фреймворка (своих либ) из общей логики уже хорошо.
Всё завит от реалий, но да, часто работа в не-IT-профильных конторах это "Пиши код, ...ть!!!"
да и в профильных тоже не все в порядке, поверьте, был там ...

afgmКоваленко Дмитрий,

кстати, раз зашёл, вот IBProvider судя по статьям да - это тесты. Но без этого никак. SQLite Well-commented source code with 100% branch test coverage. И много кто ещё. Это системный (не надо придираться к термину) софт.

А по поводу внедрения чего-либо у прикладника, то тут можно только процитировать: "Лучше сделать и просить прощения, чем вечно пытаться выпросить время на рефаторинг/тесты/..."
Часто софт пишется дабы по быстрому получить деньги, что будет потом интересует не очень и будующие ошибки даже приветствуются. Я бы сказал даже таких случаев большинство, по крайней мере мне попадалось. Ситуация обычно такая, напишите нам а поддерживать будет наш мальчик. Потому для фирмы основная заработанная сумма это период написания. Вероятность того что будет поддержка не очень высока. Потому в код закладывается необходимость в будующем что бы к вам обратились. Это может быть ошибка или что то что с изменением даты происходит. (напр. в отчете вписывается фиксированная дата или что то подобное). И если потом возникнут проблемы это хорошо, т.к. в договоре не написано что код не может содержать ошибок, а правка это деньги. Вот такая реальность. На фоне всего этого тесты как бы важны не очень. А вот если в конторе свой it отдел который сам все пишет ситуация меняется, хочется писать так, что б потом не дёргали. Потому всегда говорил, свой хороший спец, а лучше несколько, в итоге будет дешевле чем услуги сторонней конторы. Речь понятно о единичных и не маленьких продуктах. В коробочных заложена другая логика.

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