- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
private void аффинныйШифрToolStripMenuItem_Click(object sender, EventArgs e)
{
foreach (Form childForm in MdiChildren)
{
childForm.Close();
}
foreach (Form f in this.MdiChildren)
{
return;
}
Affiniy af = new Affiniy();
af.TopLevel = false;
af.Show();
tabPage1.Controls.Add(af);
af.WindowState = System.Windows.Forms.FormWindowState.Maximized;
}
Попросили посмотреть код. 15 методов с различными простейшими шифрами, но чудо foreach -> return, присутствует в каждом. И не лень кому-то было...
Follow us!
tabPage1.Controls.Add(af);
случайно был найден аналог MDI
Автор пришел из мира SQL :)
А форич с ретурном это стандартная идиома в хранимках...
btw, стрёмные ассоциации - return next означает отложенный возврат текущей строки курсора
вроде ж субд без блядского 100 летнего багажа, неужели нельзя было адекватное слово подобрать, чтобы не приходилось в хелп лезть
и да, зачем так держаться за единственную точку выхода из функции?
А в оракле так не делают?
> стрёмные ассоциации
Ну да, согласен, next там вообще не в тему.
> зачем так держаться за единственную точку выхода из функции?
Хм, return где угодно можно сделать, единственная точка выхода не требуется.
return next? нет, не видел
сделал return foobar; и всего делов
как и в любом другом языке, когда логика требует выхода из подпрограммы, а ты находишься в цикле
Ну и в слонике если написать return foobar, то он вернет этот foobar и процедура закончится.
> сделал return foobar; и всего делов
Но ведь это вернет одну строку. А если надо, чтобы процедура вернула курсор много строк?
ещё есть вариант вернуть коллекцию
а ещё есть pipelined functions вместо того, чтобы оперировать подрезультатами целиком
ещё можно включить голову и избавиться от pl/sql вообще - есть куча аналитических функций, всякие партишены и moving window - и наверняка будет быстрее, чем переключать контекст из sql в pl/sql
очень ценная вещь, а приходится реализовывать через жопу, в 2014-то году
в оракле - приходится инициализировать и юзать переменные, объявленные в пакете
В постгресе можно накостылить той фигней, которую я показывал выше, через return next в foreach ну или через return query...
Правда хер бы знал, как это скажется на производительности...
фактически, получалось гораздо медленнее, чем джойнить невъебенные таблицы с индексами
оптимизатор свое дело знает
pipelined, видать, нужно только действительно, когда надо строить длинный параллелизуемый конвейер из таких функций
Примерно вот такое:Оно, конечно, вполне решается через select-from-select, или select-from-херня-описанная-в-with, но читается ужасно ;(
и раз ты выносишь в результат то же самое (или, возможно, почти то же самое), что происходит в подзапросе, я бы тупо джойнил, делал очевидные where и так получал всё, что нужно, написав длинный непонятный подзапрос единожды
Само собой.
> я бы тупо джойнил
А это вариант... спасибо... я над этим подумаю. В having'е условия будут хоть и копипастные, но простенькие и понятные...
Правда если этот some long shit содержит case, то жопа остается ;(
Потом с леденящим ужасом будешь вспоминать дни, когда ты программировал на системных языках.
> x,
> (select some long shit from foo where some cond) as y,
> (select another long shit from foo where some cond) as z
>from
> bar
Фу-фу-фу так делать. Дефекейстра дело говорит с джоинами.
Ну тогда остается только тащить всю мало-мальски нетривиальную логику в приложение ;(
Дык, так и надо. Пусть база данных останется тихим и уютным хранилищем.
>DBdev
какой-то ленивый разработчик БД
Не ленивый, а open-minded.
Слишком много я повидал говна, которое пытались запихнуть на сторону БД.
Вы даже не представляете с каким огромным удовольствием я реализовываю логику на application level, вместо запихивания всего этого в БД.
Разве это похоже на пчёлы против мёда?