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

AVK>>Практика у всех разная. В моей практике отсутствие предопределенных имен для параметров лямбд (особенно описанных стандартными Action/Func) уже является проблемой. А в случае кортежей это еще важнее.

VD>Твоя практика однобока.

Чья бы корова мычала. Не я тут все топики свожу к обсуждению языка на букву Н. И не я уже лет десять, наверное, занимаюсь ровно одним единственным проектом.

AVK>>Это вопрос поддержки со стороны рантайма.
VD>Всего то? В следующий раз не забудь дочитать сообщение на которое отвечаешь хотя бы до середины.

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

И, если бы ты топик до конца дочитал, ты бы увидел, что эту проблему тут уже обсудили и ты ничего нового не сказал.

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

Ну, "какая то" может и нужна. "Какая то" уже в шарпе есть — и в наложении делегатов на методы, и в существующих анонимных типах. Вопрос только в том — какая. Полномасштабная — не нужна.

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

AVK>Чья бы корова мычала. Не я тут все топики свожу к обсуждению языка на букву Н.

Действительно чья бы молчала? Ну, так чисто логически?

AVK>И не я уже лет десять, наверное, занимаюсь ровно одним единственным проектом.

А кто же еще? Или ты ушел из энтерпайза и начал писать на языке отличном от C#?

В общем, не обижайся, но говорить о практике можно только имея эту практику. Попиши хотя бы пару месяцев на языке с кортежами (не обязательно на букву N, можно на F, H, M) и тогда обсудим практику. А до тех пор, давай будем доверять мнению тех из нас, кто это уже сделал. Я не только на основании своего мнения вывод делаю. Я у многих пишущих на ФЯ этот вопрос выяснял и мнение единодушное — кортежи очень удобны при наличии ПМ.

AVK>>>Это вопрос поддержки со стороны рантайма.
VD>>Всего то? В следующий раз не забудь дочитать сообщение на которое отвечаешь хотя бы до середины.

AVK>Это ты попробуй немножко голову включить



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

Обязательно. Обойтись без нее нельзя. Ее можно эмулировать в рамках одной сборки (тупо заменяя все типы с одним и тем же именем на один тип). Но это все равно будет структурня типизация. Вот только довольно странная — первого порядка.

AVK>И, если бы ты топик до конца дочитал, ты бы увидел, что эту проблему тут уже обсудили и ты ничего нового не сказал.

То что ничего нового (за последние 5 лет) не сказали — я уже видел. Но это ничего не меняет. Потому как 10 раз повторенное заблуждение не становится истиной.

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

AVK>Ну, "какая то" может и нужна. "Какая то" уже в шарпе есть — и в наложении делегатов на методы, и в существующих анонимных типах. Вопрос только в том — какая. Полномасштабная — не нужна.

В шарпе — нет (за исключением параметрического полиморфизма, которого явно не достаточно).

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

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

VD>Это только если ты зациклен на мэйнтриме. А так без проблема:
VD>

VD>if (get_array_of_int() is (ary, 42))
VD>{
VD>  ... ary[41] ...
VD>}
VD>

Да нет, я ни на чем не зациклен. Но как этот ваш код может быть подставлен, например, в такое выражение:

if (myvar + Math.Pow(get_array_of_int().неясно_как_тут_вытащить_массив.Length + 10, 3) > 1) { ... }

Похоже, что никак. Надо распаковать результат функции, потом его части подставлять в выражение. А это уже непоследовательность с идеологической точки зрения.

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

ARK>Да нет, я ни на чем не зациклен.

ОК, "зациклен" здесь не совсем правильный термин. Скажем по другому — отсутствие знакомства с альтернативой.

ARK>Но как этот ваш код может быть подставлен, например, в такое выражение:
ARK>

ARK>if (myvar + Math.Pow(get_array_of_int().неясно_как_тут_вытащить_массив.Length + 10, 3) > 1) { ... }
ARK>

Я не уверен в том, что правильно понял пример. Но если стоит задача взять значение одного из элементов кортежа и использовать его в выражении, то в немерле это делается с помощью индексирования константным значением:

if (myvar + Math.Pow(get_array_of_int()[0].Length + 10, 3) > 1) { ... }

Кроме того есть еще много разных вкусностей вроде того, что все является выражением, так что можно объявить блок и вернуть из него значение:

{ def (x, y) = foo(); x + y } // вернет сумму элементов кортежа возвращенного функцией foo().

и многое другое.

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

VD>Я не уверен в том, что правильно понял пример. Но если стоит задача взять значение одного из элементов кортежа и использовать его в выражении

Да, именно это я и имел в виду.

VD>то в немерле это делается с помощью индексирования константным значением:
VD>

VD>if (myvar + Math.Pow(get_array_of_int()[0].Length + 10, 3) > 1) { ... }
VD>

Понял, спасибо. В принципе да, можно и такой подход применить, как вариант. Правда, есть риск при чтении кода спутать с массивом, ну и при рефакторинге можно нарваться на неприятность, если в тупле чего-нибудь изменить.

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

ARK>Правда, есть риск при чтении кода спутать с массивом,

Те же аргументы можно было бы использовать против индексаторов в классах, но вряд ли ты будешь возражать против них (так как пользуешься ими на практике и проблем не видишь).

Потом это вопрос синтаксиса. Тут можно и предопределенные поля использовать (как в Tuple<...> из дотнета). Главное, что это нет проблем получить значение одного из элементов.

ARK>ну и при рефакторинге можно нарваться на неприятность, если в тупле чего-нибудь изменить.

Тут полная аналогия с вызовом методов/функций. В большинстве сиподобных языков при вызове имена параметров опускаются, но мало кто рассуждает о проблемах при рефакторинге.

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

С кортежами имеет место банальное отсутствие практики. Они родились в ФЯ и пока еще не попали в статически-типизированные мэйнсрим-языки. На мой взгляд просто по недоразумению.

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

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

Вообще говоря останавливает, только не всех разумеется. Для примера смотри в шаблоны С++. Большая часть с++ программистов их тупо не понимает, отсюда неудивительно наблюдать здесь два лагеря, одни пишут по простому, их большинство,а другие в духе буста и александреску — их меньшинство.

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

I>Вообще говоря останавливает, только не всех разумеется. Для примера смотри в шаблоны С++. Большая часть с++ программистов их тупо не понимает, отсюда неудивительно наблюдать здесь два лагеря, одни пишут по простому, их большинство,а другие в духе буста и александреску — их меньшинство.

Это не связанные вещи. Основной проблемой мешающей создать качественный рефакторинг в С++ — это препроцессор (особенно #include) и отсутствие полноценной модульности. Сравнивать это с применение кортежей по меньшей мере странно. Уверяю тебя, что если в шарпе или С++ появится поддержка кортежей и сопоставления с образцом, ими будут пользоваться большинство программистов.

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

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

I>>Вообще говоря останавливает, только не всех разумеется. Для примера смотри в шаблоны С++. Большая часть с++ программистов их тупо не понимает, отсюда неудивительно наблюдать здесь два лагеря, одни пишут по простому, их большинство,а другие в духе буста и александреску — их меньшинство.

VD>Это не связанные вещи. Основной проблемой мешающей создать качественный рефакторинг в С++ — это препроцессор (особенно #include) и отсутствие полноценной модульности. Сравнивать это с применение кортежей по меньшей мере странно. Уверяю тебя, что если в шарпе или С++ появится поддержка кортежей и сопоставления с образцом, ими будут пользоваться большинство программистов.

Смотрим твою идейку:
"в коде много мест где при рефакторинге (особенно ручном) можно легко что-то сломать. Но это не останавливает людей от применения этих возможностей"

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

Вобщем ты начал хитрить

Вообще, по моему, языки не ориентированые на полноценный качественный рефакторинг должны обладать адскими преимуществами, что бы использоваться в индустрии. У C/С++ , например, одно из преимуществ это перформанс низкоуровневого кода от которого пока что никуда не деться. Скажем, ассемблеры уже давно не дают этот перформанс, т.к. процессоры слишком сложны для ручных оптимизаций.

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

H>Вот так можно возвращать несколько значений:
H>

H>def foo(a : int, b : int) : int * string
H>{
H>  def sum = a + b;
H>  (sum, sum.ToString())
H>}
H>def (sum, str) = foo(1, 2);
H>

Если возможно написать def (sum, str) = foo(1, 2), то можно ли написать def (sum, str) = (1, "Hello") ?
Если sum и str определены ранее, то можно их сгруппировать без def ? то есть типа такого (синтаксиса nemerle не знаю, но думаю что понятно я имею в виду)

def sum;
def str;
/// code
(sum, str) = foo(1, 2);

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

NC>Если возможно написать def (sum, str) = foo(1, 2), то можно ли написать def (sum, str) = (1, "Hello") ?

Можно.

NC>Если sum и str определены ранее, то можно их сгруппировать без def ? то есть типа такого (синтаксиса nemerle не знаю, но думаю что понятно я имею в виду)
NC>

def sum;
NC>def str;
NC>/// code
NC>(sum, str) = foo(1, 2);

А вот так в Nemerle нельзя. Сопоставление может вводить новые переменные, но никак не изменять уже существующие.

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

NC>>Если возможно написать def (sum, str) = foo(1, 2), то можно ли написать def (sum, str) = (1, "Hello") ?
H>Можно.

ОК, а можно ли кроме присваивания-инициализации использовать другие операции? Написать def (x, y) = (1, 2) + (3, 4) ?

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

VD> Попиши хотя бы пару месяцев на языке с кортежами (не обязательно на букву N, можно на F, H, M) и тогда обсудим практику.

O! Теперь я знаю, что означает название мужского журнала FHM — F#, Haskell, ML!

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

NC>ОК, а можно ли кроме присваивания-инициализации использовать другие операции? Написать def (x, y) = (1, 2) + (3, 4) ?

В некоторых языках можно, если предварительно описать, что именно должна делать операция + на кортежах с такими типами.

let (+) : int * string -> int * string -> int * string = fun (a,b) (c,d) -> a + c, b ^ d;;
let (x,y) = (1, "aa") + (2, "bb");;

выдает:

val x : int = 3
val y : string = "aabb"

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

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

NC>>ОК, а можно ли кроме присваивания-инициализации использовать другие операции? Написать def (x, y) = (1, 2) + (3, 4) ?

DM>В некоторых языках можно, если предварительно описать, что именно должна делать операция + на кортежах с такими типами.

Например в Nemerle

using Q;

module Q
{
 public @+(l : int * string, r : int * string) : int * string { (l[0] + r[0], l[1] + r[1]) }
}
 
def a = (1, "a");
def b = (2, "b");
def c = a + b;
 
System.Console.WriteLine($"$c");