Здравствуйте, Serginio1, Вы писали:
E>>>>Правда конкретно у портных вертеть фигуры НЕЛЬЗЯ. E>>Потому, что портные шьют из ткани, а её механические свойства анизотропны... (Свойства в направлении утка и основы сильно отличаются)... S>А что с кожей http://lemarse.spb.ru/products/cut_leather/ которую я уже упоминал?
Обычно с кожей работают таки скорняки, а не портные. И с кожеё тоже часто вертеть нельзя, кстати. Бывает кожа с заметным рисунком или мех...
S> Да вся эта ветка оофтоп. Когда люди наследуют прямоугольник от квадрата и говорят, что это ООП
Скорее всего можно придумать задачу, где это будет в тему, но мне ничего в голову не приходит.
В любом случае я разделяю мнение, что конкретно в геометрических задачах ООП для представления данных обычно не нужно, так же, как и в вычматах, например...
Просто специфика области. Всё удобно представлять векторами чего-то...
S>Но при этом когда очевидно что любая частная фигура это наследник более общего понятия Фигура, здесь начинается флейм, а зачем и для чего.
IMHO, очевидно, что это не так.
В целом, если "фигура вообще", это таки массив сегментов (дуг там, отрезков или ещё чего), то она самодостаточна и никакие наследники ей, так же как и друнгим массивам, не нужны.
Просто тот, треугольник, например, который ты тулишь этой фигуре в наследники, будет содержать на борту три доп. длины стороны, в целом избыточные, и ещё, может быть, угол поворота вокруг первой вершину, тоже избыточный. Это не наследник, а просто альтернативное представление
Ты же не считаешь, что комплексное число в нормальной форме является предком комплексного числа в экспонециальной?
S>Доводы, того что для эффективной работы с фигурами тебе нужно знать особенности фигур просто отметаются. Ничего продуктивного в разговоре нет.
Так у тебя просят примеры.
Ты привёл три примера.
1) Подсчёт периметра -- выигрыша от ООП нет вообще ниакого, только усложение.
2) Подсчёт площади -- от ООП проигрыш
3) Ограничение гипотез по размещению детали при раскрое -- ООП для задания списка дипазонов допустимых углов поворота нужно, то есть тоже усложнение без всякой пользы.
В целом это хорошо, но ещё лучше бы было привести примеры, которые демонстрируют твою правоту, а не правоту твоих оппонентов
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, DarkGray, Вы писали:
S>>И наследование реализации — один из худших видов наследования.
DG>Чем по-твоему наследование реализации отличается от композиции? если, конечно, отвлечься от слов и смотреть на суть.
Тем, конечно, что композиция 1) не вводит отношения is-a, и 2) композиция работает на уровне объектов, а не классов. Побочным эффектом является возможность, в отличие от наследования, гибко выбирать тип компонуемого объекта.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Serginio1, Вы писали:
S>> Ну если ты отбрасываешь наследование реализации, и наследуешь прямоугольник от квадрата, значит что то неправильно в этом термине.
E>Я вообще считаю, что в этой задачи предлагаемая тобой иерархия не нужна...
Да ради Стандартной Модели. От этого прямоугольник не перестал быть фигурой. До ООП, народ прекрасно обходился без классов.
Скорее всего я неправильно выбрал или неправильно выстроил доказательство. Я веду речь о том, что наследование атрибутов и реализации это такое же ООП.
и солнце б утром не вставало, когда бы не было меня
S> Интересно а как ты квадрат то наследовать будешь? Это вырожденный прямоугольник у которого все стороны равны. Единственное его преймущество, что нужно знать всего одну сторону.
Эк вы упрощаете. А как же ромб, ведь квадрат вырожденный ромб, а прямоугольник — частный случай параллелограмма, да и ромб кстати тоже. При этом все это выпуклые четырехугольники, что есть подмножество четырехугольников.
А то зациклились, понимаешь, прямоугольник-квадрат. Шире надо смотреть, шире.
Здравствуйте, Serginio1, Вы писали:
S> Когда мы говорим о фигурах нам интересны внешние точки и их пересечение. Нас не интересуют точки внутри окружности, квадрата.
Вы уж определитесь, о чём вы хотите говорить — о фигурах вообще или о задачах раскроя.
Потому что если о фигурах вообще — то это в сад, я уже десять раз тут написал, что без требований, продиктованных конкретной задачей, дизайнить решение бессмысленно.
А если таки о раскрое, то по очевидным соображениям нас "точки внутри окружности" вполне себе интересуют.
Например, вот вам корректное решение по расположению в квадрате двух окружностей без пересечений:
То, что оно не является решением задачи раскроя, вам понятно?
Ну и так, для справки: математики, услышав словосочетание "площадь окружности", громко смеются. Так что если не желаете вызвать непреднамеренное веселье, постарайтесь применять термины по назначению.
S> Алгоритм перемещения фигур по вертикали горизонтали будет один и тот же, а вот повороты будут использовть особенности фигур. S>Логично присоединять стороны к сторонам а не стороны к углам?
Не вижу ничего логичного. Приведите пример кода, о котором вы говорите. Пока что ваши тексты выглядят бредом.
S> Это твое мнение. Оно мне понятно. Наследование прямоугольника из квадрата для меня непонятно. А вот наследование прямоугольника от фигуры с определением частных случаев для меня понятны.
А вот мне как раз непонятно вот это "наследование от фигуры". Потому что вы берётесь дизайнить схему наследования, не утруждая себя даже тенью мысли про контракты. Я вам уже приводил примеры, в которых и от фигуры прямоугольник отнаследовать невозможно. S>Прямоугольник это S>
S>фигура
S> состоящая из массива четырех точек так, что противоположные стороны параллельны и образуют прямой угол с прилежайшей стороной.
Отлично. Вы только что дали способ проверить, является ли произвольная фигура прямоугольником.
Почему бы на этом не остановиться? Вам очень хочется ввести наследника для того, чтобы зафиксировать этот признак?
Ну вот вам сценарий, в котором это даже вредно. Пусть у нас в "контракте фигуры" будет метод
Shape Intersect(OtherShape)
Если мы оставим "прямоугольность" там, где она должна быть, т.е. в виде extension метода bool IsRect(this Shape), то любая программа корректно опознает прямоугольник в результате вызова метода Intersect на вот такой паре фигур:
S>И использовать данные этой фигуры в своих алгоритмах, например чтобы опустить конверт в почтовый ящик проще повернуть конверт с наименьшей стороной к щели ящика. ) S>А эта сторона будет всего одна. Для других фигур для этого может потребоваться больше усилий.
Зачем вы всё делаете наоборот? Если стоит задача опускать в почтовый ящик конверты произвольной формы, то вам придётся один раз сесть и написать алгоритм нахождения наименьшего диаметра.
Но как только вы его напишете, вам будет не нужен алгоритм поиска наименьшего диаметра для прямоугольника. Так что "больше усилий" потребуется как раз для "использования данных прямоугольника в своих алгоритмах". Вам же Егор уже дважды подробно написал ровно эту мысль. Объясните, что именно мешает вам эту мысль понять?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Serginio1, Вы писали: S>А называй это как хочешь. ООП это не только полиморфизм, но и наследование реализации. Ты сын своего отца и матери. Полиморфизму (мутации) подверглись набор генов, но по сути ты являешься агрегатом части генов своих родителей и это реальное наследование. Как ты это будешь приспосабливать в программировании это твои проблемы. Но от этого понятие наследования не изменилось.
Чушь какая. Я вам рекомендую немедленно прекратить употреблять то, что вы употребляете, и начать после курса детоксикации читать какие-нибудь буквари. Потому что суть биологического наследования и суть наследования в ООП — принципиально разные.
То, что в них используются похожие слова, может ввести в заблуждение только ребёнка. Наследование — это всегда отношение is-a, проиллюстриованное принципом подстановки Лисков. Я не являюсь ни одним из своих родителей в этом смысле, поэтому утверждения типа "ты являешься агрегатом части генов своих родителей" с точки зрения программирования — бред. Кстати, с точки зрения биологии это тоже бред (потому, что живые организмы не состоят из генов).
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>> Да вся эта ветка оофтоп. Когда люди наследуют прямоугольник от квадрата и говорят, что это ООП E>Скорее всего можно придумать задачу, где это будет в тему, но мне ничего в голову не приходит. E>В любом случае я разделяю мнение, что конкретно в геометрических задачах ООП для представления данных обычно не нужно, так же, как и в вычматах, например... E>Просто специфика области. Всё удобно представлять векторами чего-то...
Да нет, когда ты работаешь с прямоугольниками ты будешь учитывать их особенности. Так если ты посмотришь ссылку, то пряоугольники там располагаются парралельно сторонам. И зная характер фигуры можно использовать её особенности нежели применять общий алгоритм.
S>>Но при этом когда очевидно что любая частная фигура это наследник более общего понятия Фигура, здесь начинается флейм, а зачем и для чего. E>IMHO, очевидно, что это не так. E>В целом, если "фигура вообще", это таки массив сегментов (дуг там, отрезков или ещё чего), то она самодостаточна и никакие наследники ей, так же как и друнгим массивам, не нужны.
E>Просто тот, треугольник, например, который ты тулишь этой фигуре в наследники, будет содержать на борту три доп. длины стороны, в целом избыточные, и ещё, может быть, угол поворота вокруг первой вершину, тоже избыточный. Это не наследник, а просто альтернативное представление
E>Ты же не считаешь, что комплексное число в нормальной форме является предком комплексного числа в экспонециальной?
Я считаю, что вещественное число является наследником комплексного. И в обычной практике мы пользуемся вещественными числами потому, что это проще.
S>>Доводы, того что для эффективной работы с фигурами тебе нужно знать особенности фигур просто отметаются. Ничего продуктивного в разговоре нет. E>Так у тебя просят примеры. E>Ты привёл три примера. E>1) Подсчёт периметра -- выигрыша от ООП нет вообще ниакого, только усложение.
Особенно для окружности. E>2) Подсчёт площади -- от ООП проигрыш
Особенно для окружности . Но с точки зрения, что её можно вычислить в конструкторе можно применить любой самый для этого подходящий алгоритм.
E>3) Ограничение гипотез по размещению детали при раскрое -- ООП для задания списка дипазонов допустимых углов поворота нужно, то есть тоже усложнение без всякой пользы.
Ну да проще крутить на все углы. При этом учитывая что это NP полная задача и нужно оптимизировать задачу, а её проще решить именно зная характер фигуры.
и солнце б утром не вставало, когда бы не было меня
S>Тем, конечно, что композиция 1) не вводит отношения is-a, и 2) композиция работает на уровне объектов, а не классов. Побочным эффектом является возможность, в отличие от наследования, гибко выбирать тип компонуемого объекта.
Смешиваешь наследование интерфейса с наследованием реализации (может, конечно, это связано с тем, что в мейнстриме первое неотделимо от второго). Первое вводит отношение is-a, а наследование реализации никоим образом не вводит отношение is-a.
Наследование реализации вводит отношение "поведение подобно, но..". Наследование реализации квадрата от прямоугольника вводит отношение: поведение квадрата подобно поведению прямоугольника, но при условии, что стороны всегда равны.
Обратное наследование реализации прямоугольника от квадрата вводит отношение: поведение квадрата подобно, как у прямоугольника, но кроме поведения, которого следовало из равенства всех сторон.
При утверждении: A наследует реализацию от B (поведение A подобно поведению B, но за исключеним C) и представлении поведения в виде ориентированных графов отношение "поведение подобно, но" утверждает, что графы поведения A и B совпадают за исключением дуг, которые порождены условиями C.
Здравствуйте, Serginio1, Вы писали:
S> Да ради Стандартной Модели. От этого прямоугольник не перестал быть фигурой. До ООП, народ прекрасно обходился без классов.
Угу. И вот эта программа в стиле "без классов" будет лушче того ООП-шного варианта, который ты предлагаешь...
IMHO, у тебя вообще какая-то проблема с теМ, что перепутаны статика и динамика. ООП оно обычно на уровне типов, а не на уровне объектов работает жеж...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
S>То, что в них используются похожие слова, может ввести в заблуждение только ребёнка. Наследование — это всегда отношение is-a, проиллюстриованное принципом подстановки Лисков.
И это лишь исторически сложилось, что при нестрогом разговоре (даже в тексте википедии) явление subtyping подменяется явлением наследования.
Proof из той же вики:
In programming languages that do not support inheritance as a subtyping mechanism, the relationship between a base class and a derived class is only a relationship between implementations (a mechanism for code reuse), as compared to a relationship between types.
E> ООП оно обычно на уровне типов, а не на уровне объектов работает жеж...
ООП бывает разное
Прототипное программирование — стиль объектно-ориентированного программированиях, при котором отсутствует понятие класса, а повторное использование (наследование) производится путём клонирования существующего экземпляра объекта — прототипа.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>> Когда мы говорим о фигурах нам интересны внешние точки и их пересечение. Нас не интересуют точки внутри окружности, квадрата. S>Вы уж определитесь, о чём вы хотите говорить — о фигурах вообще или о задачах раскроя. S>Потому что если о фигурах вообще — то это в сад, я уже десять раз тут написал, что без требований, продиктованных конкретной задачей, дизайнить решение бессмысленно. S>А если таки о раскрое, то по очевидным соображениям нас "точки внутри окружности" вполне себе интересуют. S>Например, вот вам корректное решение по расположению в квадрате двух окружностей без пересечений: S> S>То, что оно не является решением задачи раскроя, вам понятно?
Если листом является окружность то да, но это краевые задачи расположения фигуры на листе относительно рядом лежащих фигур.
Если мы располагаем лист на множестве фигур. Но опять же нас не интересуют точки внутри, нас интересуют только краевые точки , что бы они располагались внутри листа, то есть не было пересечения при соединении точек
S>Ну и так, для справки: математики, услышав словосочетание "площадь окружности", громко смеются. Так что если не желаете вызвать непреднамеренное веселье, постарайтесь применять термины по назначению.
Ну наверное это проще выговорить чем площадь материала очерченная окружностью.
S>> Алгоритм перемещения фигур по вертикали горизонтали будет один и тот же, а вот повороты будут использовть особенности фигур. S>>Логично присоединять стороны к сторонам а не стороны к углам? S>Не вижу ничего логичного. Приведите пример кода, о котором вы говорите. Пока что ваши тексты выглядят бредом.
Гипотнтически для фигуры можно определить метод расположения относительно крайних фигур с оптимизацией наименьшей свободной площади между ними.
Можно крутить вертеть, а можно зная характер характер текущей фигуры и рядом лежащих выбрать предпочтительное расположения, учитывая что у на NP полная задача.
S>> Это твое мнение. Оно мне понятно. Наследование прямоугольника из квадрата для меня непонятно. А вот наследование прямоугольника от фигуры с определением частных случаев для меня понятны. S>А вот мне как раз непонятно вот это "наследование от фигуры". Потому что вы берётесь дизайнить схему наследования, не утруждая себя даже тенью мысли про контракты. Я вам уже приводил примеры, в которых и от фигуры прямоугольник отнаследовать невозможно. S>>Прямоугольник это S>>
S>>фигура
S>> состоящая из массива четырех точек так, что противоположные стороны параллельны и образуют прямой угол с прилежайшей стороной. S>Отлично. Вы только что дали способ проверить, является ли произвольная фигура прямоугольником. S>Почему бы на этом не остановиться? Вам очень хочется ввести наследника для того, чтобы зафиксировать этот признак? S>Ну вот вам сценарий, в котором это даже вредно. Пусть у нас в "контракте фигуры" будет метод S>
S>Shape Intersect(OtherShape)
S>
S>Если мы оставим "прямоугольность" там, где она должна быть, т.е. в виде extension метода bool IsRect(this Shape), то любая программа корректно опознает прямоугольник в результате вызова метода Intersect на вот такой паре фигур: S>
S>>И использовать данные этой фигуры в своих алгоритмах, например чтобы опустить конверт в почтовый ящик проще повернуть конверт с наименьшей стороной к щели ящика. S>) S>>А эта сторона будет всего одна. Для других фигур для этого может потребоваться больше усилий. S>Зачем вы всё делаете наоборот? Если стоит задача опускать в почтовый ящик конверты произвольной формы, то вам придётся один раз сесть и написать алгоритм нахождения наименьшего диаметра. S>Но как только вы его напишете, вам будет не нужен алгоритм поиска наименьшего диаметра для прямоугольника. Так что "больше усилий" потребуется как раз для "использования данных прямоугольника в своих алгоритмах". Вам же Егор уже дважды подробно написал ровно эту мысль. Объясните, что именно мешает вам эту мысль понять?
Ну да вот зачем народ формулы площади круга, прямоугольников то придумывал. Конечно век компьютеризации, но вот беда то есть куча NP полных задач где нужно оптимизировать задачи.
Зачем ООП если можно в процедурном типе программировать. Да я могу использовать общий алгоритм, но в большинстве случаев он не оптимален по количеству затрачиваемого времени. Для каждой частной формы можно использовать свой алгоритм. Программирование это часть эволюции, а эволюция человечество это увеличение специализации и роста производительности труда.
Я даже отдельно для каждой частной фигуры напишу свой алгоритм прохождения, поворота для считывания индекса итд. А вот для не частных фигур я буду работать с базовым классом.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Serginio1, Вы писали:
S>> Да ради Стандартной Модели. От этого прямоугольник не перестал быть фигурой. До ООП, народ прекрасно обходился без классов. E>Угу. И вот эта программа в стиле "без классов" будет лушче того ООП-шного варианта, который ты предлагаешь...
E>IMHO, у тебя вообще какая-то проблема с теМ, что перепутаны статика и динамика. ООП оно обычно на уровне типов, а не на уровне объектов работает жеж...
Почему, разве я не могу заложить алгоритм в фигуру для оптимального её расположения относительно рядом лежащих фигур?
и солнце б утром не вставало, когда бы не было меня
Кстати хотел задать вопрос по блокировкам. Не совсем понял
у тебя
Такая блокировка совместима с коллективной, что позволит читающим транзакциям обращаться к этим данным беспрепятственно. А когда понадобится их обновить, то проблем быть не должно, так как блокировки обновления между собой несовместимы, и значит, другие транзакции, читающие эти данные для последующего изменения (и естественно тоже запросившие их с блокировкой обновления), будут ждать, пока эти данные поменяются, никому не мешая. Для этого необходимо изменить первый оператор транзакции примерно таким образом:
SELECT @Var = Y FROM Tbl WITH (UPDLOCK) WHERE X = 2
1. Блокировки типа Update нужны для обозначения такого факта: те, кто уже имеет Shared locks на этот же ресурс могут продолжать ими пользоваться, но любые новые блокировки запрещены. Как только shared locks уходят с ресурса блокировка типа U конвертируется в eXclusive, чтобы обозначить соответственно названию, что никакими другими сессиями этот ресурс не заблокирован вообще. Держать блокировку до конца транзакции или нет — это совсем другой вопрос, решаемый REPEATABLE READ или HOLDLOCK.
Короче, смысл блокировок U — не блокировать данные _читаемые_ при выборке под UPDATE, а обозначать факт того, что мы намереваемся менять данные сразу после того как уйдут те, кто их сейчас читает.
То есть смысл второго, что UPDLOCK совместима с уже читающими и перед записью ждет окончания всех транзакций на чтение. Блокировки на чтение после начала Update, курят в сторонке.
Что с моей точки зрения логичней, т.к. можно обеспечить Repeatable read и при этом повысить параллельность. Хотя может у тебя это же и подразумевается а я не умею читать
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Почему, разве я не могу заложить алгоритм в фигуру для оптимального её расположения относительно рядом лежащих фигур?
Тогда надо уже мультиметоды мутить, так как алгоритм размещения одной фигуры у другой зависит от типа обеих...
Может таки лучше иметь массив сторон описанной фигуры и перебирать способы поставить сторону одного описывающего на сторону другого описывающего?..
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, DarkGray, Вы писали:
DG>Смешиваешь наследование интерфейса с наследованием реализации (может, конечно, это связано с тем, что в мейнстриме первое неотделимо от второго). Первое вводит отношение is-a, а наследование реализации никоим образом не вводит отношение is-a.
Курить LSP до просветления.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Serginio1, Вы писали:
S> Если листом является окружность то да, но это краевые задачи расположения фигуры на листе относительно рядом лежащих фигур.
Вы опять ничего не поняли. Перечитайте текст до понимания. Листом не является окружность, листом является квадрат. Он тоже приведён на рисунке. S>Если мы располагаем лист на множестве фигур.
То мы наоборот делаем всё, ведь задача — расположить фигуры на листе.
S>Ну наверное это проще выговорить чем площадь материала очерченная окружностью.
Проще вообще не говорить. А правильнее говорить "площадь круга".
S> Гипотнтически для фигуры можно определить метод расположения относительно крайних фигур с оптимизацией наименьшей свободной площади между ними.
Код в студию.
S>Можно крутить вертеть, а можно зная характер характер текущей фигуры и рядом лежащих выбрать предпочтительное расположения, учитывая что у на NP полная задача.
Я вам больше отвечать, пожалуй, не буду. Мои аргументы вы не читаете, на вопросы не отвечаете, думать не хотите.
S> Ну да вот зачем народ формулы площади круга, прямоугольников то придумывал.
Народ придумывал формулы не для задачи раскроя, а для ручного решения конкретных задач.
S>Конечно век компьютеризации, но вот беда то есть куча NP полных задач где нужно оптимизировать задачи.
Я вас разочарую: оптимизация NP-complete задач при помощи уменьшения множителя при O — это как чайной ложкой океан вычерпывать. И об этом вам тоже уже сказали минимум дважды. Это при том предположении, что ваша идея оптимизации через полиморфизм вообще имеет смысл: без профайлера заранее сказать, как повлияет вычисление площади на время работы программы, я лично бы не взялся.
А вы уже готовы педалить код — то есть растратить деньги инвестора на код, который себя скорее всего не оправдает.
S>Зачем ООП если можно в процедурном типе программировать.
Хороший вопрос. ООП — затем, чтобы уменьшить coupling и увеличить cohesion. Чтобы написать меньший объём кода, и чтобы внесение изменений обходилось дёшево. А по-вашему, зачем? Чтобы "моделировать реальный мир" что ли?
S>Да я могу использовать общий алгоритм, но в большинстве случаев он не оптимален по количеству затрачиваемого времени. Для каждой частной формы можно использовать свой алгоритм. Программирование это часть эволюции, а эволюция человечество это увеличение специализации и роста производительности труда.
Ещё одна аналогия, не относящаяся к программированию.
S> Я даже отдельно для каждой частной фигуры напишу свой алгоритм прохождения, поворота для считывания индекса итд. А вот для не частных фигур я буду работать с базовым классом.
Вы всё ещё не можете даже на пальцах написать суть алгоритма, о котором идёт речь. А уже делаете выводы о его производительности. Крайне непрофессионально.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>1. Блокировки типа Update нужны для обозначения такого факта: те, кто уже имеет Shared locks на этот же ресурс могут продолжать ими пользоваться, но любые новые блокировки запрещены. Как только shared locks уходят с ресурса блокировка типа U конвертируется в eXclusive, чтобы обозначить соответственно названию, что никакими другими сессиями этот ресурс не заблокирован вообще. Держать блокировку до конца транзакции или нет — это совсем другой вопрос, решаемый REPEATABLE READ или HOLDLOCK.
S>Короче, смысл блокировок U — не блокировать данные _читаемые_ при выборке под UPDATE, а обозначать факт того, что мы намереваемся менять данные сразу после того как уйдут те, кто их сейчас читает.
S> То есть смысл второго, что UPDLOCK совместима с уже читающими и перед записью ждет окончания всех транзакций на чтение. Блокировки на чтение после начала Update, курят в сторонке. S>Что с моей точки зрения логичней, т.к. можно обеспечить Repeatable read и при этом повысить параллельность. Хотя может у тебя это же и подразумевается а я не умею читать
В таких случаях надо обращаться к первоисточникам. Например, http://msdn.microsoft.com/en-us/library/ms186396(v=sql.105).aspx
Existing Granted Mode: U, Requested Mode: S: Yes.
То есть на этот раз угадал я, а не sql.ru.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Serginio1, Вы писали:
S>> Почему, разве я не могу заложить алгоритм в фигуру для оптимального её расположения относительно рядом лежащих фигур?
E>Тогда надо уже мультиметоды мутить, так как алгоритм размещения одной фигуры у другой зависит от типа обеих... E>Может таки лучше иметь массив сторон описанной фигуры и перебирать способы поставить сторону одного описывающего на сторону другого описывающего?..
Здесь как раз может иметь место 2 алгоритма один заложенный в фигуру, другой общий. При этом общий может быть и у любой произвольной фигуры. Это как аналог построения ДКА.
В одном случае можно сделать ветвление в другом создать семейство классов отвечающие за свое состояние и передачу выполнения следующему экземпляру класса отвечающее за свое состояние.
Конечно можно обойтись и интерфейсами но это будет семейство классов поддерживающий интерфейс.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>>
S>>1. Блокировки типа Update нужны для обозначения такого факта: те, кто уже имеет Shared locks на этот же ресурс могут продолжать ими пользоваться, но любые новые блокировки запрещены. Как только shared locks уходят с ресурса блокировка типа U конвертируется в eXclusive, чтобы обозначить соответственно названию, что никакими другими сессиями этот ресурс не заблокирован вообще. Держать блокировку до конца транзакции или нет — это совсем другой вопрос, решаемый REPEATABLE READ или HOLDLOCK.
S>>Короче, смысл блокировок U — не блокировать данные _читаемые_ при выборке под UPDATE, а обозначать факт того, что мы намереваемся менять данные сразу после того как уйдут те, кто их сейчас читает.
S>> То есть смысл второго, что UPDLOCK совместима с уже читающими и перед записью ждет окончания всех транзакций на чтение. Блокировки на чтение после начала Update, курят в сторонке. S>>Что с моей точки зрения логичней, т.к. можно обеспечить Repeatable read и при этом повысить параллельность. Хотя может у тебя это же и подразумевается а я не умею читать S>В таких случаях надо обращаться к первоисточникам. Например, http://msdn.microsoft.com/en-us/library/ms186396(v=sql.105).aspx S>Existing Granted Mode: U, Requested Mode: S: Yes. S>То есть на этот раз угадал я, а не sql.ru.
Плохо у меня с английским. Просто для меня UPDLOCK вызывает противоречивые чувства. Если бы я делал блокировку то сделал бы по второму способу. Объясню почему
Например у меня есть намерение блокировать на запись и чтение на одинаковых строках но в разном направлении, что неминуемо приведет к дид луку. Но если я применю 2 вариант,
то новые транзакции будут заблокированы старые прочитают беспрепятственно уже заблокировнные записи и перед записью останется только подождать окончание читающих транзакций.
Метод когда UPDLOCK не приводит к блокировке новых транзакций не решает проблемы с одновременной экслюзивной и читающей блокировк строк в обратном порядке.
и солнце б утром не вставало, когда бы не было меня
