DG>>и опять религиозное мнение без каких-либо выводов из определения. S>Ты игнорируешь мои выводы. Зачем мне утруждаться?
мне лишь не нравится, что ты (не говоря уже про Sinclair-а, который кроме букварей вообще больше ничего не читал) часто используешь закон отрицания третьего, который не работает в конструкционной логике.
а программирование работает в конструкционной логике: потому что интересует возможность реального построения программы из имеющихся ресурсов, а не возможность теоретического существования.
S>>>> Как быть с полиморфизмом?
DG>>>полиморфизм как был так и остается. и примере с null как раз применение полиморфизма и показывает. S>>identity является основой для работы полиморфизма. DG>>>или ты на самом деле не знаешь что такое полиморфизм? S>>Твой пример с null показывает что ты не знаешь что такое полиморфизм.
DG>одно из классических определений полиморфизма: DG>возможность работать одинаковым образом с разнородными объектами.
Это не лучшее определение лишь одной из частей полиморфизма.
DG>при этом реализация полиморфизма через vtable, это частный случай реализации полиморфизма.
Не реализации, а вообще, частный случай полиморфизма. Конкретно — subtype полиморфизма. Который есть подвид ad-hoc полиморфизма с разрешением конкретного поведения во время выполнения по первому аргументу. DG>например, в следующем коде полиморфизм есть — функция Main обрабатывает вывод разнородных объектов (строка, целое число, дробное число) одинаковым образом, но реализация полиморфизма сделана без vtable-а DG>
DG>void Main()
DG>{
DG> foreach (var x in new object[]{"Hello", "world", 37, 21.1})
DG>
Это параметрический полиморфизм
DG>для строго наличия наличия полиморфизма или отсутствия полиморфизма — необходимо сначала зафиксировать для какого кода по отношению к какому набору объектов делается утверждение. DG>следующий код полиморфен для всех объектов, которые реализуют IDisposable, и не полиморфен для набора объектов, которые реализуют IDisposable и не реализуют DG>
DG>var disposable = x as IDisposable;
DG>if (x != null)
DG> disposable.Dispose();
DG>
DG>null и полиформизм DG>следующий код не полиморфен для набора объектов: null и не null, и при наличии такого кода и делается утверждение, что null разрушает полиморфизм DG>
DG>if (point != null)
DG> point.Inverse();
DG>
null не является объектом
DG>в следующем примере Main полиморфно обрабатывает набор объектов: null и не null. DG>и null наоборот полиморфизм добавляет, а не разрушает. DG>
DG>void Main()
DG>{
DG> foreach (var p in new Point[]{new Point(x:1, y:2), null, new Point()})
DG>}
DG>
Ты смешал в одну кучу параметрический и специальный полиморфизм. в Main null обрабатывается как за счет параметрического, а в Inverce за счет обработки специального случая, но без полиморфизма. Таким образом, null тут таки ломает.
DG>>>ты все грозишься что всё можно, а сам еще даже ни одного вывода не сделал, ни строчки кода не привел... S>>Я сделал достаточно выводов относительно твоих определений. И строчки тоже приводил, даже не одну. S>>Добавь в свой первый вариант Distinct() и каждый объект будет меняться лишь однажды.
DG>согласен будет. только при этом код станет O(n*logn) вместо O(n) и концепция Нулевые побочные затраты, если не используется, пойдут к черту, а так все замечательно.
Могу подсказать решение за O(n) DG>это я намекаю на то, что определения подбираются такие, чтобы код был хорошим, а не наоборот — подбирается код (в том числе ужасный) под раз зафиксированные определения.
В этом и проблема, что ты подбираешь определения для того что бы сделать конкретную функцию удовлетворяющей спецификацию, причем рассчитываешь на то что тот кто использует твой код и его определения не совпадают с твоими, будет писать некие адаптеры с ненулевыми побочными затратами.
Понимаешь, не Inverse для списка точек решает какой быть точкой. Решение об иммутабельности точки должно приниматься на более высоком уровне архитектуре, чем подгонка определений для того что бы впихнуть реализацию функции инвертирования списка точек в спецификацию. Функция инвертирования списка точек должна работать с теми точками, с которыми умеет работать вся остальная программа.
Код пишется для того, что бы удовлетворить требованиям, а не требования для того что бы удовлетворить коду. Обычно.
DG>>>и опять религиозное мнение без каких-либо выводов из определения. S>>Ты игнорируешь мои выводы. Зачем мне утруждаться?
DG>мне лишь не нравится, что ты (не говоря уже про Sinclair-а, который кроме букварей вообще больше ничего не читал) часто используешь закон отрицания третьего, который не работает в конструкционной логике. DG>а программирование работает в конструкционной логике: потому что интересует возможность реального построения программы из имеющихся ресурсов, а не возможность теоретического существования.
DG>http://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%82%D0%B8%D0%B2%D0%B8%D0%B7%D0%BC_(%D0%BC%D0%B0%D1%82%D0%B5%D0%BC%D0%B0%D1%82%D0%B8%D0%BA%D0%B0)
Я почитаю, но попозже.
А пока не было ни одной программы, которую бы я не смог построить из-за отрицания третьего. Кроме того, твои изыски с ООП кажутся мне совершенно необоснованными. Не испытываю никаких сложностей в том что бы использовать идентичность по ECMA при разработке и объяснении своих решений.
S>Понимаешь, не Inverse для списка точек решает какой быть точкой. Решение об иммутабельности точки должно приниматься на более высоком уровне архитектуре, чем подгонка определений для того что бы впихнуть реализацию функции инвертирования списка точек в спецификацию. Функция инвертирования списка точек должна работать с теми точками, с которыми умеет работать вся остальная программа.
библиотечный код пишется в отрыве от самой программы, при этом библиотечный код тем лучше, чем в большем кол-ве различных программ с различными подходами его можно использовать (как напрямую, так и через адаптирующий код).
из этого следует всякие частные требования: например, не использовать static-переменные; "нулевые затраты, если не используется" и т.д.
также известно, что библиотечный код построенный на immutable-объектах можно использовать шире и проще, чем построенный на mutable-объектах, но immutable-объекты более тяжелые для исполнения, чем mutable. при этом последнюю проблему можно ослабить, если используются те или иные техники суперкомпиляции.
S>Код пишется для того, что бы удовлетворить требованиям, а не требования для того что бы удовлетворить коду. Обычно.
это первый шаг.
второй шаг говорит, что требования появляются не ради требования(ради самих себя), а ради лучшего решения задачи
из этого следует третий шаг:
если требования можно сформулировать несколькими способами, то стоит выбрать такую формулировку требований для которой код пишется быстрее, проще, эффективнее и дешевле.
например:
считать null объектом или не считать — это типичное требование, верность которого относительна в зависимости от того при каком подходе получается более лучшее решение.
ты же считаешь что мнение "null — это не объект" — абсолютно(не зависит от контекста), или другими словами догматично, и тебя не интересует будет ли решение при этом лучше или хуже. Тебе лишь важно, чтобы догма "null не объект" сохранялась.
S>Это не лучшее определение лишь одной из частей полиморфизма.
на вики оно ровно такое же
In computer science, polymorphism is a programming language feature that allows values of different data types to be handled using a uniform interface.
особо отмечу, что здесь interface подразумевается в широком смысле, а не в смысле interface основанного на vtable.
DG>>при этом реализация полиморфизма через vtable, это частный случай реализации полиморфизма. S>Не реализации, а вообще, частный случай полиморфизма. Конкретно — subtype полиморфизма. Который есть подвид ad-hoc полиморфизма с разрешением конкретного поведения во время выполнения по первому аргументу.
в целом, вроде согласен.
смущает только середина. что здесь такое subtype? является ли, например, int субтипом double? вообще? и в конкретных языках программирования?
S>Ты смешал в одну кучу параметрический и специальный полиморфизм. в Main null обрабатывается как за счет параметрического, а в Inverce за счет обработки специального случая, но без полиморфизма. Таким образом, null тут таки ломает.
зачем ты лезешь в реализацию?
если бы был язык полностью похожий на C#, но там можно было бы указать для null отдельную vtable со своими реализациями каждой функции, то следующий код был бы полиморфным?
foreach (var p in new Point[]{new Point(), null})
p.Inverse();
DG>>согласен будет. только при этом код станет O(n*logn) вместо O(n) и концепция Нулевые побочные затраты, если не используется, пойдут к черту, а так все замечательно. S>Могу подсказать решение за O(n)
давай
DG>>это я намекаю на то, что определения подбираются такие, чтобы код был хорошим, а не наоборот — подбирается код (в том числе ужасный) под раз зафиксированные определения. S>В этом и проблема, что ты подбираешь определения для того что бы сделать конкретную функцию удовлетворяющей спецификацию, причем рассчитываешь на то что тот кто использует твой код и его определения не совпадают с твоими, будет писать некие адаптеры с ненулевыми побочными затратами.
затраты там почти всегда нулевые, особенно если код подвергается суперкомпиляции
Здравствуйте, DarkGray, Вы писали:
S>>Понимаешь, не Inverse для списка точек решает какой быть точкой. Решение об иммутабельности точки должно приниматься на более высоком уровне архитектуре, чем подгонка определений для того что бы впихнуть реализацию функции инвертирования списка точек в спецификацию. Функция инвертирования списка точек должна работать с теми точками, с которыми умеет работать вся остальная программа.
DG>библиотечный код пишется в отрыве от самой программы, при этом библиотечный код тем лучше, чем в большем кол-ве различных программ с различными подходами его можно использовать (как напрямую, так и через адаптирующий код). DG>из этого следует всякие частные требования: например, не использовать static-переменные; "нулевые затраты, если не используется" и т.д.
Это верно. И определяющим реализацию объекта будет не попытка подогнать реализацию функцию под спецификацию, а более общие соображения.
DG>также известно, что библиотечный код построенный на immutable-объектах можно использовать шире и проще, чем построенный на mutable-объектах, но immutable-объекты более тяжелые для исполнения, чем mutable. при этом последнюю проблему можно ослабить, если используются те или иные техники суперкомпиляции.
Мне это известно. Я широко использую immutable-объекты, но мне не нужно для их использования переопределять идентичность и понятие объекта.
S>>Код пишется для того, что бы удовлетворить требованиям, а не требования для того что бы удовлетворить коду. Обычно.
DG>это первый шаг. DG>второй шаг говорит, что требования появляются не ради требования(ради самих себя), а ради лучшего решения задачи DG>из этого следует третий шаг: DG>если требования можно сформулировать несколькими способами, то стоит выбрать такую формулировку требований для которой код пишется быстрее, проще, эффективнее и дешевле.
Стоит, но только если есть уверенность что заказчик понимает требования точно так же.
DG>например: DG>считать null объектом или не считать — это типичное требование, верность которого относительна в зависимости от того при каком подходе получается более лучшее решение.
Я не вижу как то, считать null объектом или нет, сказывается на решении.
DG>ты же считаешь что мнение "null — это не объект" — абсолютно(не зависит от контекста), или другими словами догматично, и тебя не интересует будет ли решение при этом лучше или хуже. Тебе лишь важно, чтобы догма "null не объект" сохранялась.
Прежде всего, я отличаю объект от ссылки на него. И это мне не мешает, а помогает.
S> Кроме того, твои изыски с ООП кажутся мне совершенно необоснованными. Не испытываю никаких сложностей в том что бы использовать идентичность по ECMA при разработке и объяснении своих решений.
результативность не является достаточным критерием для обоснования хорошести решений. как минимум еще выделяют эффективность, экономичность, экологичность. на следующий уровнях еще больше плоскостей выделяется.
Здравствуйте, DarkGray, Вы писали:
S>>Это не лучшее определение лишь одной из частей полиморфизма.
DG>на вики оно ровно такое же DG>
DG>In computer science, polymorphism is a programming language feature that allows values of different data types to be handled using a uniform interface.
DG>особо отмечу, что здесь interface подразумевается в широком смысле, а не в смысле interface основанного на vtable.
Я знаю. Твое мне не понравилось тем, что там было сказано "одинаковым образом", в то время как специальный полиморфизм подразумевает "разным образом". Uniform interface — это корректно.
DG>>>при этом реализация полиморфизма через vtable, это частный случай реализации полиморфизма. S>>Не реализации, а вообще, частный случай полиморфизма. Конкретно — subtype полиморфизма. Который есть подвид ad-hoc полиморфизма с разрешением конкретного поведения во время выполнения по первому аргументу.
DG>в целом, вроде согласен. DG>смущает только середина. что здесь такое subtype? является ли, например, int субтипом double? вообще? и в конкретных языках программирования?
так ты сходи по ссылочке из вики.
S>>Ты смешал в одну кучу параметрический и специальный полиморфизм. в Main null обрабатывается как за счет параметрического, а в Inverce за счет обработки специального случая, но без полиморфизма. Таким образом, null тут таки ломает.
DG>зачем ты лезешь в реализацию? DG>если бы был язык полностью похожий на C#, но там можно было бы указать для null отдельную vtable со своими реализациями каждой функции, то следующий код был бы полиморфным? DG>
DG>foreach (var p in new Point[]{new Point(), null})
DG> p.Inverse();
DG>
Зачем выдумывать язык для NullObject?
Этот код не полиморфен. null здесь не абстрактный null. Это значение типа ссылка на Point. Здесь в цикле ты работаешь с одним единственным типом — Point. Потому по определению никакого полиморфизма не будет. Если, конечно твой null-объект не окажется унаследованным от Point...
DG>>>согласен будет. только при этом код станет O(n*logn) вместо O(n) и концепция Нулевые побочные затраты, если не используется, пойдут к черту, а так все замечательно. S>>Могу подсказать решение за O(n)
DG>давай
сделать глубокую копию списка поинтов, инвертировать поинты в нем, потом перенести изменения на поинты исходного списка.
DG>>>это я намекаю на то, что определения подбираются такие, чтобы код был хорошим, а не наоборот — подбирается код (в том числе ужасный) под раз зафиксированные определения. S>>В этом и проблема, что ты подбираешь определения для того что бы сделать конкретную функцию удовлетворяющей спецификацию, причем рассчитываешь на то что тот кто использует твой код и его определения не совпадают с твоими, будет писать некие адаптеры с ненулевыми побочными затратами.
DG>затраты там почти всегда нулевые, особенно если код подвергается суперкомпиляции
Ты надеешься что суперкомпиляция сможет нарисовать код, который с нулевыми затратами будет преобразовывать мутабельные поинты в иммутабельные и обратно после инвертирования иммутабельных?
S>> Кроме того, твои изыски с ООП кажутся мне совершенно необоснованными. Не испытываю никаких сложностей в том что бы использовать идентичность по ECMA при разработке и объяснении своих решений.
DG>результативность не является достаточным критерием для обоснования хорошести решений. как минимум еще выделяют эффективность, экономичность, экологичность. на следующий уровнях еще больше плоскостей выделяется.
Есть решение, записанное в коде. До такого же решения (по крайней мере с инвертированием точек) я могу дойти не извращая ООП. А если я дойду до него не извращая ООП, значит оно окажется столь же эффективным и даже экологичным. Так нафига ломать себе голову?
Покажи преимущества, которые недостижимы с штатной идентичностью...
S>Мне это известно. Я широко использую immutable-объекты, но мне не нужно для их использования переопределять идентичность и понятие объекта.
в том числе и при использовании суперкомпиляции?
если immutable-объект не является объектом (не является эквивалентым объекту), то почему тогда при суперкомпиляции его можно преобразовывать в mutable-объекты?
S>Стоит, но только если есть уверенность что заказчик понимает требования точно так же.
что-то мне подсказывает, что заказчику пофигу, считается null — объектом или нет.
это чисто твоя догма, а не заказчика.
DG>>например: DG>>считать null объектом или не считать — это типичное требование, верность которого относительна в зависимости от того при каком подходе получается более лучшее решение. S>Я не вижу как то, считать null объектом или нет, сказывается на решении.
если считать, что для хорошего кода доказывается его корректность (хотя бы не явно), что делается через спецификации, а когда null не считается объектом, то спецификации получаются более раздутыми, что исходя из ограниченности ресурсов, приводит к тому, что корректность программы доказывается в намного меньших масштабах
DG>>ты же считаешь что мнение "null — это не объект" — абсолютно(не зависит от контекста), или другими словами догматично, и тебя не интересует будет ли решение при этом лучше или хуже. Тебе лишь важно, чтобы догма "null не объект" сохранялась. S>Прежде всего, я отличаю объект от ссылки на него. И это мне не мешает, а помогает.
примеры кода, пожалуйста, на которых видно обоснованность данного вывода.
Здравствуйте, DarkGray, Вы писали:
S>>Мне это известно. Я широко использую immutable-объекты, но мне не нужно для их использования переопределять идентичность и понятие объекта.
DG>в том числе и при использовании суперкомпиляции?
Суперкомпиляцию я не использую DG>если immutable-объект не является объектом (не является эквивалентым объекту), то почему тогда при суперкомпиляции его можно преобразовывать в mutable-объекты?
А почему immutable не является объектом?
И почему суперкомпиляция должна преобразовывать его в mutable объект?
Ты хочешь сказать, что по коду инвертирования списка иммутабельных точек суперкомпиляция сделает код инвертирования мутабельных точек? С чего бы?
S>>Стоит, но только если есть уверенность что заказчик понимает требования точно так же.
DG>что-то мне подсказывает, что заказчику пофигу, считается null — объектом или нет. DG>это чисто твоя догма, а не заказчика.
А вот иммутабельна точка или нет — может быть не пофигу.
S>>Я не вижу как то, считать null объектом или нет, сказывается на решении.
DG>если считать, что для хорошего кода доказывается его корректность (хотя бы не явно), что делается через спецификации, а когда null не считается объектом, то спецификации получаются более раздутыми, что исходя из ограниченности ресурсов, приводит к тому, что корректность программы доказывается в намного меньших масштабах
Поменьше используй null-ы будет тебе спецификация с доказательствами покороче.
DG>>>ты же считаешь что мнение "null — это не объект" — абсолютно(не зависит от контекста), или другими словами догматично, и тебя не интересует будет ли решение при этом лучше или хуже. Тебе лишь важно, чтобы догма "null не объект" сохранялась. S>>Прежде всего, я отличаю объект от ссылки на него. И это мне не мешает, а помогает.
DG>примеры кода, пожалуйста, на которых видно обоснованность данного вывода.
Примеры кода, которые показывают как мне это помогает? Это субъективно. На уровне мух и котлет. Кому-то нравится, но не мне.
DG>>в целом, вроде согласен. DG>>смущает только середина. что здесь такое subtype? является ли, например, int субтипом double? вообще? и в конкретных языках программирования? S>так ты сходи по ссылочке из вики.
NullObject как раз под это определение подходит, а NullObject в зависимости от договоренностей и возможностей языка может реализовываться и через null
S>Зачем выдумывать язык для NullObject?
потому что это отдельный subtype, требующий отдельного описания.
S>Этот код не полиморфен. null здесь не абстрактный null.
с точки зрения выделения subtype — это не требуется.
также не требуется, что subtype (и type) соответствовали типам из ЯП на котором реализуется программа.
S> Это значение типа ссылка на Point. Здесь в цикле ты работаешь с одним единственным типом — Point. Потому по определению никакого полиморфизма не будет. Если, конечно твой null-объект не окажется унаследованным от Point...
когда я пытаюсь сформировать видение твоего мировозрения, то у меня появляется чувство диссонанса.
1. с одной стороны, ты вроде понимаешь, что абстрактные (как концепции) type, subtype, object, полиморфизм и т.д. существуют в коде в независимости от того, как в ЯП реализованы их конкретные аналоги, и что при этом отношения между абстрактными и конкретными аналогами не 1 к 1.
2. с другой стороны, утверждения ты часто строишь по схеме — в моем любимом языке конкретная реализация подразумевает то и то, из этого следует, что в моем любимом языке тоже самое следует и для абстрактных type, subtype, object и т.д.
S>сделать глубокую копию списка поинтов, инвертировать поинты в нем, потом перенести изменения на поинты исходного списка.
S> потом перенести изменения на поинты исходного списка
как вот это будет делаться за O(n), и какой алгоритм будет использоваться для понимания, какой immutable-объект из результата какому mutable-объекту соответствует? в частности для тех же point-ов
S>Ты надеешься что суперкомпиляция сможет нарисовать код, который с нулевыми затратами будет преобразовывать мутабельные поинты в иммутабельные и обратно после инвертирования иммутабельных?
суперкомпиляция, как минимум, на основе immutable-кода может построить его inplace-версию кода поверх mutable-объектов, и такой код имеет нулевые затраты.
напомню, что под immutable-объектом я понимал объект с immutable-версионностью, и что операции изменяющие immutable-объект выдают тот же самый объект
S>И почему суперкомпиляция должна преобразовывать его в mutable объект?
это желательное требование, потому что inplace реализации поверх mutable-объектов обеспечивают бОльшую вычислительную эффективность.
S>Ты хочешь сказать, что по коду инвертирования списка иммутабельных точек суперкомпиляция сделает код инвертирования мутабельных точек? С чего бы?
если поставлена задача обеспечить максимальную эффективность, то сделает.
DG>>примеры кода, пожалуйста, на которых видно обоснованность данного вывода. S>Примеры кода, которые показывают как мне это помогает? Это субъективно. На уровне мух и котлет. Кому-то нравится, но не мне.
и соответственно, целиком утверждение которое ты остаиваешь в этот треде выглядит как?:
мне лично субъективно не нравится когда не различают ссылки и объекты, поэтому я тебе запрещаю говорить на форуме, что "можно быстро разрабатывать эффективные и простые программы и не различать при этом ссылки и объекты".
ты согласен с такой формулировкой?
S>Покажи преимущества, которые недостижимы с штатной идентичностью...
хотя бы разработка полноценного редактора схем (фигурки + связи) поверх трехзвенки: БД, web-сервер и браузер.
если использовать штатную идентичность, это как минимум потребует написания трех вариантов кода для написания одного и того же, но для различных сред исполнения: sql, серверный ЯП, js, как минимум из-за того, что на основе кода со штаной идентичностью геморройно создается аналогичный код для других языков, распределенного контекста и т.д.
DG>>>в целом, вроде согласен. DG>>>смущает только середина. что здесь такое subtype? является ли, например, int субтипом double? вообще? и в конкретных языках программирования? S>>так ты сходи по ссылочке из вики.
DG>NullObject как раз под это определение подходит, а NullObject в зависимости от договоренностей и возможностей языка может реализовываться и через null
Т.е. ты решил null сделать подтипом объетка, что бы вписаться в формулировку?
S>>Зачем выдумывать язык для NullObject?
DG>потому что это отдельный subtype, требующий отдельного описания.
А язык-то зачем выдумывать? NullObject можно вписать много куда.
S>>Этот код не полиморфен. null здесь не абстрактный null.
DG>с точки зрения выделения subtype — это не требуется. DG>также не требуется, что subtype (и type) соответствовали типам из ЯП на котором реализуется программа.
У тебя и с типами такая же каша?
S>> Это значение типа ссылка на Point. Здесь в цикле ты работаешь с одним единственным типом — Point. Потому по определению никакого полиморфизма не будет. Если, конечно твой null-объект не окажется унаследованным от Point...
DG>когда я пытаюсь сформировать видение твоего мировозрения, то у меня появляется чувство диссонанса. DG>1. с одной стороны, ты вроде понимаешь, что абстрактные (как концепции) type, subtype, object, полиморфизм и т.д. существуют в коде в независимости от того, как в ЯП реализованы их конкретные аналоги, и что при этом отношения между абстрактными и конкретными аналогами не 1 к 1. DG>2. с другой стороны, утверждения ты часто строишь по схеме — в моем любимом языке конкретная реализация подразумевает то и то, из этого следует, что в моем любимом языке тоже самое следует и для абстрактных type, subtype, object и т.д.
А я что-то говорил про свой любимый язык?
Понимаешь, сколько не думай о системе типов дотнета как о системе типов хаскеля, она ею не станет. Потому, все решения, которые можно записать в дотнете, объяснимы в терминах системы типов дотнета. Даже если что-то придется эмулировать, то это что-то имеет объяснение в терминах типов дотнета. И что бы объяснить это решение или что-то доказать, не нужно выдумывать новые определения, которые чреваты косяками типа идентичности всевозможных строк.
S>>сделать глубокую копию списка поинтов, инвертировать поинты в нем, потом перенести изменения на поинты исходного списка.
S>> потом перенести изменения на поинты исходного списка
DG>как вот это будет делаться за O(n), и какой алгоритм будет использоваться для понимания, какой immutable-объект из результата какому mutable-объекту соответствует? в частности для тех же point-ов
Тривиально
var list1 = list.Select(p => new Point(p.x, p,y)).ToList();
for (int i = 0; i < list.Count; i++)
{
var p = list1[i];
p.Inverse();
list[i].x = p.x;
list[i].y = p.y;
}
S>>Ты надеешься что суперкомпиляция сможет нарисовать код, который с нулевыми затратами будет преобразовывать мутабельные поинты в иммутабельные и обратно после инвертирования иммутабельных?
DG>суперкомпиляция, как минимум, на основе immutable-кода может построить его inplace-версию кода поверх mutable-объектов, и такой код имеет нулевые затраты.
Если не в лом, покажи мне код после суперкомпиляции. Хотя бы то, как мог бы выглядеть его аналог с мутабл объектами.
Здравствуйте, DarkGray, Вы писали:
S>>А почему immutable не является объектом?
DG>это надо тебя спросить.
Я такого не утвреждал. Sinclair?
DG>напомню, что под immutable-объектом я понимал объект с immutable-версионностью, и что операции изменяющие immutable-объект выдают тот же самый объект
Я под иммутабл объектом понимаю прежде всего объект (с нормальной такой идентичностью), который ведет себя так, что никаких изменений в его поведении не может быть обнаружено извне.
S>>И почему суперкомпиляция должна преобразовывать его в mutable объект?
DG>это желательное требование, потому что inplace реализации поверх mutable-объектов обеспечивают бОльшую вычислительную эффективность.
Может ты покажешь такое преобразование кода, которое могла бы выполнить суперкомпиляция. Желательно с нулевыми затратами на выполнение инверсии.
S>>Ты хочешь сказать, что по коду инвертирования списка иммутабельных точек суперкомпиляция сделает код инвертирования мутабельных точек? С чего бы?
DG>если поставлена задача обеспечить максимальную эффективность, то сделает.
Покажи
DG>>>примеры кода, пожалуйста, на которых видно обоснованность данного вывода. S>>Примеры кода, которые показывают как мне это помогает? Это субъективно. На уровне мух и котлет. Кому-то нравится, но не мне.
DG>и соответственно, целиком утверждение которое ты остаиваешь в этот треде выглядит как?: DG>мне лично субъективно не нравится когда не различают ссылки и объекты, поэтому я тебе запрещаю говорить на форуме, что "можно быстро разрабатывать эффективные и простые программы и не различать при этом ссылки и объекты". DG>ты согласен с такой формулировкой?
Я утверждаю что разрабатывать эффективные и простые программы можно и не путая ссылки и объекты. Но можно и путая, чего я запрещать не собираюсь. Я только не понимаю, зачем их надо путать?
S>>Покажи преимущества, которые недостижимы с штатной идентичностью...
DG>хотя бы разработка полноценного редактора схем (фигурки + связи) поверх трехзвенки: БД, web-сервер и браузер. DG>если использовать штатную идентичность, это как минимум потребует написания трех вариантов кода для написания одного и того же, но для различных сред исполнения: sql, серверный ЯП, js, как минимум из-за того, что на основе кода со штаной идентичностью геморройно создается аналогичный код для других языков, распределенного контекста и т.д.
Вот беда. Ради трехзвенки тебе нужно обязательно ломать идентичность? Что мешает использовать отношение послабже, например эквивалентность по ключу?
S>var list1 = list.Select(p => new Point(p.x, p,y)).ToList();
S>for (int i = 0; i < list.Count; i++)
S>{
S> var p = list1[i];
S> p.Inverse();
S> list[i].x = p.x;
S> list[i].y = p.y;
S>}
S>
при этом для обоснования корректности, ты используешь то, что:
объект list[i] переходит в объект list1[i], который переходит в условный p[i], далее p_измененный[i], и затем опять list[i].
и обоснование, что изменение получит именно тот объект, для которого они и предназначались строится через доказательство корректности преобразований над ссылками, а не над самими объектами.
переход list[i] -> list1[i] -> p[i] -> p_измененный[i] -> list[i] — это и есть трасса.
S>>>Ты надеешься что суперкомпиляция сможет нарисовать код, который с нулевыми затратами будет преобразовывать мутабельные поинты в иммутабельные и обратно после инвертирования иммутабельных?
DG>>суперкомпиляция, как минимум, на основе immutable-кода может построить его inplace-версию кода поверх mutable-объектов, и такой код имеет нулевые затраты. S>Если не в лом, покажи мне код после суперкомпиляции. Хотя бы то, как мог бы выглядеть его аналог с мутабл объектами.
все сильно зависит от того, насколько сильные предусловия сможет доказать суперкомпилятор для точек, которые передаются в InversePoints, в частности интересует кол-во использований и способ использования результата и входа.
для InversePoints можно построить как минимум следующие оптимизированные версии в дополнение к immutable-варианту
(ienumerable раскрывается в массив, как в самую быструю штуку в .net-е, при необходимости может появляться slice-версия (points, start_index, count) и т.д.):
void InversePoints_Inplace(this S_Point[] points)
{
for (int i = 0; i < points.Length; ++i)
{
p[i].X = -p[i].X;
p[i].Y = -p[i].Y;
}
}
struct S_Point
{
public int X;
public int Y;
...
}
class Point
{
public int X;
public int Y;
public Point Inverse()
{
return new Point{X = X, Y = Y};
}
public void Inverse_Inplace()
{
X = -X;
Y = -Y;
}
}
//используется только если компилятор может доказать, что все исходные point-ы различныеvoid InverseDifferentPoints_Inplace(this Point[] points)
{
for (int i = 0; i < points.Length; ++i)
{
p[i].X = -p[i].X;
p[i].Y = -p[i].Y;
}
}
void InversePoints_Inplace(this Point[] points)
{
var _points = new S_Point[points.Length];
for(int i = 0; i < points.Length; ++i)
{
_points[i].X = -points[i].X;
_points[i].Y = -points[i].Y;
}
for(int i = 0; i < points.Length; ++i)
{
points[i].X = _points[i].X;
points[i].Y = _points[i].Y;
}
}
Здравствуйте, DarkGray, Вы писали:
S>>Тривиально S>>
S>>var list1 = list.Select(p => new Point(p.x, p,y)).ToList();
S>>for (int i = 0; i < list.Count; i++)
S>>{
S>> var p = list1[i];
S>> p.Inverse();
S>> list[i].x = p.x;
S>> list[i].y = p.y;
S>>}
S>>
DG>при этом для обоснования корректности, ты используешь то, что: DG>объект list[i] переходит в объект list1[i], который переходит в условный p[i], далее p_измененный[i], и затем опять list[i].
Ничто никуда не переходит. Объект list[i] остается самим собой. Объект list1[i] с list[i] никак не связан, кроме того что получен с использованием значений полей объекта list[i]. Больше их ничего не связывает.
DG>и обоснование, что изменение получит именно тот объект, для которого они и предназначались строится через доказательство корректности преобразований над ссылками, а не над самими объектами.
Оно строится через порядковые места в списках.
DG>переход list[i] -> list1[i] -> p[i] -> p_измененный[i] -> list[i] — это и есть трасса.
Нет никакой трассы.
DG>>>суперкомпиляция, как минимум, на основе immutable-кода может построить его inplace-версию кода поверх mutable-объектов, и такой код имеет нулевые затраты. S>>Если не в лом, покажи мне код после суперкомпиляции. Хотя бы то, как мог бы выглядеть его аналог с мутабл объектами.
DG>все сильно зависит от того, насколько сильные предусловия сможет доказать суперкомпилятор для точек, которые передаются в InversePoints, в частности интересует кол-во использований и способ использования результата и входа.
Ты сам сказал, что это библиотечный метод.
DG>для InversePoints можно построить как минимум следующие оптимизированные версии в дополнение к immutable-варианту DG>(ienumerable раскрывается в массив, как в самую быструю штуку в .net-е, при необходимости может появляться slice-версия (points, start_index, count) и т.д.): DG>
DG>void InversePoints_Inplace(this S_Point[] points)
DG>{
DG> for (int i = 0; i < points.Length; ++i)
DG> {
DG> p[i].X = -p[i].X;
DG> p[i].Y = -p[i].Y;
DG> }
DG>}
Это не работает для повторяющихся экземпляров. Суперкомпилятор не знает, будут ли они повторяться. Это библиотечный метод
DG>//используется только если компилятор может доказать, что все исходные point-ы различные
Как он может доказать что все поинты различные, если метод библиотечный?
Ты вообще о какой библиотеке говорил? Об dll или о библиотеке исходных кодов для суперкомпиляции?
