Здравствуйте, Serginio1, Вы писали:

ВВ>>В ФП используются тюплы. К тюплам никаких претензий нет.
S> Это я знаю, а как быть тем кто пока не использует ФП, и как взаимодествовать с не ФП кодом без переходников? Правда я слышал слово монада.Эх надо дочитать книжку ао Хаскеллу

Вообще на самом деле много out-параметров — по крайней мере в ОО-языке — это в 99% случаев pure evil. ОО все же предполагает, что мы должны описать отдельные сущности, обладающие определенным поведение и пр. — а тут ни с того с сего наш метод возвращает кучу разрозненных "атрибутов". Эти атрибуты к какой сущности относятся? Как они связаны? Если они никак не связаны, то значит метод спроектирован неправильно и выполняет разнородные операции. Если связаны — то где сущность?

А единственный "правоверный" вариант — флажок, идентифицирующий выполнилась ли операция, и собственно результат операции — прекрасно заменяется на одну стандартную структурку.

Здравствуйте, Воронков Василий, Вы писали:


ВВ>Наиболее распространенная ситуация с out — это когда метод возвращает 2 значения, например, булевое и собственно результат какого-нибудь действия. Тут вообще можно универсальную структурку сделать.

ВВ>

ВВ>class Result<T>
ВВ>{
ВВ>    bool Flag { get; }
ВВ>    T Value { get; }
ВВ>}
ВВ>

ВВ>Много out-параметров бывают реже, но и метод с ними выглядит довольно загаженно. Вызов этого метода менее удобен и пр.
По мне уж Лучше ввести тюплы в состав языка. Если уж есть направление в сторону ФП, да и мыслить едиными стандартами проще.
Да и изменение состояния переданых объектов это скрытый реф (мутабле имутабле разные миры).

Здравствуйте, Serginio1, Вы писали:

S>По мне уж Лучше ввести тюплы в состав языка. Если уж есть направление в сторону ФП, да и мыслить едиными стандартами проще.

Да вроде и будут они. Ты же спросил, как сейчас быть.

S>Да и изменение состояния переданых объектов это скрытый реф (мутабле имутабле разные миры).

Изменение состояние переданных объектов — это не скрытый реф, это явный реф

Здравствуйте, Воронков Василий, Вы писали:

ВВ>А единственный "правоверный" вариант — флажок, идентифицирующий выполнилась ли операция, и собственно результат операции — прекрасно заменяется на одну стандартную структурку.
Полностью Согласен. Но сколько такого кода уже написано уже некий стиль программирования выработался,даи возни со структурками по сравнению с единственным реф параметром меньше.
А сколько функций с HRESULT ..... Ну это так к слову.

Здравствуйте, Воронков Василий, Вы писали:

S>>Да и изменение состояния переданых объектов это скрытый реф (мутабле имутабле разные миры).

ВВ>Изменение состояние переданных объектов — это не скрытый реф, это явный реф
С точки зрения GC несовсем, да и ты видя описание функции мало очем догадываешься. Да и как с ними быть???

Здравствуйте, Serginio1, Вы писали:

S>Полностью Согласен. Но сколько такого кода уже написано уже некий стиль программирования выработался,даи возни со структурками по сравнению с единственным реф параметром меньше.

Вообще написано очень много кривого кода, это ж не значит, что нужно продолжать так писать. Потом я ж говорю — проблема с множественными out-параметрами не "структурками" решается, а перепроектированием функций в принципе, т.к. они написаны криво.
Т.е. out по большому счету нужен для того, чтобы писать кривой код.

S>А сколько функций с HRESULT ..... Ну это так к слову.

В C# нет никакого HRESULT. А интероп это отдельная тема, и мне не особо нравится как реализована работа через PInvoke, к слову.

Здравствуйте, Serginio1, Вы писали:

ВВ>>Изменение состояние переданных объектов — это не скрытый реф, это явный реф
S>С точки зрения GC несовсем, да и ты видя описание функции мало очем догадываешься. Да и как с ними быть???

Ну сейчас уже никак, если необходима поддержка существующего кода. C# хоть и свежий довольно язык, в него нафигачили очень много ерунды для "совместимости" с С. А так, мне нравится подход в PL/SQL — все параметры immutable.
Собственно, сейчас в C# более чем достаточно средств, чтобы по крайней мере не продолжать так писать.

Здравствуйте, Воронков Василий, Вы писали:
ВВ>Ну сейчас уже никак, если необходима поддержка существующего кода. C# хоть и свежий довольно язык, в него нафигачили очень много ерунды для "совместимости" с С. А так, мне нравится подход в PL/SQL — все параметры immutable.
ВВ>Собственно, сейчас в C# более чем достаточно средств, чтобы по крайней мере не продолжать так писать.
извини за вопросы. Я просто сильно отстал от жизни. Просто введут понятие мутабле и имутабле? И еще у immutable в ФП есть понятие версионность?
Понимаю, что immutable можно легко самому написать.

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Ну сейчас уже никак, если необходима поддержка существующего кода. C# хоть и свежий довольно язык, в него нафигачили очень много ерунды для "совместимости" с С. А так, мне нравится подход в PL/SQL — все параметры immutable.
ВВ>>Собственно, сейчас в C# более чем достаточно средств, чтобы по крайней мере не продолжать так писать.
S>извини за вопросы. Я просто сильно отстал от жизни. Просто введут понятие мутабле и имутабле?

Не очень понял. В принципе эти понятия и сейчас есть.

Здравствуйте, Воронков Василий, Вы писали:
ВВ>Не очень понял. В принципе эти понятия и сейчас есть.
Спасибо Это я чего то с немерле попутал. Доразберусь Хаскеллем, умнее стану.

Здравствуйте, Klapaucius, Вы писали:

Не надо разводить демагогию. Среди причин "неправильного" шарпа именно вы постулируете его несмотрение по сторонам, хотя причин таких может быть бульоны. Вы не знаете этих причин, мы не знаем этих причин, но при этом вы уверенно считаете, что там есть прицина "не смотрел по сторонам". Доказывайте это. В ответ сторонники этого мнения приводят пространные рассуждения по поводу того, как бы они могли сделать шарп лучше, и почему он и вправду был бы лучше (для них) и потом говорят, что нам нечем их пространные рассуждения опровергнуть. Дак и ни к чему, они ничего не доказывают. Разве что то, что Хейлсберг не лично для них старался.
Вы за аксиому принимаете то, что как раз следует доказывать. Потому что вероятность того, что инженер на ощупь намалевал Дельфи и шарпы поменьше будет, чем если он взвесил некоторые причины, которые нам, разумеется, известны лишь отчасти.

А перевод у вас, мягко говоря, неудался. И слова мои подменили, и перевод испортили. Правильно вот так:
VE>Как из некоего комикса:
VE>- I have i ball
K>— Были серьезные основания.
— Хейлсберг не смотрел по сторонам
VE>- Proof it
K>— Какие?
— Докажите
VE>- You can't proof that i haven't!
K>— Не знаю, но попробуй доказать, что их небыло!
— Вы не можете доказать, что это не так! // "У вас нет аргументов" и прочее, читать выше, там много было

Здравствуйте, Klapaucius, Вы писали:

Я понял вашу позицию. Вы принимаете за аксиому его несмотрение по сторонам, а "остальные причины", оказывается, надо доказывать в силу презумпции несуществования (с вашей точки зрения). У меня же немного наоборот. Нормальный ход разработки я считаю наиоблее вероятным, а вот казусы вроде "тупил 20 лет" как раз следует доказать.

Осталось поинтересоваться, на основе каких наблюдений и чьём опыте "несмотрение по сторонам" для вас является наиболее вероятной причиной.

Здравствуйте, VoidEx, Вы писали:

VE>Здравствуйте, Klapaucius, Вы писали:

VE>Я понял вашу позицию. Вы принимаете за аксиому его несмотрение по сторонам, а "остальные причины", оказывается, надо доказывать в силу презумпции несуществования (с вашей точки зрения). У меня же немного наоборот. Нормальный ход разработки я считаю наиоблее вероятным, а вот казусы вроде "тупил 20 лет" как раз следует доказать.

VE>Осталось поинтересоваться, на основе каких наблюдений и чьём опыте "несмотрение по сторонам" для вас является наиболее вероятной причиной.

А все очень просто. У Вульфхаунда есть аргументы в защиту его точки зрения. А у вас нет ни аргументов, ни наблюдений, ничего нет. Только демагогия.

Здравствуйте, Воронков Василий, Вы писали:

ВВ> А так, мне нравится подход в PL/SQL — все параметры immutable.

Правда чтоли ? OUT NOCOPY тоже ???

Здравствуйте, Константин Б., Вы писали:

КБ>А все очень просто. У Вульфхаунда есть аргументы в защиту его точки зрения. А у вас нет ни аргументов, ни наблюдений, ничего нет. Только демагогия.
Какой точки зрения? Что несмотрение по сторонам надо принимать за аксиому? Или что несмотрение по сторонам не надо принимать за аксиому, но оно таки имело место быть? Если второе, то у него таких аргументов нет. Потому что звучат они примерно "я не вижу другого объяснения, как если бы он не смотрел по сторонам". Ну это такой же аргумент, как и моя демагогия. Только у меня хоть здравый смысл в рассуждениях.

Здравствуйте, Gluk_Kazan, Вы писали:

G_K>Правда чтоли ? OUT NOCOPY тоже ???

Ну как можно догадаться речь не про Out.

Здравствуйте, VoidEx, Вы писали:

VE>Не надо разводить демагогию.

Правильно, не надо.

VE>Среди причин "неправильного" шарпа именно вы постулируете его несмотрение по сторонам,

Charmant! Теперь я уже, оказывается, постулирую чье-то там несмотрение по сторонам. Вы, разумеется, не указали цитат, которые это подтверждают. Конечно, сделать это непросто, ведь я ничего такого не постулировал.
Я включился в дискуссию, когда вы поставили под сомнение методику WolfHound, когда же я ответил на вашу критику, вы, по всей видимости, поняв, что с подходом все в порядке, внезапно сделали разворот на 180 градусов и поставили в вину мне то, что я не следую методике, следование которой не так давно сами же ставили в вину. И все это под прикрытием призыва "Он обижает Хейлсберга!", на который должна подойти подмога, по всей видимости. Самое же забавное, что в комплекте идет и обвинение меня в демагогии.

VE>хотя причин таких может быть бульоны. Вы не знаете этих причин, мы не знаем этих причин, но при этом вы уверенно считаете, что там есть прицина "не смотрел по сторонам".

Миелофон не сработал. Мне малоинтересны обоснования некомпетентности Хейлсберга. Это нетрудно вывести хотя-бы из того факта, что в обсуждении его компетентности я участия не принимал.

VE>Доказывайте это. В ответ сторонники этого мнения приводят пространные рассуждения по поводу того, как бы они могли сделать шарп лучше, и почему он и вправду был бы лучше (для них) и потом говорят, что нам нечем их пространные рассуждения опровергнуть. Дак и ни к чему, они ничего не доказывают. Разве что то, что Хейлсберг не лично для них старался.

Я не вступался здесь за какие-то "пространные рассуждения", особенно, в вашем пересказе, освещающем их с соотвествующей вашим интересам стороны. Я подтверждаю практичность подхода WolfHound.
Каким образом вы предлагаете доказывать то, что кто-то что-то не делал? Это также практически сложно.
На практике чаще доказывают, что кто-то что-то делал. Доказывают, что убивал, а не то, что не убивал. Доказывают, что крал, а не то, что не крал. Вы доказываете факт оплаты проезда, предъявляя билет и факт покупки, предъявляя чек, но не наоборот.

VE>Вы за аксиому принимаете то, что как раз следует доказывать. Потому что вероятность того, что инженер на ощупь намалевал Дельфи и шарпы поменьше будет, чем если он взвесил некоторые причины, которые нам, разумеется, известны лишь отчасти.

Это разумеется? Как раз то что причины неизвестны тем, кто уверен что они есть, мне и кажется противоестественным. Лично я, не зная причин, отношусь к их существованию со скепсисом.
Если же они отчасти таки известны, было бы неплохо с ними ознакомится — технические причины мне интересны и я жду не дождусь, когда же их озвучат.

К сожалению, дело к этому все никак не придет. Напротив, заинтересованность в фактах объявляют демагогией и неправильной логикой.

VE>Я понял вашу позицию. Вы принимаете за аксиому его несмотрение по сторонам,

Вы неверно применяете терминологию. Аксиома может быть в какой-то языковой системе (геометрии или логике, например) там они постулируются как основа для строгих доказательств. В более широком смыле, когда речь заходит о теории, модели реальности, аксиомами могут назвать какие-то принимаемые без доказательств положения, которые могут, например, быть выведены их опыта. Но это не совсем корректный, устаревший позитивистский подход.
Презумпция кардинально отличается от аксиомы. Это эвристика. На ней ничего не основывается — она просто указывает направление для более быстрого нахождения решения. Презумпция просто считается верной до тех пор, пока не доказано обратное. Т.е. ее опровержение не только допускается, но и ожидается.

VE>Осталось поинтересоваться, на основе каких наблюдений и чьём опыте "несмотрение по сторонам" для вас является наиболее вероятной причиной.

Потрясающе. Перевели эпистемологический спор на профессиональную компетентность Хейльсберга (пусть даже и обратно, но все-же было лучше, когда обсуждение Хейлсберга пытались перевести на обсуждение технических проблем), а теперь еще и на мою. Хотите поговорить об этом?

G_K>>Правда чтоли ? OUT NOCOPY тоже ???

ВВ>Ну как можно догадаться речь не про Out.

Мутабельный IN вещч конечно в PL/SQL до зарезу необходимая

Здравствуйте, Gluk_Kazan, Вы писали:

ВВ>>Ну как можно догадаться речь не про Out.
G_K>Мутабельный IN вещч конечно в PL/SQL до зарезу необходимая

Покривляться хочется? immutable in необходим в C#.

Здравствуйте, Klapaucius, Вы писали:

K>Это разумеется? Как раз то что причины неизвестны тем, кто уверен что они есть, мне и кажется противоестественным. Лично я, не зная причин, отношусь к их существованию со скепсисом.

Сравни:

Я считаю что ты ммм... пишешь сюда, чтобы доказать, какие тут дураки собрались. Другие причины, по которым ты сюда пишешь, мне неизвестны. То, что причины неизвестны тем, кто уверен что они есть, мне и кажется противоестественным. Лично я, не зная причин, отношусь к их существованию со скепсисом.

Мысль понятна?
Доказывать надо первоначально высказанное утверждение, т.е. то, что именно несмотрение по сторонам является причиной дизайна шарпа, потому что, априори, исходя из презумпции невиновности, такие причины есть. Иначе таким путем можно много чего доказать. Я могу обвинить кого угодно в чем угодно, и, пользуясь твоей странной логикой, потребовать доказательство обратного.

K>Если же они отчасти таки известны, было бы неплохо с ними ознакомится — технические причины мне интересны и я жду не дождусь, когда же их озвучат.

А если причины нетехнические?

K> В более широком смыле, когда речь заходит о теории, модели реальности, аксиомами могут назвать какие-то принимаемые без доказательств положения, которые могут, например, быть выведены их опыта. Но это не совсем корректный, устаревший позитивистский подход.