Здравствуйте, eao197, Вы писали:
E>Пока из ваших объяснений я так и не понял, чтоже именно произойдет с объектами A и B. Такое впечатление, что они либо остануться жить вечно, либо их финализаторы гарантированно вызовутся раньше очистки памяти.
Вызов финализатора не гарантирован.
Тут просто надо понимать, что есть финализация. Финализация — это просто некий сервис, который вызывается для объекта после того как GC решит, что объект является претендентом на вылет, и (обязательное условие!) объект был предварительно подписан на этот сервис. В самом коде финализатора объект может принять решение о том, что он еще жив, например, сохранить ссылку на себя в глобальной переменной или в некоем живом объекте. Так вот, в следующий раз, когда этот объект попадёт в лапы сборщика мусора, финализатор для данного объекта уже вызван не будет, если до этого события кто-нить не вызовет для объекта GC.ReRegisterForFinalize(obj);
В принципе, возможна такая ситуция, что на объект уже нигде нет ссылок, а он в своём коде финализатора вновь и вновь самоподписывается на финализацию. На основе этого фокуса можно написать простенький сборщик статистики, как часто происходит GC.
Что касается освобождения памяти, занимаемой объектами. На объект не должны ссылаться ни обычные объекты, ни находящиеся в очереди финализации, таким образом гарантируется, что освобождаемая область памяти более программно недоступна. Вся схема работает вполне надёжно, т.к. нет конкурирующих процессов сборки мусора или конкурирующих тредов финализации.
Здравствуйте, MxKazan, Вы писали:
S>>>Я всё еще не вижу причин, по которой ты считаешь identity tracking заметно лучше, чем прямое отображение insert/update/delete в SQL.
L>>я так не считаю, я считаю что DataContext (c identity tracking) лучше чем DataContext(Sinclair edition) (c identity tracking и delete-ами через expression в обном флаконе). L>>Так надеюсь понятнее?
MK>Lloyd, по-моему, Sinclair имеет ввиду, что ему не нужно identity tracking, если оно мешает выполнять типовые запросы БД. Получилась концепция частично ради самой себя — пользоваться можно, но то здесь, то там приходиться извращаться для решения типовых задач.
Но то, что ему не нужно identity tracking — еще не повод пихать в DataContext чуждый ему (DataContext-у) метод работы с данными.
Здравствуйте, VoidEx, Вы писали:
VE>Оружие Джедаев — это такая светящаяся палка, которая на раз сносится мейнстримовой ядерной бомбой вместе с самими Джедаями?
Ядерная бомба к мейнстриму отношения не имеет. В мейнстриме есть только одно оружие массового поражения — технология Copy&Paste.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Ядерная бомба к мейнстриму отношения не имеет. В мейнстриме есть только одно оружие массового поражения — технология Copy&Paste.
Фи, как пошло. В философском обществе так не выражаются! Тут говорят clipboard inheritance.
Здравствуйте, Mirrorer, Вы писали:
M>Ну а как иначе. Большинство идей, которые попадают в языки, были описаны в академических исследованиях 19.. лохматого года. А потом по чуть-чуть из башен слоновой кости идеи перетекают в индустрию в пережеванном и удобном для употребления виде.
Надо только заметить, что далеко не все и далеко не всегда в изначальном виде.
, заявление про выигрышь в читабельности как-то гораздо сомнительнее выглядит. Когда поглядишь во что оно разворачивается, пищеварение совсем нарушается
У проблемы читабельности есть два аспекта.
1. Чтобы легко читать что-то нужно хорошо знать язык на котором это что-то написано. Скажем, я с трудом читаю на английском и совсем плохо на французском, хотя отдельные французские фразы и понимаю. Точно так же не зная ООП и конкретных особенностей его синтаксиса в конкретном языке можно смотреть на совершенно простой и очевидный код как на ребус.
2. Сложность решаемой задачи и ее абстрагированность. Такова уж природа вещей — сложные и высоко-асбтрактные задачи решать сложнее чем "бытовые" (т.е. конкретные и простые). Когда ты разбирашь "этюд", то ты сталкиваешься в первую очередь не с примером фунциональной записи, а с примером высоко-абстрактной задачи которая сложна для понимания. Если ее решение попытаться записать в императивном виде, то скорее всего мы получим кучу кода который в целом будет совсем не понятен. Учитывая же пункт 1 функциональная запись создает для тебя некий ореол таинственности и даже враждебности.
VD>>Для того чтобы воспользоваться преимуществами неизвестной тебе парадигмы нужно сделать немалое напряжение, чтобы понять ее. Проблема в том, что для этого обычно нужно менять мировозрение. Простые, казалось бы, концепции просто не втискиваются в рамки императивного мышления. MK>Вопрос то не в этом. Пока что большинство аргументов "за" выглядят примерно так: "появилась новая фича, значит она точно необходима и ей нужно пользоваться".
Вопрос именно в этом! "Новой фиче" уже исполнилось 50 лет. То что она попала в C# в 2008-ом году не значит, что фичи до этого не было. Просто раньше она вообще была доступна только очень не многим кто захотел и осилил изучение функционального языка.
MK>Не опровергая её необходимости, просто хотелось бы увидеть реальные примеры, в которых четко обозначено "было так, не нравилось потому то", "сделал по новому и это решило то-то".
и (возможно) цикл статей по Немерле (здесь). Уверен, что если приложить небольшое усилие, то не только увидишь примеры, но и осознаешь саму суть, а это намного интереснее.
VD>>Откровенно говоря тем хуже для тебя. 3 года — это совсем малый срок для нашей профессии, а ты уже становишься ретроградом и отказываешься воспринимать новые (для тебя) знания.
MK>Это, мягко говоря, неверная оценка — я лишь отношусь с подозрением и слушаю более опытных коллег, с которыми работаю. MK>И между прочим нигде
Здравствуйте, Lloyd, Вы писали:
L>>>Только не надо про nemerle
VD>>Причем тут Немерле? Ты давно в отпуске то был?
L>Переходить на личности тоже не надо. L>P.S. В отпуске был в июле.
Что значит "тоже"?
У тебя уже мания преследования.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mirrorer, Вы писали:
M>Ухх. А Немерле значится позволяет автоматизировать Copy&Paste. M>Ну сколько бедный индус может закопипастить за час... А так напишешь M>
M>for x in [1..100000000]
M>CoolMacro()
M>
Бедный индус ошибся. Его код вызвал 100 000 000 раз код всего лишь однажды сгенерированный макросом CoolMacro(). Правильная версия будет выглядеть примерно так:
Здравствуйте, VladD2, Вы писали:
L>>Переходить на личности тоже не надо. L>>P.S. В отпуске был в июле.
VD>Что значит "тоже"?
VD>У тебя уже мания преследования.
Здравствуйте, Mirrorer, Вы писали:
M>Ну например. Возьмем простой пример. Просуммировать список чисел M>
M>var sum = 0;
M>foreach var x in someList
M> sum += x
M>
M>Допустим нам понадобилось сделать умножение. M>И что видно ? Видно дублирование кода. Отличие только в начальном значении суммы и функции, которая будет применяться на каждом шаге.
M>
M> var sum2 = Accumulate<int, int>(0, (s, x) => s + x);
M>
M>Мы теперь можно чувствовать себя крутым. Мы абсрагировали способ обхода коллекции (foreach) от операций которые будут выполняться на каждом шаге. M>Уберутся ненужные дублирования и т.п.
А в чем заключается убирание дублирования? При императивном подходе мы дважды писали foreach, при функциональном дважды пишем Accumulate. В чем выигрыш?
При этом выучив foreach один раз его можно использовать в миллионе случаев, а Accumulate покрывает куда меньшее количество случаев, соответственно для того, чтобы иметь возможность решить те же задачи, которые решаются с помощью foreach, нужно выучить не только Accumulate, но и еще 125 различных функций.
Из сказанного не следует, что я являюсь противником функционального подхода. Напротив, я считаю, что костяк приложения должны составлять статические функции, а объекты, как правило, быть лишь обертками над ними. Но как раз с точки зрения алгоритмики область применения функционального подхода достаточно узка (хотя и безусловно существует). Сложные алгоритмы записанные в императивном стиле, как правило, проще и в понимании и в отладке, т.к. при императивном подходе есть возможность опуститься на уровень одного элемента, т.е. части результата, а при функциональном подходе приходиться сразу мыслить на уровне коллекций, т.е. результата в целом.
По-своему опыту скажу, что в случае простых преобразований вместо трех строчек с foreach'ем я охотно использую статистическую функцию в тех случаях, когда этой функции не нужно принимать делегат, например: _.Combine<T>(params IEnumerable<T>[] collections). Если функция использует делегат, то чуть большая лаконичность написания, на мой взгляд, не окупает необходимости вспоминать специальную функцию.
Функции же с делегатами я охотно использую только в случае достаточно сложных, но стандартных преобразований, например:
Вот в решении подобных стандартных задач функциональному подходу самое место.
ps
Т.е. ни в коем случае нельзя противопоставлять императивный и функциональный подход, подавая функциональщину как серебрянную пулю, которая в скором времени вытеснит императивщину. Главное достоинство C# заключается в том, что он позволяет использовать и тот, и другой подход, выбирая более подходящий для конкретной задачи.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Lloyd, Вы писали:
L>>Каскадные удаления не являются частью SQL-я. GZ>Являются частью стандарта. Но вопрос в следующем. Когда мы выполняем delete * from students s where (select min(mark) from exam where exam.studentID = s.id) < 3 мы попадаем в классические грабли ORM. Мы положили на валидацию. Мы не можем сказать какой объект student был уже удален. И мы не можем сказать ваще какие объекты удалены и насколько у нас актуальные данные в памяти поскольку есть триггеры и каскадные удаления. По факту классическая рассинхронизация оперативной памяти и состояния на БД. Подобный запрос только увеличит глубину падения в наших глубинах.
Мы на эти грабли можем наступить еще в тысяче и одном случае, но общее у этих случаев только одно — это независимое изменение источника данных. Оно в любом случае приведет к рассогласованию контекста сессии и источника данных, на что вы, собственно, и указали. И не обязательно выполнять сложные запросы, можно просто работать с базой в соседнем соединении. Вообще, стоит рассматривать объекты в сессии как рассинхронизированные по умолчанию. Поэтому-то линк и выполняет селект перед обновлением источника. Но это можно разрулить, например, версиями записей. В принципе, такая проблема не возникает, если работать с короткими сессиями. Что, впрочем, ЛИНК и предполагает.
То потухнет, то погаснет
Если нам не помогут, то мы тоже никого не пощадим.
